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

Android's stack is five layers tall. The Linux kernel at the base provides process isolation, the Binder IPC, the low-memory killer and the wakelock subsystem. The HAL (Hardware Abstraction Layer) sits one layer up, with per-vendor shared libraries that bridge the kernel drivers to the framework. The Android Runtime (ART) sits above the HAL since Android 5.0; before that, Dalvik VM ran the same role with JIT compilation. The native libraries layer holds Bionic libc, OpenSSL, SQLite and the media codecs. The Java framework layer above them exposes the Android API to apps, which sit at the top in the form of APK packages.

An APK is a ZIP file with a specific structure. Open one with unzip or any archive tool and the layout becomes visible: AndroidManifest.xml (the binary-XML app manifest, parsed with aapt dump xmltree or apktool), classes.dex (one or more DEX files holding the compiled Java bytecode), resources.arsc (the binary resource table), res/ (uncompiled resources like layouts and drawables), lib/<abi>/ (native shared objects per CPU architecture), assets/ (raw bundled files the app reads at runtime), and META-INF/ (the v1 signing block with MANIFEST.MF, CERT.SF and CERT.RSA). Modern APKs also carry v2, v3 or v4 signing blocks at fixed offsets outside the ZIP entries.

For the examiner, the version dictates the artefact map. A Marshmallow handset still has FDE possibilities; a Nougat-and-later handset is FBE. An Android 10+ handset has scoped storage, which means /sdcard/ is no longer a free-for-all and the per-app directories under /data/data/<package>/ are the only authoritative source for app artefacts. Indian Android casework in 2024 and 2025 is overwhelmingly Android 11 to 14, which is what the digital forensics paper has shifted to test.

iOS shares its lowest layers with macOS. The kernel is XNU, a Mach-BSD hybrid from Apple's Darwin project, running on ARM with the Secure Enclave coprocessor on the same SoC. Above XNU sits the Core OS layer (BSD libc, libdispatch, IOKit), then Core Services (CoreFoundation, Foundation, CoreData), then Media (AVFoundation, Core Audio, Core Image), then Cocoa Touch at the top (UIKit, MapKit, EventKit). Apps run sandboxed in their own containers, with a strict per-app filesystem layout under /var/mobile/Containers/.

An IPA file is the iOS counterpart to an APK. It is a ZIP with a Payload/ folder containing the app bundle <App>.app/, which is itself a folder holding the Mach-O binary, the Info.plist, the _CodeSignature/ directory, the embedded provisioning profile, and the resource assets. The Mach-O binary is the iOS executable format; static analysis uses otool, class-dump, Hopper, IDA Pro, Ghidra and Frida. Unlike Android, iOS production binaries are encrypted with FairPlay DRM (the cryptid flag in the Mach-O LC_ENCRYPTION_INFO load command), which requires a jailbroken device or a decrypted dump (Frida-iOSDump, bagbak) for static analysis.

Windows Mobile warrants a brief note. Microsoft deprecated the OS in 2017, Lumia hardware support ended in 2019, and any Windows Mobile handset that reaches an Indian lab today is a pre-2015 case file requiring period-appropriate XRY or UFED versions.

SQLite is the storage engine under WhatsApp, Telegram, Signal, Instagram, Snapchat, Truecaller, every major UPI app, the Android Contacts provider, the iOS Messages database, and the iOS Photos library. Its binary layout has been stable since version 3.0 (2004), and deleted-row recovery from free pages is a standard forensic competency.

A SQLite database on a mobile device is rarely a single file. The main .db (or .sqlite) holds the committed state. The .db-journal sibling, in rollback-journal mode, holds the pre-image of pages currently being modified. The .db-wal sibling, in WAL (Write-Ahead Log) mode, holds new pages that have not yet been checkpointed into the main file. The .db-shm sibling holds the shared-memory index that tracks which WAL frames are current. An examiner who copies only the .db and misses the .db-wal may miss the last several minutes of transactions, which on a busy app like WhatsApp can be hundreds of messages.

1. Capture all four siblings together
   Copy .db, .db-journal, .db-wal and .db-shm in one atomic snapshot. Hash each with SHA-256 at capture time. A copy that lacks the WAL is incomplete, and a tool that opens the .db without the WAL will silently miss un-checkpointed rows.
2. Open in a read-only forensic tool
   DB Browser for SQLite, SQLiteSpy, Magnet AXIOM's SQLite Wizard, Sanderson SQLite Forensic Toolkit and Belkasoft Evidence Center all support WAL-aware open. The sqlite3 CLI also reads WAL natively if the .db-wal is present in the same directory.
3. Carve deleted rows from free pages
   SQLite stores deleted rows in unallocated cells on each B-tree page until a VACUUM runs. Sanderson's SQLite Recovery, the open-source undark and sqliteparser tools, and Belkasoft's SQLite carver parse the freelist and unallocated cells to recover deleted rows with high fidelity.
4. Replay the WAL
   The .db-wal holds frames keyed by salt and checksum. A WAL-aware tool replays the frames in order to reconstruct the database state at any point during the WAL window, including states no committed snapshot ever held.
5. Hash and report
   Hash the original four files, the parsed CSV exports, and any reconstructed snapshots. The BSA 2023 Section 63 certificate names the tool versions and the recovery method (carving, WAL replay, freelist parse) so the defence can reproduce.

CERT-In's mobile-forensics guidance (CIAD-2023-0046) names WAL-loss as the most common error in seized-device SQLite extraction, and Indian state SFSLs have begun to test for it in junior-examiner certifications.

Android's per-app data lives at /data/data/<package_name>/ on internal storage. The subdirectory layout is the same across apps. shared_prefs/ holds XML preference files (used for tokens, last-login data, feature flags). databases/ holds SQLite databases and their WAL/SHM siblings. files/ holds the app's freely structured working data. cache/ holds disposable caches. lib/ is a symlink to the native libraries under /data/app/. Access requires root or an adb backup (deprecated since Android 12) or a full physical image, which on a modern Pixel or Samsung handset means an EDL or chip-off acquisition.

iOS's per-app data lives at /var/mobile/Containers/Data/Application/<UUID>/ for the app's writable container, with the read-only bundle at /var/mobile/Containers/Bundle/Application/<UUID>/. The writable container has Documents/ (user-visible), Library/ (preferences, caches, internal databases), tmp/ (disposable temp files), and a few subdirectories under Library including Preferences/ (plist files), Caches/, Application Support/ and Cookies/. The UUID changes on app reinstall, so a forensic tool maps UUIDs back to bundle identifiers via the applicationState.db SQLite database under /private/var/mobile/Library/FrontBoard/.

The Indian state cyber-cell caseload prioritises the bottom four rows. UPI fraud cases require the transaction SQLite plus the VPA (Virtual Payment Address) records plus the device fingerprint stored in the app's shared_prefs. Truecaller is the most-cited contact-resolution evidence source in NCRB-tagged stalking and threat cases, because its server-side contact database often resolves a "Private number" caller to a name a regular CDR will not. WhatsApp's key file under /data/data/com.whatsapp/files/key is the symmetric AES key that decrypts the msgstore.db.crypt14 and crypt15 chat backups; an examiner with root or a full physical image can extract both and decrypt offline with WhatsApp Viewer or the open-source whatsapp-database-decrypter.

Android encryption evolved through two generations. Full-Disk Encryption (FDE), introduced in Android 5.0 and deprecated after Android 9, used a single volume-wide key derived from the user passcode. File-Based Encryption (FBE), default since Android 7.0 Nougat and mandatory on new devices since Android 10, splits files into Credential Encrypted (CE) and Device Encrypted (DE) storage classes. CE files are encrypted with a key derived from the user passcode and are unavailable before first unlock. DE files are encrypted with a key tied to the device and are available at boot, before unlock; the system uses DE for alarms, accessibility services, and the framework's bare-minimum startup state. The keys are stored in the ARM TrustZone-backed keystore on modern devices, with hardware key attestation enforced from Android 9 onward.

iOS hardware encryption has been present since the iPhone 3GS (2009), but passcode-derived Data Protection classes only arrived with iOS 4 (2010). The per-file key is generated from a per-class key, which is itself wrapped by a master key derived from the user passcode and a hardware UID baked into the Secure Enclave. The four protection classes (NSFileProtectionComplete, NSFileProtectionCompleteUnlessOpen, NSFileProtectionCompleteUntilFirstUserAuthentication, NSFileProtectionNone) control when a file becomes readable. The Secure Enclave is a coprocessor with its own ARM core, its own kernel and its own flash, isolated from the main application processor. Brute force against the passcode is rate-limited inside the Secure Enclave with hardware-enforced retry delays, which is what makes commercial extractors expensive and what makes Indian SFSL iOS work commercially constrained.

Mobile backups widen the recoverable surface. Android offers Google Drive backup (app data, SMS, call logs, device settings), ADB backup (now restricted, app-cooperative), Samsung Smart Switch (vendor-specific full backup over Wi-Fi or cable), and per-vendor clouds (Samsung Cloud, Mi Cloud, OnePlus Cloud). iOS offers iCloud backup (encrypted in transit and at rest, with the key wrapped by the Apple ID under standard mode and by the user-only key under Advanced Data Protection) and iTunes/Finder local backup (encrypted with a user-set passcode if the user enables backup encryption). For an Indian case, the legal anchor for Google Drive and iCloud is the Mutual Legal Assistance Treaty (MLAT) process via the MHA's IS-II division, or in time-sensitive matters the emergency-disclosure channels each provider exposes for credible threat-to-life cases.

Android's runtime permission model, introduced in Marshmallow, records every grant and revocation in /data/system/users/<user_id>/runtime-permissions.xml (legacy) or in the consolidated runtime-permissions.xml under the user's directory on modern Android. Each entry names the package, the permission, the grant state and the flags (whether the user granted, denied, or revoked it, and whether the grant is a one-time grant introduced in Android 11). The AndroidManifest.xml inside the APK declares the permissions the app requests; the runtime XML records the user's response.

iOS's equivalent is TCC.db (Transparency, Consent, Control), at /var/mobile/Library/TCC/TCC.db on the device and at /Library/Application Support/com.apple.TCC/TCC.db per-user on macOS. The schema includes the access table (service, client bundle ID, allowed flag, prompt count, timestamp), the expired table (revocations) and the policies table (configuration-profile-driven policies). An examiner can open TCC.db with any SQLite tool and produce a permission-by-permission timeline of who got the camera, who got the microphone, who got contacts and at what point the user revoked any of them.

The Indian casework lens makes this concrete. In an Instagram stalking case from Delhi in 2024, the runtime-permissions.xml on the accused's seized Android handset showed the app had been granted continuous location access, and Instagram's per-app SQLite under /data/data/com.instagram.android/databases/ contained the location-tagged story drafts the victim had reported. The combination of permission audit plus app database is the trail Indian cyber cells now rely on for IT Act Section 66E (privacy violation) read with BNS 2023 Section 78 (stalking) charges. CERT-In's CIAD-2024-0019 advisory on Indian mobile-app surveillance vectors names TCC.db and runtime-permissions.xml as the two artefacts every state SFSL should baseline against.

UPI app forensics is the single most-demanded skill in Indian state cyber cells. A typical UPI fraud case file pulls the transaction SQLite from the app (PhonePe's phonepe_transactions.db, Google Pay's tez.db, Paytm's wallet_transactions.db, BHIM's transactions.db, BharatPe's transaction store), joins it against the NPCI transaction ID returned in the response, and cross-references against the victim's bank statement and the mule account's bank statement. The cross-link to the acquisition toolkit topic is direct: a UPI case is only as strong as the acquisition method, because the app SQLite is in CE storage and is unreachable without the passcode or a chip-off.