Android and iOS Forensics: Operating Systems, SQLite and App Data

Android combines a Linux-based kernel, system services, hardware interfaces, native libraries, runtime and application frameworks. Layer diagrams are teaching models, not a promise that every component produces retained forensic logs.

An APK is an archive-based package that can contain a manifest, DEX code, resources, assets and native libraries. Apps can use split packages and dynamically delivered components, so one APK may not represent the entire installation.

DEX is Android executable bytecode, not simply ordinary Java class files. Resources can be compiled, and code may include native components. Preserve package identity, version and signatures alongside the relevant data.

APK signature schemes differ: v1 uses archive entries, v2/v3 use an APK signing block in the defined layout, and v4 uses a separate signature file. They are not all fixed-offset blocks inside every APK.

OS launch version, updates and vendor configuration affect encryption and storage. FBE support began with Android 7; that does not mean every Android 7 device used FBE. Scoped storage also does not make one private directory the only valid app evidence source.

iOS uses sandboxing, code signing, entitlements and hardware-linked data protection. Identify actual hardware, OS build and accessible state rather than treat one historical jailbreak as a universal acquisition path.

An IPA can contain a Payload app bundle with executable code, resources and signature-related material. Installed writable app data is separate from the code bundle; package possession does not mean user records were acquired.

Mach-O encryption and distribution characteristics vary by build and source. Inspect actual metadata instead of claiming every production binary requires the same decryption technique. Dynamic instrumentation and static disassembly are different methods.

Bootrom exploits and other access mechanisms are model- and version-dependent. A historical tool does not provide permanent unrestricted root on every supported chip, and public/commercial capabilities change.

Logical acquisition, accessible filesystem data, local backups and cloud sources can have different coverage. Do not define contemporary acquisition by an unsupported “iOS 17 sealed filesystem” rule or promise that one paid product accesses all devices.

SQLite use and schemas vary by app. The main database, WAL, rollback journal and shared-memory index are not four siblings guaranteed to coexist. Identify the actual journalling mode and existing supporting files.

A WAL can hold committed changes not yet checkpointed into the main file. It can also contain incomplete or stale frames requiring transaction, salt and checksum interpretation. Copying files at unrelated live moments can produce inconsistent state.

Preserve a coherent database set with a supported acquisition, recording source paths, versions and hashes. Work on copies, and document any replay, checkpoint or recovery transformation.

Deleted-data recovery depends on page reuse, secure_delete, vacuuming, encryption, WAL reuse and application behaviour. Checkpointing is not a universal erasure event, and a retained WAL is not a fixed window containing all recent chats.

Carved cells and historical pages need schema/context validation. A fragment may lack complete columns, relationships or trustworthy timing. Do not present uncommitted state as a successfully sent message or authoritative transaction.

Keep native files and queries alongside exports. Cross-check important decoded records and distinguish current rows, recovered historical content and reconstruction uncertainty.

Android private data commonly uses user- and encryption-specific paths such as /data/user/<user>/<package> and /data/user_de/<user>/<package>, with historical aliases like /data/data. Work profiles, external storage and app-specific databases add other sources.

iOS data can span app containers, shared app groups, system stores, keychain-related items and separate media. UUID mapping and paths change; use actual installation metadata rather than one universal FrontBoard database.

App stores can hold preferences, databases, attachments, caches and account state. Identify bundle/package IDs, versions and profile/account relationships before parsing.

Paths, database names and backup-key formats change across releases. Do not promise a particular WhatsApp key file decrypts every crypt14/crypt15 backup or that a guessed payments database exists on every device.

End-to-end transport encryption and local database protection are separate. A protected messenger can still contain accessible local content under some conditions; its protocol name does not establish minimal or complete recovery.

Android FBE distinguishes credential-encrypted and device-encrypted storage with different availability. Access still depends on permissions and the actual platform; device-encrypted does not mean unprotected plaintext for any reader.

Apple Data Protection uses file and class-key relationships with hardware/passcode protections. Per-file keys are protected through the hierarchy rather than universally generated by directly deriving each file key from a class key.

Before-first-unlock and after-first-unlock conditions matter, but relocking can change availability according to protection class. A filesystem extraction does not automatically include every usable key or decrypted item.

Backups are selected representations with platform and app exclusions. A local encrypted iPhone backup has its own password, which need not equal the device passcode or account password.

Cloud sync, device backup and app-specific backup are different sources. Standard and end-to-end protection settings affect what the provider can access; a legal request does not itself remove encryption.

Preserve account, backup/device identifiers, creation and collection times, tool/version, downloaded bytes and exclusions. Authority and cross-border disclosure requirements vary by jurisdiction.

An app manifest declares requested capabilities, while OS permission state records some grants or policies. These are different from evidence that a camera, microphone or location service was actually used.

Android permission and app-operation records are version-dependent and may describe current or limited recent state. They are not a universal file listing every grant, denial and revocation throughout device life.

Apple TCC-related schemas and paths vary. A retained row can support a permission-state observation but does not automatically yield a complete use timeline or identify who answered a prompt.

Correlate relevant resource-use telemetry, app content and independent events when available. A granted camera permission does not prove a particular call was recorded; a location grant does not prove stalking.

Acquisition choices are developed in Mobile Phone Forensics. Root access, a raw chip read and a decrypted filesystem extraction are distinct capabilities, not interchangeable requirements.