Acquisition

1 Three levels of acquisition

Mobile acquisition methods are usually sorted by how deep they reach. Deeper copies contain more, but need more access to the device, and the deepest ones are often impossible on a current, locked phone.

On current phones, "full file system" copies have largely replaced physical images: since the storage is encrypted per file, a decrypted file-system copy is more useful than an encrypted raw dump.

2 Android: adb and the .ab backup

With USB debugging enabled and the computer authorised on the unlocked phone, the Android Debug Bridge gives you a shell and file transfer. adb pull /sdcard/DCIM copies shared storage. The app sandboxes under /data/data/ are not readable for the shell user, so a plain adb pull of an app's databases fails without root.

adb backup was the classic logical method. It writes one .ab file and still exists, but it is deprecated and increasingly empty:

• an app can opt out with android:allowBackup="false" in its manifest;
• since Android 12, data of apps that target Android 12 or later is no longer included (debuggable apps aside);
• the user must confirm on the device and can set a password, which encrypts the file.

The format itself is simple: four text lines, then a zlib stream that inflates to a tar archive with paths like apps/<package>/db/….

Try this: the header ends at byte 0x17. Which two bytes follow, and what do they tell you about the compression? Then check the tar listing: which folder would hold the app's SQLite databases?

Root- or exploit-based methods (temporary root, bootloader vulnerabilities, vendor service modes) reach the full file system. They are what commercial extraction tools do behind their buttons. They are device- and version-specific, can modify the device, and must be documented and validated; they are outside the scope of this course.

3 iOS: iTunes/Finder backups and Manifest.db

A trusted computer can make a local backup of an iPhone (Finder on macOS, iTunes or the Apple Devices app on Windows, or open-source tools using the same protocol). The backup is a folder named after the device's UDID:

There are no original file names on disk. Manifest.db maps them: each row of its Files table holds the domain (which area of the phone, e.g. AppDomain-<bundle id> or HomeDomain), the relative path inside it, flags (1 file, 2 directory, 4 symbolic link) and a file blob with metadata (size, times, protection class; NULL in this sample).

Cell 3 is the chat database: fileID 842b3ea268d81c26ede3c216a5fc1b7bebde69bf, so the file sits in folder 84/. Note that the -wal file has a row of its own: a backup copies it as a separate file. The fileID column is the primary key, so SQLite also keeps an index, sorted by fileID. This is what an index leaf page (type 0A) looks like: each cell holds only the key and the rowid.

Try this: compute the fileID of the preferences file yourself: printf '%s' 'AppDomain-com.example.chatter-Library/Preferences/com.example.chatter.plist' | sha1sum. In which folder of the backup would it be? Find its row in the hex view.

Encrypted or not?

The user can enable "Encrypt local backup" with a password. Then every file, including Manifest.db itself, is encrypted, and Manifest.plist carries the key bag. Encrypted backups contain more than unencrypted ones: saved passwords (keychain items), Wi-Fi settings, website history and Health data are only included when the backup is encrypted. Examiners therefore often prefer an encrypted backup with a known password over an unencrypted one.

4 Copy the database with its -wal and -shm

Most apps run SQLite in WAL mode: new and changed pages go to chat.db-wal first and reach chat.db only at the next checkpoint. chat.db-shm is a shared-memory index into the WAL. Three consequences for acquisition:

1. The newest data may exist only in the WAL. Copy the main file alone and recent messages are missing.
2. Old versions of pages live on in the WAL until it is overwritten, including rows that were deleted since. This is often where deleted chats are found (see the WAL page).
3. Opening the database can destroy that evidence. When the last connection closes, SQLite checkpoints the WAL into the main file and deletes it. A GUI browser or a quick sqlite3 chat.db on the original does exactly that.

The builder output below shows the same SELECT on two copies of the sample chat database. With immutable=1, SQLite reads the main file only and ignores the WAL, so the message with id 8, which so far exists only in the WAL, is missing. With the -wal next to the copy it appears.

5 Try it yourself

Answer from the hex views and builder outputs above. Numbers can be typed in decimal or hex (0x…).