Mobile browser forensics: Chrome on Android, Safari on iOS

The good news for mobile browser forensics is that the data formats do not change. Chrome on Android writes the same SQLite databases with the same schemas as Chrome on a laptop; Safari on iOS uses the same History.db layout as Safari on a Mac. If you can parse a desktop profile, you can parse a mobile one. The hard part is not the parsing — it is getting the files off the device in the first place.

Same formats, different paths

A mobile browser is the same application code with a mobile UI. The artifacts you already know — urls, visits, keyword_search_terms, cookies, logins, autofill — are all present, in the same tables, with the same column types and the same timestamp epochs. What differs is where the files sit and how protected they are. Every app lives in its own sandbox, and the OS does not hand that out to a USB cable.

So the workflow splits cleanly in two: acquisition (device-specific, often the bottleneck) and parsing (identical to desktop). This tool handles the second half. Once you have extracted the databases, the parsers are the same ones used on desktop profiles.

Android Chrome

Chrome's profile on Android lives inside the app sandbox at:

/data/data/com.android.chrome/app_chrome/Default/

Inside that Default folder you get the familiar files:

History — urls, visits, downloads, keyword_search_terms.
Cookies — same schema as desktop.
Login Data — logins; username plain, password ciphertext.
Web Data — autofill and payment data.

These are byte-for-byte the same SQLite schemas as desktop Chrome, WAL sidecars and all. Grab the -wal and -shm files alongside each database, exactly as you would on a desktop acquisition — recent visits live in the WAL until a checkpoint merges them.

The catch is access. /data/data/ is the protected app-private storage. You cannot read it over plain ADB on a non-rooted device. Reaching it means one of: root (then pull directly), an ADB backup if the app allows it (many do not), or a forensic extraction (physical / file-system image via a commercial tool or exploit). Without one of those, the sandbox stays shut.

iOS Safari

Safari on iOS keeps history in History.db, the same SQLite schema as macOS Safari (history_items, history_visits), under:

/private/var/mobile/Library/Safari/

Cookies sit in the Safari container's Cookies folder, in the same Cookies.binarycookies format Apple uses on the desktop. The plists you know from macOS Safari — bookmarks, last session, recently closed tabs — are present too.

Reaching any of it requires a full file-system image: a jailbreak, a forensic extraction tool, or in limited cases an iTunes/Finder backup (which captures some Safari data but not always the live History.db with its WAL). The standard sandbox is no more open on iOS than on Android.

Encryption

The databases are SQLite, but the sensitive values inside them are encrypted, just as on desktop — and the key material is tied to the device.

Android Chrome: cookies and saved passwords are protected through the Android Keystore. It is the mobile analog of desktop os_crypt (DPAPI / Keychain): the History table is plain text, but cookie and Login Data ciphertext needs the on-device key to decrypt.
iOS Safari: files are protected by iOS data-protection classes, with keys derived from the device passcode. Without the passcode (or a state where the keys are already unlocked), even a file-system image yields ciphertext for protected items.

This is why a locked, powered-off modern phone is genuinely hard, not just inconvenient. The encryption is a property of the platform, not the browser.

What this tool does — and does not do

Be honest with yourself about the boundary. This tool runs entirely in your browser and parses the SQLite databases — History, Cookies, Login Data — once you have extracted them from the device. The parsing logic is the same as for desktop artifacts, because the schemas are the same. You drop in the History file you pulled and you get the decoded urls / visits timeline, transitions and all.

What it does not do is acquisition. Rooting, jailbreaking, file-system imaging and backup extraction are device-side steps that happen before any file reaches this tool. Plan the acquisition first; the parsing is the easy part once the files are in hand.