ADB is the backup method Android examiners use when nothing else works.

That’s not a knock on it. In the real world, you won’t always have root access, a rooted test device for your extraction tool, or the luxury of chip-off physical extraction. Sometimes you have an Android phone, a USB cable, and ADB — and that has to be enough.

But “enough” means different things depending on the case. ADB backup gives you a specific, well-defined slice of device data. Going in with accurate expectations about what’s included and what’s been locked out since Android 11 is what separates an examiner who reports useful findings from one who misses evidence and doesn’t know it.

What ADB Actually Is

Android Debug Bridge is a command-line tool that’s part of the Android SDK. It’s Google’s own developer tool, originally built for app development and testing. For forensic purposes, its backup functionality is what matters.

The ADB backup command creates an archive of app data, including some databases, settings, and media. The output is a .ab file (Android backup format), which is a compressed archive of the device’s app data in a specific directory structure.

Running a backup:
“
adb backup -apk -shared -all -f device_backup.ab
`

Breaking down the flags:

The device will display a confirmation prompt. The user or examiner must tap "Back up my data" on the device screen to proceed. This is important — ADB backup requires physical interaction with the device. You can't run it silently.

If the device is locked and you don't know the passcode, ADB backup is unavailable.

What ADB Backup Captures
Each evidence source provides a different perspective on digital activity, strengthening forensic conclusions when correlated.

What ADB Backup Captures

Here's what's actually in the output when ADB backup runs:

App data directories. For each app that permits backup, ADB captures the app's data directory — which typically includes SQLite databases, shared preferences (XML settings files), and sometimes cache. This is where the message databases for apps like SMS managers, some email clients, and certain social apps live.

APK files (with -apk flag). The installed application packages. Useful for confirming which version of an app was installed, which matters when app version affects database schema interpretation.

Shared storage (with -shared flag). The device's "shared" storage — effectively the internal storage area equivalent to an SD card. This includes the Downloads folder, DCIM (camera photos and videos), and other user-accessible directories. On most Android devices, this is where WhatsApp media, downloaded documents, and similar files live.

What ADB backup does NOT capture:

That native SMS database exclusion is particularly significant. If you're trying to capture text messages from an Android phone via ADB, the standard adb backup command won't get you the SMS database in most current Android versions. There are workarounds (some third-party SMS apps back up their own databases; SMS backup apps can create exportable files) but they require pre-existing setup or cooperation from the device owner.

Android 11 and Scoped Storage: The Landscape Changed

Android 10 introduced scoped storage restrictions; Android 11 made them mandatory for all apps targeting API level 30 and above. This fundamentally changed what ADB backup can reach.

Before Android 11: Apps could read and write to shared external storage freely. ADB backup with -shared captured a broad swath of external storage content.

After Android 11: Apps are restricted to their own directories in shared storage (e.g., Android/data/com.example.app/) unless they request broad storage access permissions, which requires user approval and isn't granted to most apps. The broader external storage is still accessible to ADB's -shared flag, but apps no longer dump their data there freely.

What this means for your extraction:

The -shared flag still captures the accessible external storage content — downloads, camera media, and files placed there by apps with appropriate permissions. But app-specific databases and sensitive data that used to appear in external storage (a pattern from older Android versions) are less likely to be there on modern Android. That data is now in app-private directories under scoped storage, which ADB backup only captures when the app allows backup.

Additionally, the adb backup command itself was deprecated in Android 12+ (though it still works in many cases). Google's official stance is that ADB backup is a legacy feature. It continues to function in practice, but its behavior can vary across Android versions, manufacturer customizations, and device security policies.

Decoding the .ab File
Forensic analysis requires systematic documentation and cross-referencing of multiple artifact sources.

Decoding the .ab File

The .ab file ADB produces is not directly readable. It's a compressed archive wrapped in a custom header. Forensic tools handle this automatically, but understanding the structure matters for manual work.

The file format: 5-line ASCII header followed by a zlib-compressed tar archive. To extract manually:

`python

Strip the 5-line header and decompress

import zlib
with open('device_backup.ab', 'rb') as f:
# Skip the header (find the zlib magic bytes 0x78 0x9C)
data = f.read()
zlib_start = data.index(b'x78x9c')
decompressed = zlib.decompress(data[zlib_start:])
with open('backup.tar', 'wb') as out:
out.write(decompressed)
`

If the backup was created with encryption (the user set a backup password on the device), the content is AES-256 encrypted and you need the password. Without it, decryption is not practically feasible.

Forensic tools like Magnet AXIOM and Cellebrite UFED both handle ADB backup file ingestion natively, decoding the format and parsing the contained app data automatically. For most examinations, use your forensic tool rather than manual extraction.

When ADB Is the Only Option

Real-world scenarios where ADB becomes the primary or only extraction method:

Newer Android devices without a supported physical extraction path. Not every Android device has a supported physical extraction method in your tool's current version. Some devices from smaller manufacturers, some locked bootloaders, and some chipsets simply don't have a path to full physical extraction with available tools. ADB gets you something.

Cooperating custodians in civil matters. When a device owner agrees to produce data and you're working through civil discovery protocols, ADB backup executed with the custodian's cooperation is a documented, defensible method. No bypass, no invasive tools — just the owner's own backup mechanism.

When root access is unavailable and time is constrained. Root access acquisition on Android requires either an unlocked bootloader (which wipes data), a specific chipset vulnerability, or EDL (Emergency Download) mode access — none of which are quick. ADB backup is fast.

Older Android devices with more permissive backup policies. On Android 9 and earlier, ADB backup captured more data. If you're examining an older phone that hasn't been updated, ADB may produce more useful output than it would on a current-generation device.

Documenting ADB Extraction for Legal Use

ADB backup's documentation requirements are straightforward but non-negotiable for evidentiary use:

Before extraction:

During extraction:

  • Screenshot the device screen showing the backup prompt and confirmation

  • Note any password set on the backup

  • Record start and end time

After extraction:

  • Hash the .ab file immediately (SHA-256)

  • Document the hash in your chain of custody log

  • Copy to evidence storage and verify hash on destination

  • Record the file size

The key documentation challenge with ADB is explaining what it does and doesn't capture. Your examination report should explicitly state that ADB backup captures app data for apps that permit backup, does not include the system partition, and does not include app data from apps that have opted out. Opposing counsel will ask what you didn't get. Have that answer ready.

ADB vs. Commercial Tools: Knowing When to Upgrade

ADB backup is a legitimate forensic method, but it's not the only logical option for Android. Commercial tools offer additional capabilities:

Cellebrite UFED for Android: Beyond ADB backup, UFED offers advanced ADB extraction modes that can reach more data than standard ADB, device-specific physical extraction methods, and Android file system acquisition on some devices.

Android File System Acquisition via ADB shell: If the device has developer options enabled and ADB is authorized, advanced examiners can use adb shell commands to copy specific files rather than relying on the backup mechanism. This requires knowing exactly what you're after and can reach some files that the backup command misses.

Root-based extraction: If the device can be rooted without data loss (some manufacturer-specific methods preserve data), root access opens the full file system. This is device-specific and often impractical.

EDL (Emergency Download) Mode: Qualcomm chipset devices can sometimes be accessed via EDL mode for physical extraction. Requires specialized tools and device-specific loaders.

ADB backup sits at the bottom of the capability ladder. Know what it gives you, know what's above it in the hierarchy, and know when the case requires climbing higher.

FAQ

Q: Can I run ADB backup without the device passcode?

No. ADB backup requires the device to be unlocked and Developer Options/USB debugging to be enabled. If the device is locked and you don't know the passcode, ADB backup is not available. USB debugging also needs to have been previously enabled — you can't enable it on a locked device.

Q: Does ADB backup capture WhatsApp messages?

It depends. WhatsApp on Android can back up via ADB, but the behavior varies by WhatsApp version. The main database (msgstore.db) may or may not be included. WhatsApp's media folder in external storage will typically be captured by the -shared` flag. For reliable WhatsApp forensics, physical extraction with root access is preferred. See the full guide on WhatsApp artifact parsing across Android and iOS for more detail.

Q: How do I verify the integrity of an ADB backup file over time?

SHA-256 hash at time of acquisition is your baseline. Any subsequent verification hashes the file and compares against the documented original. Store the hash separately from the file itself — in your case management system or chain of custody log. Some examiners also compute MD5 alongside SHA-256 for additional redundancy, though SHA-256 alone is considered sufficient.