Reverse engineering a mobile application means taking apart an Android or iOS binary to learn about its makeup. This insight makes it easier to manipulate an app in ways its developer didn’t originally intend. As a mobile pen tester, security analyst or researcher, knowing how to reverse engineer mobile apps improves the quality and depth of your analysis and aids mobile application security testing efforts.
Unfortunately, security analysts and researchers aren’t the only ones who routinely reverse engineer mobile binaries. Attackers will also reverse engineer a mobile binary for their own malicious intents. Knowledge of the techniques by which both security practitioners and attackers reverse engineer a mobile application can ensure this area of focus isn’t missed during the secure development process.
Security analysts or attackers have several reasons for utilizing mobile application reverse engineering techniques. Someone attempting to reverse engineer a mobile app might want to reveal information about backend services and servers in order to launch attacks against those entities. Some others might attempt to reverse engineer tactics to reveal static cryptographic values and identify specific ciphers in use within the app’s runtime. Still others might utilize reverse engineering of a mobile app in order to either better understand its overall logic, identify ways that subsequent code modification may be performed, or to even steal intellectual property.
Regardless of the intent, every successful reverse engineering attempt should either identify services the app communicates with, locate hard-coded cryptographic values that may allow access to sensitive data, determine the level of effort required to bypass specific defense-in-depth or anti-tamper techniques, or uncover unreported app functionality.
There are several ways to reverse engineer a mobile app. One of the most common methods entails using a decompiler or a disassembler. However, you don’t need either of those tools to reverse engineer a mobile app. You can perform reverse engineering via a command line interface (CLI), a custom tool, or Frida script. This tutorial covers each of those methods of reverse engineering without a decompiler or disassembler.
You can perform reverse engineering via a command line interface (CLI), a custom tool, or Frida script.
Reverse Engineering a Mobile Application via the Command Line
An Android Package Kit (APK) or an iOS app store package (IPA) can be reverse engineered using a simple command line interface (CLI). The following two examples use the iTerm2 terminal, which is only available for Mac devices. Use an alternative CLI for other machines.
Verifying Presence of Memory Corruption Built-in Security Protections
When investigating an IPA, you may want to quickly determine whether or not the app is utilizing free, memory corruption built-in security protection measures within its native libraries or frameworks. Oftentimes, free security features such as stack smashing protection and automatic reference counting may have been disabled during the development of the binary. Generally, there are no downsides to enabling these built-in features because they aid the binary in mitigating against potential buffer overflow and memory management attacks.
If you don’t have access to the source code of the IPA, you can simply reverse engineer the binary to determine the answer yourself. To do this, unzip the binary file on the terminal, cd to the IPA folder and the subsequent .app folder, and then make use of the grep command. To search the IPA for instances of stack smashing protection, simply enter grep -iER “stack_chk”. This CLI command will recursively search the entirety of the binary for instances of the stack smashing protection flag, ignoring word case. If instances show up, we know that stack smashing protection has been enabled. If no instances are found, we can perform further analysis to see if the binary might be susceptible to a buffer overflow attack. You can also use the approach shown below to check for ARC protection via the grep -IER “objc_release” command. Using the iOS Damn Vulnerable iOS application (DVIA) app available for download from GitHub, we entered the above commands to manually verify that stack smashing protection was enabled for the binary.
Monitoring the Device Log for Sensitive Data Entry
When you are investigating an Android binary, you might be curious if any sensitive data is exposed within the device log while using the app. You can reverse engineer the binary via the CLI using the adb logcat command. For this command to work on your terminal, you must first enable USB debugging on your Android device. Next, enter the command and you will then see a number of log entries. Launching your app enables you to search the log entries for app-specific entries. In the example below, we installed the InsecureShop Android binary. Using adb logcat during the app’s launch and subsequent login flow, you can see that the device logs this entry. The entry includes sensitive information such as the userName and password for the device.
Reverse Engineering a Mobile Application via Custom Tooling
Another way to reverse engineer an IPA or APK requires custom tooling. For example, the Objection tool for both Android and iOS reverse engineering. Objection is a runtime mobile exploration tool that works on jailbroken/rooted and non-jailbroken devices. Frida powers Objection so you will need to install that first for the toolkit to function.
To run Objection, enter “objection –gadget [package name of app] explore”.
Monitoring Cryptographic Functions During App Runtime
Objection can often come in handy for discovering how a mobile app works in real time. Do you want to learn what cryptographic functions an app uses during runtime? Objection can help. Launch Objection and enter iOS monitor crypto. As you navigate the app, Objection will show which cryptography functions are in use during each action or activity. If you’re curious if the mobile app uses a weak cryptographic algorithm for critical security operations, Objection can help answer that question.
In the below example, we use Objection to determine what cryptographic functions are used to encrypt a password (“objection_rules”) within the DVIA iOS app. After running the iOS monitor crypto use case and submitting a password, we see the cryptographic functions present in that process. The password is shown as “dataIn” and the encrypted form of the password is seen in “dataOut”. We see that KCCPBKDF2 and KCCAlgorithmAES128 are the primary cryptographic algorithms for this process.
If we take the “alg”, “key”, and “iv” values from the CCCCryptorCreate operation as well as the “dataOut” value, we can verify that the AES algorithm is used to encrypt the password. With this knowledge, we can presume that the AES algorithm can also be used to decrypt ciphertext. Using a simple website like CyberChef can help us do this quickly.
Hooking & Launching Android Activities That Reveal Sensitive Data
Another example of where Objection can aid reverse engineering is when you want to launch a sensitive activity for an Android app. Certain activities when launched may reveal sensitive data. You can use Objection’s android hooking capability to list out the app’s activities, services, and receivers. Hooking may be especially useful if the app’s source code cannot be deobfuscated. Using the Damn Insecure and Vulnerable App (DIVA), you can use android hooking list activities to list all the activities that have been specified by the AndroidManifest.xml. This may come in handy if you wish to quickly determine if any activities can be abused or reveal sensitive data. After running the command, we immediately find one activity (“.APICredsActivity”) that seems promising.
We can now use a followup Objection command, android intent launch_activity,to launch a specific activity class by building a new Intent and running startActivity() with it as an argument. Launching the .APICredsActivity and running the intent reveals sensitive vendor API credentials within the app’s user interface.
Reverse Engineering a Mobile App via Frida Scripts
While Objection is a powerful tool for reverse engineering, using an actual Frida script can open up even more opportunities. Frida is a dynamic instrumentation toolkit specifically designed for reverse engineering a number of other functions. You can use Frida to inject your own custom scripts into an appl’s processes or use public available scripts created by others.
Bypassing Android Biometric Authentication
Oftentimes when testing an Android app, you may come across an app that has fingerprint ID functionality. Normally, most applications require a username and password for login. Other apps may utilize multi-factor authentication in the form of a PIN, OTP or biometrics. Depending on the app, the biometric configuration may have been set up insecurely to allow an attacker to bypass the fingerprint authentication altogether. In that case, an attacker who gains physical access to the device could reverse engineer the biometric authentication process to be able to login to the app, even if they do not have access to the original user’s fingerprint.
A Frida script can come to the rescue in this scenario. For example, a publicly available Frida script by researchers at F-SECURE can bypass the Android biometric authentication altogether if the app does not make correct use of the BiometricPrompt.CryptoObject. Normally, proper usage of this object requires the user’s biometric authentication object to be stored in the Android Keystore, preventing the device from unlocking without that specific fingerprint. However, if the BiometricPrompt.CryptoObject is of a null value, then the object isn’t stored in the Keystore and a valid fingerprint isn’t required, which sets up the bypass. This script proves useful because a lot of apps are susceptible to the above script. However, note that this only works if the user has already set up an initial fingerprint ID for the app.
Bypassing Network Defense-In-Depth Runtime Controls
Frida scripts for reverse engineering can enable you to bypass certain network defense-in-depth controls which might interfere with a man-in-the-middle (MiTM) attack. While not expressly recommended, when implemented properly, certificate pinning can mitigate against MiTM attacks by only accepting specific certificates for client-server connections. A Frida script can help reverse engineer the application to discover what method is being used for certificate pinning and then hooking into the process to disable or bypass the mechanism during runtime. In the example below, an iOS Flutter app initially prevented network interception due to certificate pinning. However, after running a publicly available Frida script, we could hook into the SecTrustEvaluate, SecTrustGetResult, and SecTrustEvaluateWithError() methods. Hooking into those methods ensured the trust management certificate object was considered trusted, enabling us to intercept traffic using an interception proxy due to the bypass. You can find additional Frida scripts for other reverse engineering efforts at Frida Codeshare.
Conclusion
This walkthrough showed you three reverse engineering tactics that work without a decompiler or disassembler. However, there are other reverse engineering tactics that weren’t covered.
Reverse engineering is a necessary aspect of mobile app pen testing. Find more information and expand your reverse engineering skills with free training from NowSecure Academy. Online courses focused on additional reverse engineering tactics include Cracking Fun With Frida & Radare and iOS Reverse Engineering with Frida.
