Device & systemSecurity & malware
ADB Backup Format: backup.ab Files
The Android ADB backup .ab format: header, zlib tar stream, AES-256 encryption with PBKDF2, app folder layout, Android 12 limits and hashcat mode 18900.
- Location
- Examiner workstation: the file written by adb backup -f <name>.ab (not stored on the device)
- Proves
- The private data (databases, shared preferences, files) of apps that allow backup, optionally their APKs and shared storage, as the device held them when the backup ran
- Timestamps
- No global timestamp in the header; tar entries carry file modification times in Unix seconds; the app data inside keeps its own formats
- Access
- Logical: needs an unlocked phone, USB debugging and on-screen confirmation. Since Android 12, excludes apps targeting API 31+ unless debuggable; apps with allowBackup=false are always excluded.
- Retention
- A point-in-time copy created by the examiner; nothing is kept on the device
- Collection
- adb backup -f case.ab -apk -shared -all -system, adb backup -f case.ab <package>
Tools
Compare all toolsWhat it is
adb backup is Android's original full-backup-to-computer feature. The workstation asks the device's backup manager for app data, the user confirms on the phone (optionally setting a password), and the data streams back over ADB into a single .ab file. It was long a cheap route into app sandboxes without root, and the basis of the APK downgrade technique.
It still exists on Android 16 but has been deprecated since Android 12, and its reach has shrunk: since Android 12, data of apps that target API level 31 or higher is excluded unless the app is debuggable. On a current phone an ADB backup mostly yields shared storage, a few older apps, and some system data. Understanding the format still matters, because examiners receive .ab files from older cases, from downgrade workflows, and from tools that wrap them.
Where it lives
The .ab file is created on the workstation, not on the phone. Its internal layout:
| Part | Content |
|---|---|
| Line 1 | ANDROID BACKUP |
| Line 2 | Format version (1 to 5; Android 8 and later write 5 on the builds examined) |
| Line 3 | Compression flag: 1 zlib-compressed, 0 not |
| Line 4 | Encryption: none or AES-256 |
| Lines 5 to 9 (encrypted only) | User password salt, master key checksum salt, PBKDF2 rounds, user key IV, encrypted master key blob (hex) |
| Rest | Tar stream (zlib-compressed and optionally AES-256-CBC encrypted) |
Inside the tar, each app has a folder apps/<package>/ with a _manifest and subfolders: a/ APK, db/ databases, sp/ shared preferences, f/ files, r/ other files in the data root, ef/ external files, k/ key-value backup data, obb/. Shared storage (with -shared) is under shared/0/.
What it proves
- The contents of included apps' private storage at backup time: SQLite databases, preferences, files.
- Which packages allowed backup, which already reveals something about their age and configuration.
- With
-apk, the exact APK versions installed.
It does not include apps that opted out or target API 31+ (Android 12+), system databases such as the telephony provider on most builds, or deleted data outside the copied files. Anything that exists only in a -wal file may be missing if the app checkpointed before backup.
Key fields
| Header field | Meaning |
|---|---|
| Version | 1 initial; later versions changed the key derivation string encoding and added features |
| Compression | Almost always 1 |
| Encryption | AES-256 when the user set a password |
| PBKDF2 rounds | 10,000 on standard builds |
| Master key blob | Master key IV, master key and checksum, encrypted with the password-derived key |
Timestamps
The header has no creation time: record the time of the backup in your notes and hash the file immediately. Tar headers keep each file's modification time (Unix seconds), which usually reflects the file on the device. Timestamps inside the app databases keep their native formats.
head -c 64 case.ab | xxd | head -4 # inspect the header
# Unencrypted and compressed: skip the 24-byte header and inflate
dd if=case.ab bs=24 skip=1 2>/dev/null | python3 -c "import sys,zlib; sys.stdout.buffer.write(zlib.decompress(sys.stdin.buffer.read()))" > case.tar
# Or with Android Backup Extractor (handles encryption):
java -jar abe.jar unpack case.ab case.tar [password]
The 24-byte skip only works for an unencrypted version 1 to 5 header with a single-digit version; use Android Backup Extractor otherwise.
Retention
The file is a static snapshot kept by the examiner. On the device, nothing persists except the fact that a backup was requested (visible in logs for a short time) and the confirmation the user saw.
Collection
adb backup -f case.ab -apk -shared -all -systemfor everything the device will release, or name specific packages.- The user must confirm on screen; leave the password empty unless policy requires one, and record it if set.
- Hash the
.abimmediately and keep it unmodified; unpack copies. - For the APK downgrade technique, document every change: it alters the device.
Parsing
- Hash Extractor turns the header of an encrypted
.abinto a$ab$hash in the browser, for hashcat (mode 18900) or John the Ripper, when you are authorised to recover the password. - Android Backup Extractor (
abe) decrypts and converts.abto tar, and packs tar back to.ab. - ALEAPP and commercial suites process the resulting tar like a partial file system.
Investigator tips
- Check first which apps allow backup:
dumpsys package <pkg>showsALLOW_BACKUPin the flags and the target SDK. - An empty or tiny
.abon Android 12+ is expected, not a failure; state it in the report and move to a full file system extraction if the case needs app data. - Record the device's build and patch level with the backup: the same command reaches very different data on Android 11 and 12.
- The acquisition guide places ADB backup among the other methods.