In my last blog entry, I did a walkthrough of the Anchored challenge from Hack the Box. I’ve solved several of the mobile challenges from Hack the Box, so I thought I would post walkthroughs of any of the retired challenges that I have already solved. The next challenge that I am going to solve is called Don’t Overreact.
This challenge is rated as Very Easy, so we shouldn’t expect it to be too difficult. The description says:
Some web developers wrote this fancy new app! It’s really cool, isn’t it?
This description doesn’t give us much information, but the name of the challenges can sometimes give us a hint as well. In this case, the name of the challenge is Don’t Overreact, which tells us that this app is probably a React Native application and the solution will probably be something specific to React Native applications.
With that in mind, we can download the APK and start performing some static analysis. Two of the common tools that are often used for static analysis are JADX and Apktool. For this situation, I am going to use Apktool. I’ll explain why Apktool might be the better option in this case at the end.
Static Analysis
We can disassemble the APK using Apktool with the following command:
apktool d <apkname>
Once we have the APK disassembled, we can start looking through the application files. Here is where the fact that this is a React Native comes into play. Something that is specific to React Native applications (and is also a good way to verify if an application is React Native or not) is the index.android.bundle file, which can be found in the assets directory. This file contains all of the React JavaScript from the application, and it is often a place to search for hard coded data like API keys or URL endpoints.
Searching for Keywords
Once we locate this file, we can search for some keywords using grep. A few examples of some good search terms to look for would be: key, password, token, api, and we can also search for http to look for any hardcoded URL endpoints. Most of these keywords don’t return anything interesting, but http returns a URL.
Looking at this URL a bit closer, we can see that there is a debug parameter in the URL, and this parameter includes a base64-encoded string.
Base64 can be easily decoded, and it is sometimes incorrectly used to encode sensitive data. For that reason, it is a good idea to decode any base64-encoded strings that you find when analyzing an application. There are many tools available to decode base-64, but my favorite is CyberChef.
We can simply copy and paste this base64-encoded string into CyberChef and then drag the “From Base64” option into the recipe. Then, we see our decoded text, which is our flag.
Why Not JADX?
Earlier I mentioned that for this specific example I chose to use Apktool for my static analysis instead of JADX. Typically, I prefer to use JADX to analyze Android applications because it decompiles the Dalvik bytecode into much more readable Java code. The JADX search function is also usually a great way to search for those keywords that we used in order to solve this challenge. However, the index.android.bundle file is not included in those search results. You can usually still view the file in the JADX viewer (though I have seen cases where the file was too large to be displayed by JADX), but as you can see in the screenshot below, the URL string does not appear in the search results even though it is clearly present in the index.android.bundle file.
This is why I prefer to use Apktool to analyze React Native applications and specifically the index.android.bundle file.
If you want to sign up for Hack the Box, please consider using my affiliate link at Sign up for Hack the Box with my affiliate link:
https://hacktheboxltd.sjv.io/VmGgeE.
If you’re interested in more content about security, hacking, making, and tech, check out my YouTube channel at https://youtube.com/@CorSecure.
