Hbctool

[Andree Vandestreek]

Mobileoperators are distributing more and more Android and iOS applications in order to interface with their APIs and provide enhanced services to their subscribers. The need for P1 Security to reverse engineer mobile platform-targeted applications in the context of black-box security audits, as well as the global lack of effective tools regarding reverse engineering React Native-based applications, led us to develop hermes-dec.

P1 Security is publishing the initial release of hermes-dec, a new tool for reverse engineering React Native mobile applications for Android and iOS embedding a JS bundle compiled within the bytecode language of the Hermes virtual machine.

The Hermes bytecode is a binary-form, intermediary representation of Javascript which is used as a mean of optimizing the execution speed of React Native mobile applications. Announced by Facebook on July 2019, and ultimately used by default in new React Native projects since September 2022, we have seen the Hermes bytecode format used in many popular React Native applications, whilst React Native itself is an increasingly popular mobile software development platform, and a major cross-platform mobile development framework.

The hermes-dec tool released by P1 Security allows to disassemble the Hermes bytecode, with the intent to be compatible will all public version of the Hermes virtual machines (from 0.1.0 to the current 0.12.0, or bytecode version 89, at the time of writing, end of 2022). Other tools such as the hbctool utility support a more restricted set of versions of the Hermes bytecode, and the hbcdump tool present in the Hermes source tree supports the exact version of the Hermes virtual machine it was built for.

In addition, it allows to decompile the associated code into JavaScript-like pseudo-code. Please keep in mind that this is the equivalent of beautifying a minified React Native bundle, hence nor the naming of the variables, nor the original control flow, neither the structure of functions will be reconstructed as an outcome of the decompilation process.

It was developed considering the need for P1 Security to often reverse engineer mobile platform-targeted applications in the context of black-box security audits, as well as the global lack of effective tools regarding reverse engineering React Native-based applications.

This is open-source software, feel free to give it a try and provide any feedback and contribution. Please also note that this tool was initially made by P1 Security for its internal use and that its stability for other uses is not guaranteed.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

As we saw on the first part of this adventure, the Lovebox backend does not check if the box we're sending a message is allowed or not to receive a coloured message. Changing the hasColor value in the app response of an API request is all we need.

In the past the index.android.bundle was a uglified JS file that contained the entire React app. Now things are a little different because of Hermes, a JavaScript engine optimized for React Native, that is now used by default in the React-Native builds. It compiles the entire app into a bytecode that has a unique set of instructions with registers managment and such.

Searching on GitHub I found hbctool a open-source tool for disassembling and assembling the Hermes bytecode. Unfortunately there are different version of Hermes and the tool from the original author doesn't support the version 94 that is used for the Lovebox app. BUT, looking at the differents forks I found this one that supported the version 94.

Our _id disguised as hasColor would still unlock the colors even if the bool value in reality is a integer number. I might add that even if this wouldn't work we could alias another bool field like isConnected. (But probably get the coloured messages only if the Lovebox is actually connected to the internet).

- Use jadx to decompile the app and extract assets

-> It's a React Native app using Hermes - the actual challenge code is in Hermes Bytecode

- Use hbctool to disassemble the index.android.bundle

- Username "admin" is hardcoded, password and flag are decoded from static buffers

- Extract buffers from the metadata.json generated by hbctool

-> password and flag

Checking through bundle file reversing, we found this GitHub Repo of hbctool, a command-line interface for disassembling and assembling the Hermes Bytecode. The tool is capable of decompiling bundle to hasm and compiling hasm back to bundle. However, we get the following error when trying to decompile:

In the repo, it states that currently only version 59, 62, 74, and 76 are supported. There is a post in the repo issues where someone added support for version 84 in his forked repo. Using that, we successfully disassembled index.android.bundle to instruction.hasm, which looks like this.

Our goal here is to bypass the password check and login with username admin. Looking at the source code, the main interesting function within instruction.hasm is the tryAuth function which is responsible for verifying the username and password.

The function reads input username to Reg8:0, and loads a const string admin to Reg8:1, then compares them. If they are not equal, then some state will be triggered which is to print the Wrong Username/Password combination error.

This block is the key to solving this challenge. The entered password is compared with the content of a static buffer run through decodedText. If they match, check is successful and we are able to login. Our trick here is to change JStrictEqual to JStrictNotEqual, so any random password can bypass the password check.

3a8082e126