Mobile Pentesting 101 – The Death of ADB Backup: Modern Data Extraction in 2026

Mobile security, Penetration Testing Leave a comment

For a long time, the adb backup command was the “Swiss Army Knife” for mobile pentesters. It allowed us to pull the private /data/data/ folder of an application without needing root, making it a staple for analyzing local databases, shared preferences, and session tokens. However, with the release of Android 12 (API 31), Google introduced a major security shift: the command now excludes app data by default unless the app is specifically marked as debuggable.

As we move into 2026, many production apps are now “invisible” to the standard backup path. In this article, we’ll explore how to bypass these restrictions using four modern methods, and how we’ve integrated these into MMSF (Massive Mobile Security Framework) to automate the process.

The Challenge: The Deprecated Sandbox

In modern Android versions (12 through 16), setting android:allowBackup="true" in the manifest is no longer enough for adb. While it still allows Cloud or Device-to-Device (D2D) transfers, the adb binary is restricted for security reasons. To extract data today, we must leverage deeper shell mechanics or manifest manipulation.

The next screenshots show that no data is extracted on an Android 13 using the classic adb backup.

Running the basic adb backup
Note the empty directories

Method 1: The Rooted Path (Direct Extraction)

If your testing environment uses a rooted device or a rooted emulator (like Genymotion), you can bypass the Android sandbox entirely. This is the most reliable method for 100% data integrity during a forensic or deep-dive assessment.

The Workflow:
We use su to elevate privileges and then tar the private directory directly from the filesystem. This is extremely fast and avoids the encryption overhead of .ab files.

# Direct extraction via root
adb shell "su -c 'tar -cvf - /data/data/com.target.app'" > app_data.tar
  • Pros: Fast, silent, and works on 100% of apps.
  • Cons: Requires a rooted device, which isn’t always the best choice due to protections in production assessments.

Method 2: The run-as Solution (The Debuggable Path)

The run-as command is the “goldilocks” solution for non-rooted devices. It allows you to execute commands within the app’s own sandbox, inheriting its permissions.

The Requirement:
The application must have android:debuggable="true" in its manifest. If you are testing a “Pre-Prod” or “UAT” build, this is likely already enabled.

The Command:

adb shell "run-as com.target.app tar -cvf - ." > private_data.tar
  • Pros: No root required, no UI prompts, and perfectly clean extraction.
  • Cons: Fails on 99% of production Play Store apps as those have debugging disabled.

Method 3: The Patch & Re-sign Attack (The Bridge)

When dealing with a production app that is not debuggable, we have to create our own “escape hatch”. This involves modifying the APK to grant ourselves the necessary permissions, but of course, this implies data loss as the previous application should be uninstalled.

The Workflow:

  1. Decompile: apktool d target.apk -o source
  2. Patch: Add android:debuggable="true" to the <application> tag in AndroidManifest.xml.
  3. Rebuild & Sign: apktool b source -o patched.apk followed by signing with uber-apk-signer.
  4. Reinstall: adb install -r -d patched.apk (the -r flag is critical to keep the existing data).

Once patched, you can return to Method 2 and use run-as to extract the data silently.

The application is not initially debuggable
Without the original certificate, you must uninstall the application first
After installing back the application, the backup can now be extracted using the run-as method
Contents of the Backup

Method 4: Legacy Backup with UI Automation

If you have a patched app or an app where both allowBackup and debuggable are enabled, the old adb backup command still works. However, it requires a physical button press on the device. In 2026, we automate this using the built-in uiautomator tool.

The Automation Logic:
We start a background thread that dumps the UI XML, parses the coordinates for the “Back up my data” button, and taps it automatically.

# Helper to automate the button press
def _auto_confirm():
    # Dump UI and find the button center
    subprocess.run("adb shell uiautomator dump /data/local/tmp/ui.xml".split())
    # ... regex parsing of the 'bounds' attribute ...
    adb_shell("input tap <center_x> <center_y>")

This turns a manual, interactive process into a fully automated one-liner.

mmsf (ng-backup)> usemodule legacy
mmsf (ng-backup/legacy)> run
[+] Extracted to /Users/john/.mmsf/loot/data
mmsf (ng-backup/legacy)>
Patch the application to contain both flags: allowBackup and debuggable
Backup process is starting
Backup is extracted

MMSF Integration: Automating the NgBackup

In MMSF, we’ve encapsulated these methods into the NgBackup module. You don’t need to manually run uiautomator or tar commands anymore; the framework handles the logic based on the device state.

How to use the module:

  1. Load the module:
mmsf> usemodule ng-backup
mmsf (ng-backup)> usemodule rooted
  1. Configure the target:
mmsf (ng-backup/rooted)> set
mmsf (ng-backup/rooted/set)> app com.st3v3nss.mockbankingapp
  1. Execute:
mmsf (ng-backup/rooted/set)> run

What happens under the hood?

MMSF ng-backup offers four specialized extraction methods that you can select based on the target environment:

  • Rooted extraction directly streams app data via su -c tar for full filesystem access. run-as extraction leverages the debuggable flag to access app sandboxes without root.
  • The run-as command allows you to execute commands within the app’s own sandbox, inheriting its permissions, but debuggable flag is required.
  • Patch extraction automatically pulls the APK, decompiles it, injects android:debuggable="true" into the manifest, rebuilds, signs, and reinstalls it, then extracts via  run-as.
  • Legacy extraction uses the deprecated  adb backup with UI automation that automatically presses the confirmation button, then unpacks the result using  abe.jar  (Android Backup Extractor).

Each method produces a readable folder structure containing databases, SharedPreferences, and files ready for analysis.

Conclusion

The death of the classic adb backup isn’t the end of app data extraction; it’s just an evolution. By combining APK Patching with UI Automation, we can maintain the same level of visibility in 2026 that we had a decade ago. For those using MMSF, this entire workflow is now just a single run command away.

You can get the MMSF from GitHub: https://github.com/St3v3nsS/MMSF/.

Leave a Reply