Binary Reversing: Ghidra & Binary Ninja Techniques

This skill defines binary analysis techniques for MobHunt hunter agents. It covers Ghidra headless analysis (primary) and Binary Ninja (optional) for both iOS Mach-O and Android ELF binaries.

Ghidra Headless Analysis

MobHunt uses Ghidra in headless mode via tools/binary_analysis/ghidra_analyze.sh. The script runs platform-specific Ghidra scripts that extract security-relevant data.

Running Analysis

# iOS binary analysis
bash tools/binary_analysis/ghidra_analyze.sh \
  --binary workspace/<target>/ios/decrypted/<executable> \
  --platform ios \
  --output recon/<target>/

# Android native library analysis
bash tools/binary_analysis/ghidra_analyze.sh \
  --binary workspace/<target>/android/extracted/apktool/lib/arm64-v8a/<lib>.so \
  --platform android \
  --output recon/<target>/

Environment

• GHIDRA_HOME: Installation directory (default: ~/Library/ghidra/12.0.4)
• GHIDRA_HEADLESS: Path to analyzeHeadless (auto-detected from GHIDRA_HOME/support/)
• GHIDRA_TIMEOUT: Analysis timeout in seconds (default: 600)

What the Scripts Extract

iOS Script (ghidra_ios_script.java):

• Objective-C class and method lists
• Swift demangled symbols
• Crypto API calls (CCCrypt, SecKey*, CC_MD5, CC_SHA*)
• Keychain API usage (SecItemAdd, SecItemCopyMatching)
• URL scheme handlers
• String cross-references for sensitive patterns
• Function call graphs for security-critical paths

Android Script (ghidra_android_script.java):

• JNI exported functions (Java_* naming convention)
• Crypto function calls (OpenSSL, BoringSSL)
• String references (URLs, keys, paths)
• Dangerous function usage (system, exec, dlopen)
• Memory-unsafe function calls (strcpy, sprintf, gets)
• Symbol exports and imports

Function Classification

After Ghidra analysis, classify functions by security relevance:

python3 tools/binary_analysis/function_classifier.py \
  --results recon/<target>/*_ghidra_results.json \
  --output recon/<target>/

Classification Categories

Hunters should focus on crypto, network, auth, and dangerous categories first.

iOS Binary Reversing

Objective-C Runtime Analysis

Objective-C binaries contain rich metadata exploitable for analysis:

# List classes
otool -o <binary> | grep "name 0x" | head -50

# List methods per class (in Ghidra)
# Navigate to __objc_methnames section

Key classes to investigate:

• *ViewController with webView properties: WebView attack surface
• *APIClient, *NetworkManager: network configuration
• *KeychainManager, *SecureStorage: data protection
• *AuthManager, *LoginController: authentication flow
• *DeepLinkHandler, *URLRouter: IPC entry points

Swift Binary Analysis

Swift binaries are harder to reverse but contain type metadata:

# Swift demangling
swift demangle 's4MyApp10AuthTokenCV'
# → MyApp.AuthTokenC

Swift-specific patterns in Ghidra:

• Swift metadata in __swift5_* sections
• Protocol witness tables reveal implemented protocols
• Generic specializations may contain type information

Crypto Function Tracing

In Ghidra, trace from crypto API calls to understand:

1. What algorithm: Find CCCrypt calls → check algorithm parameter:
   • 0 = AES, 1 = DES, 2 = 3DES, 10 = RC4, 11 = RC2
2. What mode: Check options parameter for ECB (1) vs CBC/other
3. Key source: Trace the key parameter backward. Hardcoded? Derived? Random?
4. IV source: Trace the iv parameter. Static? NULL? Random?

Finding criteria:
- DES/3DES/RC4/RC2 for any security purpose → FINDING
- ECB mode for multi-block encryption → FINDING
- Hardcoded key bytes → FINDING (extract the key value)
- NULL or static IV → FINDING if used with CBC
- MD5 for authentication/integrity → FINDING (not for checksums)

Android Native Library Reversing

JNI Function Analysis

JNI exports follow a strict naming convention:

Java_<package>_<class>_<method>

with dots replaced by underscores and special characters mangled.

Analysis steps:

1. List JNI exports: nm -gD <lib.so> | grep "Java_"
2. In Ghidra, navigate to each JNI function
3. Check parameter handling:
   • GetStringUTFChars: is the result length-checked?
   • GetByteArrayElements: is the array length validated?
   • FindClass / GetMethodID: what Java methods does native code call?

Anti-Reverse Engineering Checks

Native libraries may contain anti-tampering:

• ptrace(PTRACE_TRACEME): anti-debugging
• /proc/self/maps reading: instrumentation framework detection
• Signature verification via JNI callback to Java
• Checksum verification of DEX files

These are NOT security findings. They are defensive measures.

String Analysis in Native Code

# Extract strings from .so
strings -a <lib.so> | grep -E "(http|key|token|password|secret|api)"

Native libraries often contain hardcoded secrets that developers assume are "hidden" by being in native code. They are not; strings and Ghidra find them.

Binary Ninja Analysis (Optional)

If analysis.binary_analyzer is set to "binja" in config:

python3 tools/binary_analysis/binja_analyze.py \
  --binary <path> \
  --platform ios|android \
  --output <dir>

BN provides similar capabilities to Ghidra with different strengths:

• Better Swift demangling and type recovery
• Faster analysis for large binaries
• HLIL (High Level IL) for more readable decompilation
• Python scripting API for custom analysis

The output format matches Ghidra's JSON schema for downstream compatibility.

Common Binary Findings

Hardcoded Secrets

Authorization boundary: extracting a secret from a binary you hold is static analysis; sending it anywhere is testing. Run any of the checks above only when the service is covered by the program's stated scope, and, when it is third-party hosted (AWS, Google, Firebase, and similar), only with the program's written permission. The account belongs to the program, and the provider never agreed to your test. Where that authorization is absent, keep the check static.

Rule: Every secret finding must say what the secret is and what access it grants. Where a permitted live check ran, report its result. Where none was permitted, report the provider's documented privileges for that key type and ask the program to confirm whether the key is active. A key confirmed expired or confirmed restricted to nothing sensitive is not a finding; an unconfirmed key is still a finding, at lower confidence.

Weak Cryptography

Missing Binary Protections

Modern platform rule: iOS 15+ and Android 10+ enforce most binary protections at the OS level. Missing protections are only findings on older platform versions or when the app explicitly disables them.

Analysis Workflow

1. Start with strings: Extract and review strings before deep reversing. Most secrets are findable with strings alone.
2. Classify functions: Use function_classifier.py to identify security-relevant functions.
3. Trace crypto paths: For each crypto call, trace key source and data input.
4. Check JNI boundaries (Android): Every JNI export is an attack surface if Java layer passes user-controlled data.
5. Time-box: Spend no more than 15 minutes per binary on deep reversing. If nothing surfaces from strings + function classification, move on.
6. Document offsets: For every finding, record the binary offset and function name so the validator and report writer can reference it.