Android Acquisition: Logical, ADB Backup, Bugreport, FFS

On a computer, "acquisition" usually means imaging a disk. On an Android phone it means choosing an extraction level, and that choice decides which evidence exists for the rest of the case. A logical pull over ADB will never contain WhatsApp's database; a bugreport will never contain an SMS body; a raw physical image of a modern phone is ciphertext. This guide explains what each method reaches on Android 8 to 16, what it changes on the device, and how file-based encryption and the lock state set the limits before you plug anything in.

Before you connect anything

Three facts about the handset determine every later option. Record them first, with photos of the screen where possible.

1. Lock state. Is the phone powered on, and has it been unlocked since its last boot? A phone in AFU (after first unlock) has its credential-encrypted keys in memory, even when the screen is locked again. A phone in BFU (before first unlock) only exposes device-encrypted storage. If you seize an AFU phone, keep it charging: a reboot or a flat battery sends it back to BFU for good unless you have the passcode.
2. Network isolation. Remote wipe, remote lock and incoming messages that overwrite or expire data are real risks. A Faraday bag or box stops radio traffic but makes the phone search for a signal and drain its battery faster, so combine it with a power bank. Airplane mode is an option only if the phone is unlocked and policy allows interacting with it; document it either way.
3. Build. Model, Android version, security patch level and build fingerprint determine which paths and formats apply and which extraction exploits exist. If the phone is unlocked, Settings > About phone gives them; over ADB, getprop does.

adb shell getprop ro.product.model
adb shell getprop ro.build.version.release        # e.g. 14
adb shell getprop ro.build.version.security_patch # e.g. 2026-08-05
adb shell getprop ro.build.fingerprint
adb shell date -u; date -u                         # device clock versus workstation clock
adb shell getprop persist.sys.timezone

Remember the legal side: examine only devices you are authorised to examine, and keep the scope of the authority (which apps, which period) in mind when choosing a method.

The extraction levels at a glance

The rest of this guide takes each method in turn.

Logical extraction over ADB

A logical extraction uses the Android Debug Bridge and the device's own APIs. It is the least invasive method and the one available on almost any unlocked phone.

Enabling it requires the phone to be unlocked: tap Build number seven times to show Developer options, enable USB debugging, connect, and accept the workstation's RSA key on screen. From then on you run commands as the unprivileged shell user.

What the shell user can reach directly:

• Shared storage: photos, videos, downloads, documents, and app folders under /sdcard/Android/media/ (WhatsApp's encrypted backups and media live there on current versions). Since Android 11, other apps (file managers included) can no longer read /sdcard/Android/data/, but the ADB shell usually still can: pull it explicitly and note if a build refuses.
• System state: getprop, dumpsys <service> for almost every system service, pm list packages -f -i -U for installed apps with their installers and UIDs, cmd interfaces.
• Content providers that grant the shell access: on some builds content query --uri content://call_log/calls works; on others the shell lacks the permission.

mkdir -p case0142/logical && cd case0142/logical
adb shell pm list packages -f -i -U > packages.txt
adb shell dumpsys package > dumpsys_package.txt
adb shell dumpsys usagestats > dumpsys_usagestats.txt
adb shell dumpsys account > dumpsys_account.txt
adb pull /sdcard/ ./sdcard/
sha256sum packages.txt dumpsys_*.txt > SHA256SUMS

Commercial suites and open-source collectors extend this with an agent app: an APK installed for the duration of the extraction and granted runtime permissions (SMS, call log, contacts, calendar), which reads the content providers and streams the results back. The data is the provider's current view: no deleted rows, no WAL residue, no app sandboxes. androidqf, from the MVT project, packages the ADB-based collection (packages, dumpsys, logs, a bugreport, and optionally APKs) into a single folder for later analysis.

Everything a logical extraction touches is documented in the installed packages and usagestats pages, which both have a live dumpsys route.

Bugreport

A bugreport is Android's own diagnostic bundle. It is generated by dumpstate and delivered as a zip:

adb bugreport case0142_bugreport.zip
unzip -l case0142_bugreport.zip | head

Inside you find a main text file (bugreport-<device>-<build>-<date>.txt) with the output of dumpsys for every system service, the logcat buffers (usually hours, sometimes a day or more), kernel logs, dumpstate_board data from the vendor, and a partial FS/ tree with files such as ANR traces. It can also be generated on the device from Developer options > Take bug report and shared, which helps when you cannot connect a workstation.

For an investigation the valuable sections are:

• dumpsys package: every installed package with firstInstallTime, lastUpdateTime, installer, requested and granted permissions.
• dumpsys usagestats: recent app foreground and background events, screen and keyguard events.
• dumpsys batterystats: per-app power use, wakelocks, and a history of radio and screen state.
• dumpsys account, dumpsys wifi, dumpsys notification, dumpsys activity (recent tasks), dumpsys telecom (a short call history with masked numbers).

A bugreport never contains message bodies or app database content. It does contain personal data (accounts, Wi-Fi names, notification text on some builds), so handle it as evidence. The Mobile Verification Toolkit (mvt-android check-bugreport) scans it for known spyware indicators, and Battery Historian turns the battery section into a readable timeline.

ADB backup

adb backup was designed for users to back up apps to a computer. It still exists, but it has been deprecated since Android 12 and its reach shrinks with every release:

• Apps that set android:allowBackup="false" are excluded, as they always were.
• Since Android 12, data of apps targeting API level 31 or higher is excluded unless the app is debuggable. On a current phone that is most of what matters.
• The user must confirm on screen, optionally setting a backup password.

adb backup -f case0142.ab -apk -shared -all -system

The result is a .ab file: a short text header (ANDROID BACKUP, format version, compression flag, encryption none or AES-256) followed by a zlib-compressed tar stream. Android Backup Extractor converts it to a plain tar (abe unpack case0142.ab case0142.tar [password]). If the backup was encrypted and the password is unknown but you are authorised to recover it, Hash Extractor turns the header into a $ab$ hash for hashcat (mode 18900) or John, entirely in the browser.

A common historical technique was the APK downgrade: temporarily replacing an app with an old version that allowed backup, backing it up, then restoring the current version. It alters the device, can lose data if anything fails, and on Android 14 and later the system refuses to install APKs targeting an API level below 23 unless adb install --bypass-low-target-sdk-block is used. Commercial tools still offer automated variants; document their use precisely if you rely on one.

Full file system extraction

A full file system extraction copies the file system as the running OS sees it, including /data/data/<package>/ for every app, /data/system/ and /data/misc/. Because the OS decrypts files as it reads them, the output is readable, which is why FFS is now the target level for most casework.

It needs privileged code on the device:

• Root, if the device is already rooted (by the user, or by a method you can justify). Do not unlock the bootloader of an evidence phone to root it: on current devices that wipes userdata.
• An exploit against the boot chain (for example chipset boot ROM or emergency download modes on specific MediaTek and Qualcomm platforms), the kernel or a system service. These are version and patch dependent and mostly packaged in commercial tools.
• An agent installed through ADB that gains temporary elevated privileges, collects and removes itself.

The lock state still applies. In AFU, an FFS reaches both CE and DE storage. In BFU, only DE storage is readable: the telephony provider's SMS and MMS database, the call log and Wi-Fi configuration typically sit in DE storage, while WhatsApp, Chrome, contacts and, from Android 11, usagestats are CE. Brute-forcing a passcode to move from BFU to AFU is a separate, tool-specific capability with its own legal and technical limits.

The deliverable is normally a tar or zip archive. It has no unallocated space, but deleted records inside SQLite databases (freelist pages and WAL frames) are preserved, so always keep each database with its -wal, -shm or -journal file. ALEAPP parses such an archive directly:

python aleapp.py -t tar -i case0142_ffs.tar -o case0142/aleapp/

Physical extraction

Physical extraction images partitions below the file system: through a bootloader or chipset exploit, JTAG or ISP connections to the board, or by desoldering the storage chip (chip-off). On phones from the full-disk-encryption era it was the gold standard, because it included unallocated space.

With file-based encryption, and the metadata encryption most devices launching with Android 11 or later add on top, a raw userdata image is ciphertext unless the keys can be recovered from the device's secure hardware, which is only possible for specific chipsets and vulnerabilities. Physical methods remain relevant for damaged devices, older phones, and non-userdata partitions (for example to verify system partitions), but they are rarely the first choice today. If you receive an ext4 image from such an extraction, Disk Image Parser can browse it in the browser; it does not read F2FS, which many recent phones use for userdata.

Cloud and companion sources

Some evidence never needs the handset: Google account data (Location History on older accounts, Chrome sync, Google Photos, Drive backups) through the account holder's Takeout export or legal process, WhatsApp chat exports the user shares, and paired devices such as a smartwatch or a car head unit. Treat them as separate sources with their own timestamps and retention, and never log into a suspect's account from the seized phone.

Documenting the acquisition

Whatever the level, the report must let someone else understand exactly what you reached:

• Device identifiers, Android version, security patch level and build fingerprint.
• Lock state at seizure and at extraction (BFU or AFU), and how the phone was kept powered and isolated.
• Every change you made: Developer options and USB debugging enabled, RSA key accepted, agent installed and removed, apps downgraded, airplane mode toggled.
• Tool names and versions (adb version, the commercial suite build), commands run, and start and end times with the device clock offset.
• Hashes of every output file (sha256sum), computed immediately.
• What was not reachable and why: for example, "CE storage not acquired, device in BFU".

Choosing a method

Work from least to most invasive, and stop when you have what the case needs:

1. If the phone is unlocked or you have the passcode: logical collection and a bugreport first. They are quick, low-risk and capture volatile system state.
2. Try an ADB backup only if a specific older app is known to allow it.
3. For app content (messaging, browser, location databases) go to a full file system extraction, ideally while the phone is still AFU.
4. Consider physical methods only for damaged devices, older models, or when a validated key-recovery path exists for the chipset.

Each artifact page on this site states in its Access field which of these levels reaches it. Start from the artifacts index and filter by Android version to plan what an extraction must cover.