Mobile Operating Systems: Android, iOS, SQLite and App Forensics
Android and iOS architecture, SQLite WAL recovery, per-app artefact paths, UPI app forensics and encryption models for Indian digital forensic examiners.
Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
Android and iOS architecture, SQLite WAL recovery, per-app artefact paths, UPI app forensics and encryption models for Indian digital forensic examiners.
A mobile examiner who only knows how to image the handset finishes about a third of the case. The rest sits in the operating system's per-app directories, in SQLite databases the app wrote and forgot, in WAL files the app never merged, and in cloud backups the user did not realise were on. The Indian state cyber cell caseload skews heavily towards UPI fraud, WhatsApp-based extortion, Telegram-channel CSAM and Instagram-based stalking, and every one of these cases lives or dies on the artefact paths and recovery techniques covered in this topic. ART has replaced Dalvik. FBE has replaced FDE. iOS 17's sealed file system has replaced the iOS 12 jailbreak-everything era. The toolkit has moved with the platform, and the examiner has to move with the toolkit.
This topic continues Module 6 from the mobile technologies foundation and feeds the acquisition workflows that cover JTAG, ISP and chip-off and the cloud and backup forensics layer. The malware-side companion is the static, dynamic and memory analysis chapter, which carries the binary-analysis half of mobile app forensics. Framing is Indian throughout: UPI app artefact paths, NCRB-cited Truecaller and WhatsApp evidence patterns, CERT-In advisory references, BNS 2023 Section 318 and Section 336, IT Act Sections 66, 66C, 66D and 67, and the BSA 2023 Section 63 certificate format the trial bundle expects.
Five layers and a ZIP file that holds them together.
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.
| Android version | Codename | Year | Forensic milestone |
|---|---|---|---|
| Android 6.0 | Marshmallow | 2015 | Runtime permissions introduced (per-permission prompts) |
Darwin at the bottom, Cocoa Touch at the top, a sealed file system in the middle.
iOS shares its lowest layers with macOS. The kernel is XNU, the Mach-BSD hybrid kernel from Apple's Darwin project, running on ARM with the Apple Silicon SoC's Secure Enclave coprocessor alongside. 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 is the historical footnote still worth knowing. Microsoft's mobile OS was deprecated in 2017, Lumia hardware support ended in 2019, and the Surface Duo that briefly carried the Microsoft mobile name runs Android. Any Windows Mobile handset that reaches an Indian lab today is a pre-2015 case file, and the relevant tools are the WinMo-era XRY and UFED versions from that period.
The .db, the .db-wal, the .db-shm and the unallocated rows.
SQLite is the storage engine under WhatsApp, Telegram, Signal, Instagram, Snapchat, Truecaller, every UPI app, the Android Contacts provider, the iOS Messages database and the iOS Photos library. The file format is documented, the binary layout is stable since version 3.0 (2004), and the recovery of deleted rows is a standard forensic skill the digital forensics paper tests directly.
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.
The two filesystem trees every mobile case lives in.
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/.
| App | Platform | Key artefact path | Notable contents |
|---|---|---|---|
| Android | /data/data/com.whatsapp/ |
FBE, Secure Enclave, ARM TrustZone and where the user accidentally kept a copy.
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 encryption is always on since iPhone 3GS (2009). 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.
One XML on Android, one SQLite on iOS, both name what the app was allowed to see.
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 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.
An examiner copies only msgstore.db from a WhatsApp Android handset and opens it in DB Browser for SQLite. The most likely consequence is:
| Android 7.0 | Nougat | 2016 | File-Based Encryption (FBE) becomes the default |
| Android 9.0 | Pie | 2018 | Hardware-backed keystore mandatory for new devices |
| Android 10 | (numeric) | 2019 | Scoped storage; per-app sandbox for shared media |
| Android 11 | (numeric) | 2020 | Storage Access Framework hardened; auto-revoke of unused permissions |
| Android 12 | (numeric) | 2021 | Privacy Dashboard; clipboard access notifications |
| Android 13 | (numeric) | 2022 | Per-app language; photo picker bypasses storage permission |
| Android 14 | (numeric) | 2023 | Partial photo and video access; credential manager |
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.
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.
| msgstore.db (chats), wa.db (contacts), files/key (chat backup key), Media/ |
| iOS | /var/mobile/Containers/Data/Application/<UUID>/ | ChatStorage.sqlite, ContactsV2.sqlite, Media/Library |
| Telegram | Android | /data/data/org.telegram.messenger/ | cache4.db, cache_media, files/, shared_prefs/userconfing.xml |
| Signal | Android | /data/data/org.thoughtcrime.securesms/ | Encrypted databases; minimal recoverable content due to E2E |
| Truecaller | Android | /data/data/com.truecaller/ | Call log SQLite, search history, contact lookup cache (rich Indian dataset) |
| PhonePe (UPI) | Android | /data/data/com.phonepe.app/ | Transaction history SQLite, beneficiary list, KYC cache |
| Google Pay (UPI) | Android | /data/data/com.google.android.apps.nbu.paisa.user/ | tez_transactions.db, VPA records, statement cache |
| Paytm | Android | /data/data/net.one97.paytm/ | Wallet transaction SQLite, KYC documents, biller list |
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.
A backup-derived artefact in an Indian trial bundle needs the certificate to name: the source platform (Google account ID, Apple ID), the timestamp and method of acquisition (MLAT response, emergency disclosure, user-consent download with screen-recorded session), the hash of the downloaded archive, the tool used to parse (Elcomsoft Phone Breaker, Magnet AXIOM Cloud, Oxygen Forensic Cloud Extractor), and the chain of custody from download to lab intake. Skipping any of these weakens admissibility under BSA Section 63.