It is the process of analyzing the APK statically, without executing it, with the aim of understanding the application logic, identifying protections and finding critical functionalities. Tools like Jadx allow you to decompile .dex files into readable Java code, making it easier to inspect suspicious classes, methods, and strings. Furthermore, disassemblers such as apktool, Ghidra, IDA Pro and Radare2 can be used to analyze the native code in assembly, expanding the view of the internal workings of the app.
On Android, applications are primarily written in Java or Kotlin and compiled to Java bytecode. This bytecode is then translated into Dalvik bytecode or, more recently, ART (Android Runtime) bytecode. When disassembling an .apk file, the disassembled code is usually presented in a language called Smali, which is a human-readable representation of Dalvik or ART bytecode. Smali is Android specific and provides a human-readable view of the application code.
apk - .dex (Dalvik executable files) -> smali code (Assembler for Android)
https://bitbucket.org/JesusFreke/smali/downloads/
cp test.apk test.zip
unzip test.zip
-> baksmali ( .dex -> smali code ) - Disassembler
java -jar baksmali.jar d test/classes.dex -o output
-> smali(smali code -> .dex ) - Assembler
java -jar smali.jar a output -o classes.dex
-> ziping
zip -r test.apk AndroidManifest.xml classes.dex res/ resources.arsc
-> signing the app with jarsigner
jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore test.keystore test.apk test
https://bitbucket.org/iBotPeaches/apktool/downloads/
-> apktool decompiling ( .dex -> smali code)
apktool d test.apk -o test
-> recompile
apktool b test -o test.apk
-> signing the app with jarsigner
jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore test.keystore test.apk test
https://github.com/iBotPeaches/Apktool
-> Doc - smali
http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html
https://github.com/JesusFreke/smali/wiki/TypesMethodsAndFields
-> jadx
https://github.com/skylot/jadx
-> dex2jar + JD_GUI
https://github.com/pxb1988/dex2jar
https://github.com/java-decompiler/jd-gui
-> enjarify + JD_GUI
https://github.com/Storyyeller/enjarify
https://github.com/java-decompiler/jd-gui
Ps:
Modify the app = smali code with apktool
Understand the app logic = .dex -> Java .class with jadx, enjarify/dex2jar + jd_gui
index.android.bundle is a package file that contains all the JavaScript code of the application developed in React Native. This file is generated during the application's compilation/packaging process. It includes not only the code that has been written, but also all the code from the libraries and dependencies that the application uses.
Before being included in the bundle file, the JavaScript files are transpiled (usually using Babel) to ensure compatibility with the Android runtime environment. After transpiling, Metro Bundler (the standard bundler used by React Native) compiles all these files into a single bundle file - index.android.bundle.
An interesting decompiler to use is react-native-decompiler, which is able to decompile React Native index.android.bundle files and Webpack bundles, making them significantly easier to read.
-> Running react-native-decompiler
npx react-native-decompiler -i ./index.android.bundle -o ./output
If the bundle was compiled using Hermes (a mobile-optimized JavaScript engine), the file will be binary and will not be supported by react-native-decompiler. In this case, it would be necessary to decompile using a tool that supports Hermes.
Use https://github.com/P1sec/hermes-dec
-> Decompile to pseudocode (which is still not valid JavaScript as it doesn't re-transcribe loop/conditional structures)
hbc-decompiler assets/index.android.bundle /tmp/my_output_file.js
-> Another option is to disassemble
hbc-disassembler assets/index.android.bundle /tmp/my_output_file.hasm
-> Use the unzip command directly on the APK file to extract it. Navigate to the assets folder to locate the index.android.bundle file
-> Create an HTML file with the following content
<script src="./index.android.bundle"></script>
-> Open the HTML file in a browser and view the JavaScript code using the developer tools (DevTools) under the "Sources" tab.
-> located in: /data/data/<package_name>/lib/
-> displays data from the binary file, revealing information from the read-only section (.rodata) constants, where constants and important data are located.
objdump -s lib.so
-> displays Information of external symbols About an Object File to facilitate the identification of functions and variations that can be accessed externally
nm -g lib.so
Dynamic Reverse Engineering Android consists of analyzing the app's behavior in real time, while it is running on the device. Using tools like Frida, Objection, it is possible to intercept methods, inspect loaded classes, monitor sensitive calls and identify active protections. This approach allows you to change or suppress app behaviors directly in memory, without having to recompile the APK, facilitating dynamic testing and the development of bypass scripts.
Main tools used:
-
Frida: Dynamic instrumentation framework that allows you to inject JavaScript code into application processes. It is widely used for hooking Java, Kotlin, native (C/C++) functions and, among others, inspecting API calls, reading/writing memory and manipulating logic in real time.
Info+: Hooking with Frida and Objection on iOS -
Objection: Frida-based tool that provides ready-made commands for common Android tasks, such as root detection bypass, KeyStore listing, class/method enumeration, and accessing internal sandbox files. Info+: Hooking with Frida and Objection on iOS
-> Capture logs from your app
adb logcat | grep <pid>
adb logcat | findstr <pid>
-> Using StackTrace for debugging and detecting possible protections in the app
-> listing classes with frida script: listing_classes.js
'use strict'
if(Java.available){
Java.perform(function(){
try{
Java.enumerateLoadedClasses({
onMatch: function(className){
console.log(className);
},
onComplete: function(){
console.log("[+] done!");
}
});
}catch(error){
console.log("[-] Exception");
console.log(error.stack);
}
});
}else{
console.log("[-] Java unavailable");
}
frida -U -f <package_name> -l listing_classes.js
-> listing classes - objection
objection --gadget <package_name> explore -s "android hooking list classes"
-> list methods of a class - objection
objection --gadget <package_name> explore -s "android hooking list class_methods <package_name>.<class_name>"
-> search for the code responsible for Anti-Root protection, after decompiling the dex to java class with jadx for code review
frida-trace is a tool for dynamic analysis, enabling you to hook native functions and high-level method calls at runtime. It’s ideal for tracking control flow, uncovering sensitive operations (like login or encryption), and bypassing app protections. It generates editable JavaScript handler files (__handlers__) for each traced function, allowing you to customize behavior, log arguments, modify returns, or bypass checks.
-> You can track functions by name pattern, for example, search for a term referring to a possible Root detection:
frida-trace -U -f <package_name> -i "*Root*/i"
-> Trace Objective-C methods where the class or selector contains "Root":
frida-trace -U -f <package_name> -m "*[Root* *]"
or target a specific function, for example:
frida-trace -U -f <package_name> -i '<function>'
https://github.com/interference-security/frida-scripts/tree/master/android