Reverse Engineering in Mobile Development: What It Is, Tools, and Analysis Methods

What Is Reverse Engineering?

Reverse Engineering is the discipline of analyzing software to recover the characteristics, logic, and structure of an application from its binary representation. For mobile applications, the objects of analysis are APK files (Android) and IPA files (iOS), which contain compiled code, resources, manifests, and certificates. The result of reverse engineering is the extraction of algorithms, protocols, encryption keys, API schemas, and business logic.

The goals of reverse engineering are divided into legitimate and illegitimate. Legitimate: analyzing malware to create security tools, auditing one’s own applications for vulnerabilities, ensuring compatibility with closed protocols, patent analysis, and education. Illegitimate: theft of intellectual property, bypassing license restrictions, creating pirated copies, and modifying applications to steal user data. According to Google Play Protect (2025), 78% of malicious modifications of banking applications are created based on the original APK processed through reverse engineering.

The methodology of reverse engineering includes two main directions: static analysis (without running the application) and dynamic analysis (during execution). Each approach provides a different level of information. Static analysis gives a complete picture of the code but lacks runtime data. Dynamic analysis reveals real behavior, data flow, network calls, but only within a specific execution scenario. Professional reverse engineering always combines both approaches.

Static Analysis Tools

Static analysis is the first stage of reverse engineering. The original APK or IPA is unpacked, and each component is analyzed separately. The main targets: DEX bytecode, resources, manifest, native libraries (.so, .dylib), and metadata.

jadx — DEX to Java decompiler

jadx is the primary tool for static analysis of Android applications. It converts DEX bytecode into readable Java code with minimal loss. jadx supports: multidex decompilation, recognition of lambdas and inline Kotlin classes, and export to Gradle project. For obfuscated code (ProGuard), jadx displays code with names a, b, c, but class structure and call sequence are preserved. According to independent testing, jadx correctly decompiles 85–92% of code even with obfuscation.

apktool — resource unpacking

apktool decodes APK into smali code (DEX assembler) and restores resources in a readable format: AndroidManifest.xml is converted from AXML to readable XML, layouts become XML markup, strings.xml becomes plain text. apktool allows modifying resources and rebuilding the APK. After unpacking via apktool and replacing resources, the application can be installed with modified content.

Ghidra — native library analysis

Ghidra (NSA) is a reverse engineering framework essential for analyzing .so libraries on Android and .dylib on iOS. Ghidra disassembles ARM64 code, reconstructs C pseudocode, and builds call graphs. For mobile reverse engineering, Ghidra is used to analyze native implementations of cryptography and DRM mechanisms. Ghidra supports scripting in Python and Java for analysis automation.

# APK Unpacking and Decompilation
$ jadx -d output_dir app.apk

# Resource unpacking via apktool
$ apktool d app.apk -o app_unpacked

# Native library analysis via Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Searching for string constants in DEX
$ strings classes.dex | grep -i api_key

Dynamic Analysis Tools

Dynamic analysis is performed on a running application. The analyzer connects to the process and intercepts function calls, arguments, and return values in real time.

Frida — universal instrumentation tool

Frida is the leading tool for dynamic analysis of mobile applications. Frida injects a JavaScript engine into the application process (Android ART or iOS app) and allows intercepting calls to both Java/Objective-C and C/C++ functions. With Frida, reverse engineers can: log all calls to the AES.decrypt() method with parameters, substitute return values arbitrarily, disable SSL-pinning via Universal Android SSL Unpin, and trace native calls via Stalker. Frida works without modifying the APK/IPA, making it indispensable for penetration testing.

Objection — Frida wrapper

Objection provides ready-made commands for common reverse engineering tasks without writing JavaScript scripts: disable-pinning (disabling SSL pinning), dump-keychain (iOS), explore (class hierarchy browsing), memory search (searching for strings in memory). Objection allows performing a full dynamic analysis without a single line of code. For iOS applications, Objection automatically finds and logs calls to NSURLSession, CFNetwork, and NSKeyedArchiver.

Xposed Framework

Xposed is a framework for Android that works by replacing the app_process file in Zygote. Unlike Frida, Xposed does not require root access after installation. Xposed modules can intercept method calls in any application. For reverse engineering, Xposed is convenient for long-term analysis: the module is installed and runs continuously, logging the application’s behavior in different scenarios. Xposed supports Android up to version 8.1; for Android 9+, EdXposed based on SandHook is used.

// Frida: intercepting decrypt() method in an application
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

The Process of Reverse Engineering an Android Application

The standard reverse engineering workflow consists of sequential steps, each providing a certain level of information.

Step 1: Reconnaissance

The analyst examines the APK at the metadata level: targetSdk, uses-permission (which permissions are requested), intent-filter, and exported components. Permissions can reveal which APIs are used (android.permission.CAMERA → camera, android.permission.RECORD_AUDIO → audio). Exported activities identify entry points without authorization. This stage is performed via aapt or ApkAnalyzer and takes 1–2 minutes.

Step 2: DEX Decompilation

The APK is unpacked, and classes.dex (or multidex) is fed into jadx. The output is Java/Kotlin code organized in packages. The analyst looks for key classes: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, and checks which algorithms are used. If the code contains strings like AES/CBC/PKCS5Padding, the application uses encryption and the key needs to be found. At this stage, hardcoded keys, API URLs, OAuth tokens, and secrets are identified. Without obfuscation, the entire application code reads like a regular Java project.

Step 3: Traffic Analysis

After setting up Frida or Objection to disable SSL pinning, the analyst launches the application and intercepts network traffic via Burp Suite or mitmproxy. Traffic data reveals the API schema: which endpoints, which parameters, and in what format. If possible, the analyst modifies requests and checks the server’s response to incorrect or malicious data. Lack of server-side validation is a direct vulnerability discovered at this step.

Step 4: Recording to data.json

Analysis results are recorded in a structured format. For each vulnerable point found, the following is indicated: class and method, vulnerability description, exploitation vector, and remediation recommendation. This dataset is passed to the development team or used to compile a penetration test report. In automated environments (MobSF), the report is generated automatically based on static and dynamic analysis results.

Reverse Engineering iOS Applications

Reverse engineering iOS applications is more difficult than Android due to Apple’s stricter security architecture and the lack of direct file system access on stock devices. Jailbreak is required for iOS analysis.

Mach-O Static Analysis

An IPA archive contains a Mach-O binary — Apple’s universal executable file format. Hopper Disassembler or IDA Pro is used for decompilation. Unlike Android DEX, which decompiles into Java with minimal loss, Mach-O contains native ARM64 code that is reconstructed into C pseudocode with lower accuracy. Hopper achieves 60–70% reconstruction; the rest must be analyzed at the assembly level.

Dynamic Analysis with Frida for iOS

Frida on iOS requires jailbreak and installation of frida-server. After connecting, Frida intercepts Objective-C methods via the API message routing. For iOS applications, a typical scenario involves: intercepting NSURLSession.dataTaskWithRequest to log HTTP requests, intercepting NSKeyedUnarchiver for serialized data analysis, and tracing CoreData queries via frida-trace. Frida became available for iOS 15–17 with the release of the Dopamine jailbreak.

IPA Modification

Reverse engineering may involve modifying the IPA followed by repackaging and installation on the device. Tools include: ipatool for unpacking, MachOView for viewing sections, and optool for code injection. After modification, the IPA is signed via ldid or fastlane sigh for installation on a jailbroken device. For iOS 16+, code signing is verified at the Secure Enclave level, and a modified IPA will not run on a non-jailbroken device.

// Frida: intercepting HTTP requests in an iOS application
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Methods of Protection Against Reverse Engineering

Protection against reverse engineering follows the principle of layered security: no single method provides 100% protection, but a combination makes reverse engineering economically unfeasible.

Code Obfuscation

The basic level is ProGuard for Android, which replaces class and method names with single-character names. For enhanced protection, DexGuard adds overload induction (multiple methods with different signatures and the same name) and AES-256 string encryption. Obfuscation increases code analysis time from 5 minutes to 5–20 hours depending on the level. DexGuard additionally obfuscates control flow, making the code unreadable for jadx.

Constant Encryption

All string constants — URLs, keys, tokens, SQL queries — are encrypted at build time and decrypted at runtime. This protects against static analysis of strings in DEX files. An attacker running strings on app.apk will not see a single API endpoint. Even after decompilation, all strings appear as binary data. Each string can use a separate key, complicating deobfuscation.

RASP and Integrity Checks

A RASP agent within the application detects Frida and debugging at runtime. Integrity checks via SHA-256 hash of the APK prevent running a modified version of the application. If the APK hash does not match the reference hash (stored in the native layer), the application terminates. This blocks attacks based on APK modification, including repackaging.

Server-Side Protection

Critical business logic should be executed on the server, not on the client. Even if an attacker fully decompiles the application, the server-side code remains inaccessible. Server-side validation of all requests and parameters prevents exploitation of vulnerabilities found during reverse engineering. Server attestation via Play Integrity API or App Attest confirms that the request comes from a genuine, unmodified application.