The WeiTch Protocol – Reversing The Front End – Part 2

In this second part of The WeiTch Protocol series of articles, we will focus on the methodology I have used to reverse the Twetch and Weiblock application's front end. As you will see in Part 3, reversing the front end proved to be important when trying to understand the messaging protocol etched on-chain. At this stage, if you haven't read the first part of my articles I recommend that you read it as I explain the reasons why I believe a standard and open-source messaging application would benefit both the users and the businesses.

Introduction

Before I begin, it is important to highlight that the results presented in this article are relevant to the date when this article was written. As you can imagine, Twetch and Weiblock are applications that are actively being developed. At present, there is no documentation about the API used by those applications, nor about the protocols used. Therefore, a little investigation was required.

The methodology

Reversing a web application is not a hard task to do. In fact, it is fairly easy as long as you make sure you follow a rigorous methodology and refrain from making wild assumptions during your investigation.

The first step is ensuring you have (as a minimum) the right tools for it. What you will need is:

• A modern web browser with debug features such as Google Chrome DevTools.
• A proxy to capture the web requests and responses and allow editing, such as Burp (optional).
• A Money Button account.
• A Twetch and a Weiblock account.
• A bit of spare time.
• A basic understanding of Bitcoin, communication protocols, cryptography, and web-based programming (HTML, JavaScript, JSON, etc.).

I will not detail the steps to link all of the above together but as you can guess, the setup is fairly straightforward. All you need is combining those requirements to have an environment that provides full visibility and control of the application's communication data and flow: from the moment you perform an action on Twetch or Weiblock (publish content, like, comment, etc.) to the moment your transaction is broadcasted to the Bitcoin network.

Reversing the applications

You might wonder why I wish to talk about the front end when what I should focus on is the messaging protocol as stored on the Blockchain. The reason is simple: both Twetch and Weiblock do not strictly rely on the Blockchain to read and write user data. In fact, the content you post is pre-processed by the application, then ends up both on the Bitcoin network (using Money Button) and on the application's internal database. Which means: messages that are not present on the application's internal database will likely not be processed nor displayed to the end user.

For instance, using those applications, it is possible to post a message on the blockchain using the protocol requirements imposed by Twetch and Weiblock. However, if those platforms are not aware of the transaction, they will not pull them because they are currently not designed with a mechanism that automatically fetch third-party published content from the blockchain. The opposite is also true: it is possible to post content on Twetch and Weiblock without requiring you to broadcast content to the blockchain in the first place. Which is the reason why I believe it is important to spend a bit of time understanding what is going on with the application – and it starts with the front end and API calls it makes. With that, we will be able to better understand the application's limitations, what is not done properly and how things can be improved.

This exercise will also help us better understand the message format and its content as seen on the blockchain. So, let's explore the UI and play around with those applications.

The case of Twetch

Twetch is fairly straightforward to reverse. The JavaScript code the application uses only requires some beautifying. Which can be done using Chrome DevTools (which doesn't always work). Alternatively, you can use this Online JavaScript Beautifier which works very well.

You can learn a lot about the application only by reading the JavaScript code provided to your web browser. Which, by the way, is also something loved by hackers.

Most of the content rendering and payload structure construction for the API are handled by the UI on the application's front end. Meaning: it is user-controllable. Anything can be hooked and altered. For instance, it is possible to obtain access to posting images or activating the Twetch DarkMode without spending a cent on those features. This is because the controls and application's logic are directly available to the end user on the application's front end. I will, however, not detail this part and will let you investigate it if this is something you wish to explore.

For the rest, any actions that involve login, storing user's actions and activities and pre-processing data payloads for content to publish go through API calls and is handled by the application's back end which sometimes also involves Money Button.

For example, below is what the front end submits to the back end to sign content before it can get swiped and broadcasted to the Bitcoin network using Money Button. As you can see, the message is visible in the request submitted by the user's web browser.

You can also see that the next request was a Money Button simulated request, which, as I will detail later in Part 3 of my articles, displays the raw transaction that will be broadcasted. We will also discuss what is stored on-chain, what isn't and which messaging format Twetch uses.

So far, we have learned that anything Twetch processes is fairly easy to understand (and modify) using the application's own code and network communications.

The case of Weiblock

Similarly, Weiblock also relies heavily on the client's data processing (using JavaScript) for most of the application's functioning. However, there is a catch when the client performs certain requests to the backed: the API requires encrypted messages. Which means, the application's front end needs to pre-process request payloads and encrypt them in a way they are understood by the back end. This, by the way, adds up to the application's load and is completely unnecessary (I will explain why below).

Let's have a quick look at a simple search call for instance, which is something that does not hold any sensitive information. As seen below, it triggers a couple of encrypted payload requests submitted to the server:

/hWpnaeRDO7Xw34oILTaz0I/eMJynGGHxZG7fRUmdxGFMmy5Vv61nxRo81nOIp/8FcBTZzgvmRmkglPRIbkbk+A1D8bK2Ur580NpIJGqrzFkPlVYCoesv1f9NGeNNQQh8N0ZijKjkR2KgmMqHIp/koj1pE3Ytk+9+Vqd1l5vSkR3O/n/1MGeCFR0Cz8y5/biZxfM9PXrNMotE8URP5tmaBG6SG3mvgkoAt1+QKH6MlykcZC+OrLWLRNVUsDhV+lElvg8FuOB0J23l4VC2//xuXffZAQ1BCA0+SdpVNGZ0wE=

The above is the content of the request (the payload), which is what your web browser (front end JavaScript code) constructs and sends to the server. This specific search request retrieves some content of the posts listed by the search functionality. Search also does not require the user to be authenticated. Therefore, there is no real value added to require encryption here... But this is something Weiblock imposes anyway, so we can't get around it.

Another example is what the client submits to the application after a message is broadcasted to the blockchain:

I believe the initial intent of the developer(s) of encrypting messages before they are sent was likely to provide some sort of obfuscation layer rather than encryption. Nevertheless, it needs to be understood that if the TLS encryption (first layer of encryption) is broken by an attacker, this attacker can just alter the JavaScript code of the application and therefore access whatever the user processes before the messages are encrypted. Even in a passive attack scenario, an attacker who gains access to the plain requests and responses (within TLS) can still decrypt anything because the application uses symmetric encryption with a publicly known shared key (which also transits from the server to the client in plain). I will not elaborate further here, but there are ways of implementing second-layer encryption properly (hint: have a look at how ProtonMail does this).

At this stage, it is safe to say that Weiblock consumes a bit of our CPU power and their back end CPU power for literally no real purpose. But still, we wish to understand the application and thus we need to understand what the application encrypts or decrypts. So, let's find the key and algorithm used in the code...

The algorithm used to encrypt and decrypt with Key and IV:

• Algorithm: AES-128 (the Key is 16 bytes)
• Mode: CBC-PKCS7
• Key (UTF-8): R7DF45SD50BB83E1
• IV (UTF-8): s4af72c78fts6625

With this information you can either write your own script or program that will decrypt and encrypt data. Or you can be lazy like me and just find a tool that does it for you. I am personally using CyberChef, which I recommend to anyone who works with cryptography. Enter the algorithm detail and the input to decrypt or encrypt and hit the "Bake!" button. The output will display the decrypted or encrypted message of your input.

You can access my preconfigured CyberChef page here. Encryption works the same way, just disable the From Base64 & AES Decrypt boxes and enable the AES Encrypt & To Base64 boxes, then enter the content you wish to encrypt using the input box.

{"token":"LTNK2LwugtfzOj7oCnsUh/awnPg4fsuvB719QX8EAYEOc3Zv9zHZWypxOQKyUzbH","tx":"5ccfe6eaf87876acb83b473f74b760ac7acfde30cf30df4c7d7f1c12e7aa8496","from":"4070"}

What you can read above is a JSON payload containing the session token, the transaction ID (which was broadcasted using Money Button) and the Money Button user ID used to identify who submitted the post (redundant information, because the token's purpose already serves as the user's identifier). This payload is submitted encrypted to the back end using the Weiblock post API call. But, again, I will not list the numerous tricks that can be done at this stage with altering the request's payload (some were fixed, others were not) as this is not the purpose of this article. And as you can imagine, a lack of back end controls can easily lead to interesting scenarios when exploited by malicious users.

Now that we understand how the client's applications work for both platforms and how messages are processed. Let's shift our focus to Money Button and how the applications prepare our messages ready to be swiped and broadcasted to the Bitcoin network.

From message pre-processing to Money Button

So far, we have learned how the application's front end and API calls to the application's back end come together to pre-process and process users' requests. We have also seen that most of the logic is handled by the application's front end and briefly mentioned that clients see the simulated Money Button raw transactions before they are broadcasted to the blockchain.

I still need to clarify the link between Money Button and why it was important to understand the front end of our applications:

Reversing the client-side of the application taught us that most of the logic and pre-processing happen on the client side. This is also true for preparing the raw Money Button transactions. The JavaScript code of the application will gather all the data that needs to be swiped with Money Button. It will format it and display a Money Button for it. The stage from where the client's data is ready to be formatted to where it arrives on Money Button is purely handled by the client-side, and it does not require assistance from the back end of our application. Which also means that any user can alter the data that is meant to be swiped with Money Button. In fact, you can just instruct Money Button to swipe anything you want, but let's not dive into this.

This application processing logic is valid for both Twetch and Weiblock. The Money Button raw transaction data pre-processing and payment processing always happen on the client side in JavaScript.

The construction flow is as follows (applicable to both applications):

1. User decides (s)he wants to submit content or perform an action.
2. Application's front end processes the request, make API calls to the back end if necessary.
3. Application's front end decides whether or not Money Button should be involved.
4. If Money Button is involved, application's front end constructs the message for Money Button and displays a Money Button for this specific message.
5. User swipes the Money Button and the transaction is submitted to the network.

You might even have witnessed it yourself, on every Bitcoin SV applications that use Money Button, the button is redisplayed whenever there is new data to be swiped for it. This is exactly what is happening: the application displays a new Money Button each time there is new/updated content that needs to be swiped.

With all of that said, what we really care about then is to understand the raw transaction that is broadcasted. And the easiest way to see the transaction's content is simply by having a look at the simulated Money Button payment request.

Conclusion

Understanding the applications' front end and API calls is key to understand how the applications function. Throughout this article I have shared with you how you can investigate on your own those application's functioning. Such exercise is important when it comes to engineer your own application, whether or not the purpose is to develop a competitor or a third party companion application. Especially when there is a lack of documentation or no developer is available to explain the intricacies of his or her creation.

The next part of this series of articles will be dedicated to reversing the protocol used by Twetch and Weiblock to better understand what is recorded on-chain and what is not. I will also be exposing what is done properly and what is not and provide recommendations.