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.
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.
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.
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
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
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:
Another example is what the client submits to the application after a message is broadcasted to the blockchain:
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):
- IV (UTF-8):
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.
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:
The construction flow is as follows (applicable to both applications):
- User decides (s)he wants to submit content or perform an action.
- Application's front end processes the request, make API calls to the back end if necessary.
- Application's front end decides whether or not Money Button should be involved.
- If Money Button is involved, application's front end constructs the message for Money Button and displays a Money Button for this specific message.
- 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.
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.