Module 7 — Advanced Dynamic Analysis with Objection

Important Reminder: Everything in this module must be practiced only in authorized labs, with vulnerable APKs or applications you have written permission to test. The tools and techniques here are powerful and can alter app behavior at runtime. They should never be used on production systems or customer data.

7.0 Learning Objectives

By the end of this module, you will be able to:

  • Explain what Objection is and how it builds on Frida.
  • Safely set up and run Objection in a lab environment.
  • Use Objection’s built-in commands for quick dynamic analysis of Android apps.
  • Explore storage, preferences, and in-memory data at runtime.
  • Interact with runtime methods without writing custom Frida scripts.
  • Test application defenses such as root detection and certificate pinning.
  • Collect reproducible evidence from Objection sessions.

7.1 What is Objection?

Objection is a runtime mobile exploration toolkit built on top of Frida. It provides:

  • An interactive CLI with ready-made commands.
  • High-level abstractions that save time (e.g., dumping SharedPreferences, bypassing SSL pinning in labs).
  • Both Android and iOS support, with an emphasis on runtime inspection and manipulation.

In short: Frida = instrumentation engine, Objection = prebuilt lab operator interface.

7.2 Lab Setup (Safe Environment)

  1. Install Objection on host: pip3 install objection
  2. Verify Frida compatibility:
    • Objection requires that Frida client and server versions match.
    • Check with frida --version and ensure the same server version is on the device.
  3. Device preparation:
    • Use an emulator or a lab device.
    • Deploy frida-server as explained in Module 6.
  4. Test connection: adb devices frida-ps -U Both should list the device and running apps.

7.3 Launching an App with Objection

To start an analysis session:

objection -g com.vulnlab.app explore

This command:

  • Spawns the target app (-g flag).
  • Injects Frida.
  • Opens an Objection interactive shell with preloaded commands.

7.4 Core Objection Commands (Android Labs)

7.4.1 Process Information

env
env path
  • Shows app environment variables, directories, and paths.
  • Helps you locate databases and storage.

7.4.2 File System and Storage

android ls /data/data/com.vulnlab.app/
android cp /data/data/com.vulnlab.app/shared_prefs/UserData.xml .
  • Enumerates internal directories.
  • Dumps SharedPreferences (commonly store tokens and flags).
android heap search string password
  • Searches heap for sensitive strings like “password”.

7.4.3 Shared Preferences

android sharedpreferences list
android sharedpreferences print com.vulnlab.app_preferences.xml
  • Lists available SharedPreferences files.
  • Prints key-value pairs directly.

7.4.4 Database Inspection

android sqlite list
android sqlite connect UserData.db
sqlite> .tables
sqlite> SELECT * FROM users;
  • Finds SQLite DBs.
  • Connects and queries them live inside the app.

7.4.5 Runtime Method Exploration

android hooking list classes
android hooking search classes Login
android hooking search methods password
  • Enumerates loaded classes and methods.
  • Useful for quickly locating authentication functions.

7.4.6 Hooking & Method Invocation

android hooking watch class com.vulnlab.auth.LoginManager
android hooking set return_value com.vulnlab.security.RootCheck.isRooted false
  • Watches methods being called.
  • Changes return values in real-time (lab-only demonstration).

7.4.7 SSL Pinning (Lab Demonstration)

android sslpinning disable
  • Temporarily disables SSL pinning so traffic can be proxied in Burp during lab exercises.
  • Useful for validating whether pinning is enforced client-side.

7.4.8 Root Detection Bypass (Lab Demonstration)

android root disable
  • Disables common root detection libraries (RootBeer, custom checks).
  • Use only on test builds to evaluate robustness of anti-root controls.

7.5 Example Lab Workflow

Scenario: Testing a vulnerable banking lab app

  1. Launch app with: objection -g com.vulnbank.app explore
  2. Enumerate storage: android ls /data/data/com.vulnbank.app/ android sharedpreferences list
  3. Print SharedPreferences: android sharedpreferences print com.vulnbank.app_preferences.xml → Reveals auth_token.
  4. Hook login manager: android hooking search classes Login android hooking watch class com.vulnbank.auth.LoginManager → Logs credentials in real-time.
  5. Test SSL pinning bypass: android sslpinning disable → Confirm if API traffic can now be intercepted.

7.6 Anti-Instrumentation Considerations

Apps may attempt to block Objection/Frida:

  • By scanning loaded libraries.
  • By checking for method tampering.
  • By obfuscating class names.

Pentester’s role: Use Objection first for rapid wins, then fall back to custom Frida scripts when apps block Objection.

7.7 Evidence Collection

Always capture:

  • Commands used.
  • Console logs (copy entire Objection session).
  • Screenshots of intercepted data.
  • Hashes of APK version under test.
  • Device/emulator snapshot metadata.

This ensures findings are reproducible and defensible.

7.8 Practical Lab Exercises

Lab 7-A — Dumping Preferences

  • Target: InsecureBankv2 app.
  • Task: Locate and print SharedPreferences.
  • Evidence: JSON export of all keys and values.

Lab 7-B — Hooking Login

  • Task: Monitor LoginManager class for credentials.
  • Evidence: Objection console logs showing credentials flow.

Lab 7-C — SSL Pinning Validation

  • Task: Run app with Objection, test android sslpinning disable, confirm Burp captures API traffic.
  • Evidence: Burp log + Objection command transcript.

7.9 Best Practices & Pitfalls

  • Don’t rely only on Objection. It’s fast but limited. Some defenses require custom Frida scripts.
  • Be aware of false positives. Disabling SSL pinning in a lab doesn’t mean it’s bypassable in production — confirm server behavior.
  • Always validate evidence. Correlate Objection findings with proxy captures, logs, and code review.
  • Stay ethical. Never dump or modify production customer data.

7.10 Deliverables for Module 7

  • Objection Command Cheat Sheet (organized by functionality).
  • Lab Workflow Template (step-by-step procedure to reproduce results).
  • Evidence Package (example Objection logs + Burp captures + APK hash).
  • Comparison Chart: Objection vs. Frida (when to use each).

Key Takeaway: Objection is the fast-track toolkit for runtime analysis. It lowers the barrier to instrumentation by packaging common Frida hooks into ready-made commands. Use it to quickly extract storage, bypass defenses in labs, and observe runtime behavior. But remember: advanced cases still need Frida scripting.