API Reverse Engineering

Decompiling Mobile Binaries to Extract Hidden API Endpoints

Discover how to use JADX and Apktool to reverse Android and iOS binaries, revealing hardcoded URLs, API keys, and internal routing logic hidden in the source code.

SecurityAdvanced12 min read

In this article

The Hidden Blueprint: Why Static Analysis is Essential

The Limitations of Traffic Sniffing

The Android Deconstruction Pipeline

Reconstructing the Networking Layer

Navigating Obfuscation and Hardcoded Secrets

Deciphering Custom Request Headers

The iOS Perspective and Mach-O Analysis

Analyzing Swift Binaries

The Hidden Blueprint: Why Static Analysis is Essential

Traditional API security testing often relies on dynamic analysis through intercepting proxies like Burp Suite or Charles. While effective for observing active traffic, this method only reveals endpoints triggered during manual navigation. It fails to expose hidden administrative routes, beta features, or dormant endpoints intended for future releases.

Static analysis fills this gap by examining the compiled binary directly to understand the full application surface. By reversing the code, engineers can discover hardcoded environment variables and internal routing logic. This approach identifies how the application constructs requests before they are even sent over the wire.

The methodology involves converting machine-readable instructions back into a human-readable format. For Android, this means reversing the Dalvik Executable format back into Java or Kotlin code. For iOS, it involves disassembling Mach-O binaries into assembly or pseudo-C code to find logic patterns.

Static analysis is not just about finding hidden strings; it is about reconstructing the mental model of the original developers to predict where vulnerabilities might exist.

The Limitations of Traffic Sniffing

Intercepting network traffic is frequently thwarted by modern security implementations such as Certificate Pinning. When pinning is active, the application refuses to establish a connection if the certificate does not match a hardcoded hash. This makes dynamic observation impossible without first patching the binary.

Furthermore, modern applications often use complex request signing algorithms to prevent tampering. Without access to the source code, understanding how these signatures are generated is nearly impossible. Static analysis allows us to locate the exact cryptographic functions used for these security headers.

The Android Deconstruction Pipeline

Android applications are distributed as APK or AAB files, which are essentially specialized ZIP archives. These archives contain the compiled bytecode in DEX files, along with resources and a manifest. To understand the API interaction, we must decompress these assets and convert the bytecode into a navigable format.

Apktool is the industry standard for unpacking the manifest and resource files. It decodes the binary XML files into a readable format and converts DEX files into Smali code. Smali is an intermediate representation that is useful for patching but difficult for high-level logic analysis.

For a higher-level view, JADX is the preferred tool for converting DEX files back into Java source code. It provides a searchable interface that allows developers to jump between class definitions and method calls. This makes it significantly easier to trace the flow of data from a user interface component to a network request.

Apktool: Best for resource analysis and binary patching to bypass security controls.
JADX: Best for understanding business logic and mapping internal API routing.
Ghidra: Used for analyzing native libraries written in C or C++ via the Java Native Interface.

Reconstructing the Networking Layer

Most modern Android applications use the Retrofit library for managing API interactions. Retrofit uses Java interfaces to define endpoints, which makes them very easy to identify during static analysis. These interfaces typically contain annotations that reveal the HTTP method, the path, and the required parameters.

When searching the decompiled source, looking for the @GET or @POST annotations is the fastest way to map the API surface. Even if the code is obfuscated, these annotations often remain intact to allow the library to function. This provides a clear list of all server-side functions the app is capable of calling.

javaReconstructed Retrofit Interface

1// This is an example of what a reversed Retrofit interface looks like in JADX
2public interface UserApiService {
3    @POST("api/v2/auth/login")
4    @Headers({"X-Platform: Android", "Content-Type: application/json"})
5    Call<LoginResponse> authenticateUser(@Body LoginRequest request);
6
7    @GET("api/v2/user/profile/{uid}")
8    Call<UserProfile> getUserData(@Path("uid") String userId, @Header("Authorization") String token);
9
10    @DELETE("api/v2/internal/debug_cleanup")
11    Call<Void> triggerInternalCleanup(); // This endpoint might not be visible in a proxy
12}

Navigating Obfuscation and Hardcoded Secrets

Developers often use tools like ProGuard or R8 to obfuscate their code before release. This process replaces meaningful class and method names with short, nonsensical strings like a, b, and c. While this makes reading the logic harder, it does not hide hardcoded strings or the overall structure of the network calls.

To combat obfuscation, you should focus on constant values and library signatures. Many developers leave sensitive information in the strings.xml file or as hardcoded constants in a Config class. These can include API keys, third-party service credentials, and base URLs for staging or development environments.

A common pattern is to search for protocol strings like https or file extensions like .json. This often leads directly to the core configuration logic of the application. Once the base URL is found, you can use the Find Usages feature in JADX to see every method that interacts with that server.

pythonAutomated Endpoint Extraction Script

1import os
2import re
3
4# A simple script to crawl decompiled source for potential API endpoints
5def extract_endpoints(directory_path):
6    # Regex to find patterns like "https://api.example.com/v1/..."
7    url_pattern = re.compile(r'"https?://[\w\.-]+(?:/[\w\.-]*)*"')
8    
9    for root, dirs, files in os.walk(directory_path):
10        for file in files:
11            if file.endswith(".java") or file.endswith(".smali"):
12                with open(os.path.join(root, file), 'r') as f:
13                    content = f.read()
14                    matches = url_pattern.findall(content)
15                    if matches:
16                        print(f"Found in {file}: {matches}")
17
18# Example usage pointing to the JADX output folder
19extract_endpoints('./decompiled_source/sources')

Deciphering Custom Request Headers

Advanced APIs often require custom headers for security, such as HMAC signatures or unique device identifiers. These are calculated at runtime using specific logic hidden within the binary. By locating the interceptor classes in the code, you can reverse the algorithm used to generate these tokens.

Look for classes that implement the Interceptor interface if the app uses OkHttp. These classes have an intercept method where the request is modified before being sent. Reversing this logic is the key to successfully replaying or spoofing API requests outside of the mobile application.

The iOS Perspective and Mach-O Analysis

Reversing iOS applications presents different challenges because they are compiled to native machine code for ARM64 architectures. Unlike the intermediate bytecode of Android, iOS binaries must be analyzed using disassemblers. This requires a deeper understanding of assembly language and the Objective-C or Swift runtime.

The first step is often decrypting the application binary, as apps downloaded from the App Store are encrypted with FairPlay DRM. Tools like Clutch or Frida-ios-dump are used on jailbroken devices to dump the decrypted Mach-O file. Once decrypted, the binary can be loaded into tools like Hopper Disassembler or Ghidra.

iOS apps written in Objective-C are particularly verbose in their metadata. Even in compiled form, the binary contains the names of classes and methods. This allows researchers to search for terms like API, Client, or Network to find the logic responsible for communicating with the backend.

Analyzing Swift Binaries

Swift is more difficult to reverse than Objective-C because it does not rely as heavily on dynamic message passing. However, Swift still leaves clues in the form of name mangling and metadata. Dedicated Swift demanglers can help turn complex symbols back into readable function signatures.

Focusing on the imports is a highly effective strategy for iOS. If an application imports the Network or Foundation frameworks, you can set breakpoints on common networking functions like URLSession. This allows you to inspect the arguments and discover the endpoints being targeted during execution.

Capturing and Analyzing Encrypted API Traffic with MITM Proxies Bypassing SSL Pinning and Security Controls via Dynamic Instrumentation