user@shadowpbx: ~/cyber/posts$ cat writeup.md

Mobile Application API Interception and Reverse Engineering: A Step-by-Step Case Study

In modern mobile application security auditing, understanding client-server communication is critical [1]. While developers secure application traffic using encryption protocols like HTTPS, security researchers and analysts must often reverse-engineer these endpoints to verify backend validation, check for vulnerabilities, and inspect data transmission [2].

This article documents the practical, step-by-step methodology used to analyze a production Android application, transitioning from raw packet capture to full application-layer API decryption and static analysis.

Phase 1: Environment Setup and the Rooting Constraint

The analysis began with a standard Android Virtual Device (AVD). However, attempting to intercept traffic on a default emulator image presents a major technical challenge:

To proceed, the application's split APK files were pulled from the standard emulator to the local Linux host so they could be reinstalled on a developer-friendly testing environment.


Phase 2: Preparing a Writable Developer Environment

To bypass the production environment restrictions, a new emulator image was configured in Android Studio:

  1. Creating a Google APIs Image: A new AVD was created using a Google APIs system image instead of a Google Play image, allowing debug capabilities.
  2. Launching with Write Permissions: The emulator was started from the Linux terminal with a writable system partition: bash /home/shad/Android/Sdk/emulator/emulator -avd Your_Google_APIs_AVD -writable-system
  3. Elevating Privileges and Remounting: To write files to the system root, Android's integrity verification (dm-verity) was disabled, and the partitions were remounted as read-write: bash adb root adb remount adb reboot After the reboot, running adb root and adb remount successfully unlocked the /system/etc/security/cacerts/ directory.

Phase 3: Dynamic Interception & HTTPS Decryption

With a writable, rooted emulator active, an interception tool was introduced to act as a Man-in-the-Middle (MitM) proxy [2].

  1. Automating Certificate Injection with HTTP Toolkit: HTTP Toolkit was launched on the Linux host. Using the "Android Device via ADB" feature, the tool detected the root access and writable partition [1]. It automatically injected its custom decryption CA directly into the emulator’s system certificate store [1].
  2. Installing the Target App Splits: The original split APKs of the grocery application (Chaldal) were pushed to the emulator together to prevent resource mismatches or splash-screen crashes: bash adb install-multiple *.apk
  3. Observing Live API Streams: Upon launching the app, the proxy successfully decrypted the TLS connection. Real-time traffic analysis revealed:
  4. Structured JSON Endpoints: Secure POST requests, such as https://catalog.chaldal.com/searchPersonalized, transmitting search queries, API keys, and device identifiers.
  5. Real-time WebSockets: A live bidirectional WebSocket connection (wss://groceryintegration-api.chaldal.com/api/v1/realTime) used to sync inventory and cart updates without page refreshes.

Phase 4: Raw Packet Analysis

To study the network mechanics beneath the application layer, Wireshark was deployed on the Linux host.

  1. Resolving GUI Performance Freezes: Initially, capturing on the host's any interface flooded the Wireshark GUI with background system traffic, causing the application to stop responding. This was resolved by:
  2. Disabling network name resolution in Wireshark preferences.
  3. Utilizing a strict Capture Filter rather than a Display Filter to discard noise at the kernel level: text net 103.185.176.0/23
  4. Infrastructure Identification: A WHOIS lookup on the captured destination IP range (103.185.176.0/23) confirmed the servers belonged directly to the application's infrastructure.
  5. Analyzing the Transport Layer: Wireshark displayed the initial unencrypted TLS Client Hello handshakes, revealing Server Name Indication (SNI) details before the subsequent transmission of encrypted Application Data packets.

Phase 5: Static Analysis and Secret Extraction

In addition to dynamic traffic analysis, static analysis was performed directly on the application's binaries to inspect the code structure and extract embedded assets.

  1. Code Decompilation (Jadx-GUI): Jadx-GUI was used to decompile the Dalvik Executable (DEX) files back into readable Java and Kotlin code. This allowed for the inspection of the application’s core classes, including network request formatting and tracking headers.
  2. Automated Security Auditing (MobSF): Mobile Security Framework (MobSF) was run to perform static analysis. It scanned the codebase for common security misconfigurations, insecure permissions, and hardcoded secrets.
  3. Certificate and Key Extraction: To locate cryptographic keys and certificates embedded within the assets, a specialized scanning utility was run. While several tools perform this function, typical choices in this workflow include:
  4. APKleaks: A tool designed to scan decompiled APKs for URIs, endpoints, and hardcoded API keys.
  5. Keytool: Used to inspect the application's signing certificates within the META-INF directory.
  6. MobSF's Static Analyzer: Which automatically parses and displays certificates, hardcoded keys, and sensitive string variables found inside the unpacked archive.

Phase 6: Replicating the API and Automation

Once the dynamic payloads were understood, the application's dependency on the Android UI was bypassed entirely.

  1. Replicating the Request: Using the headers and JSON payload captured during interception, a curl command was executed from the Linux terminal to query the search API directly.
  2. Automating Queries: A Python script utilizing the requests library was written to programmatically search the catalog and output real-time inventory and pricing data directly to the command line, completing the cycle of API reverse-engineering.

This thread covered a diverse set of tools, ranging from professional security proxies to command-line network utilities and Android developer tools.

The following is a comprehensive, categorized list of every tool used, discussed, or referenced in our workflow:

1. Network & Proxy Interception Tools (The "Middlemen")

2. Reverse Engineering & APK Patching Tools

3. Secret Extraction & Static Analysis Tools

4. Packet Sniffers & Network Diagnostics

5. Android SDK & Device Utilities

6. Linux Shell & System Commands