Mobile Cloud and Backup Forensics: iCloud and Google Drive

A modern smartphone is a thin client. iOS pushes iMessage, Photos, Notes, Safari history, Keychain and Health into iCloud by default. Android pushes app data, SMS, call history, contacts and Wi-Fi credentials into Google Drive through Auto Backup. WhatsApp on both platforms writes daily chat archives to Google Drive or iCloud at the user's option. Telegram keeps every cloud chat on its own servers regardless of which device the user is holding. The seized phone is the user interface; the evidence is often distributed across cloud accounts the device silently syncs to.

The practical consequence is that a logical or filesystem acquisition of the phone, however clean, frequently shows truncated chat histories. WhatsApp on iOS purges local message media after 30 days for accounts on default storage settings; the original media survives only in the iCloud or Google Drive backup. iMessage on iOS roll-aged after the "Keep Messages" preference (30 days, 1 year, or Forever) but the iCloud Messages sync, if enabled, mirrors everything to the cloud and back. A device that has Messages in iCloud turned on will appear to show only recent messages until the iCloud account is also acquired.

The Indian anchor here is the dowry-and-banking-fraud bucket. A typical 498A or banking cheating matter (IPC successor in BNS 2023) turns on WhatsApp exchanges between the accused and a third party. The accused regularly deletes the on-device thread before the seizure. The Google Drive backup, set daily at 2 a.m., still holds the prior week's messages because the deletion happened after the last backup and the suspect has not yet rotated the backup. An investigating cell that requests the Drive backup recovers what the on-device acquisition missed; one that does not may close the file without the primary evidence.

iCloud backup is a daily snapshot that runs when the device is on Wi-Fi, charging and locked. The default classes Apple holds keys for include the device settings, Home Screen layout, iMessage and SMS/MMS history (when iCloud Messages is off), Apple Watch backup, ringtones, visual voicemail, and most app data that the developer marked for backup. Photos go to iCloud Photos as a separate stream if the user enabled it; otherwise they sit inside the daily backup. Health data is encrypted with a key tied to the device passcode; Keychain uses iCloud Keychain Escrow with a per-account key that Apple holds in a Hardware Security Module but cannot extract without the user's iCloud password and the device passcode.

The end-to-end encrypted classes are the ones Apple cannot decrypt even when served a production order. The official Apple list, current to 2025, includes Keychain (passwords, payment cards), iMessage when both ends have 2FA enabled, Apple Pay information, Health, Home (HomeKit), Maps Favourites, Memoji, Payment Information, QuickType Keyboard Learned Vocabulary, Safari Bookmarks (under ADP), Screen Time, Siri Information, and Wi-Fi passwords. For each of these, Apple's production response to a valid legal demand is metadata only: account creation date, last sign-in, recovery contacts, and device list.

Advanced Data Protection, an opt-in feature since iOS 16.2 in December 2022, extends end-to-end encryption to the remaining classes: iCloud Backup itself, iCloud Drive, Photos, Notes, Reminders, Voice Memos, Safari Bookmarks, Shortcuts, Wallet Passes, and any iCloud-backed app data. When ADP is on, Apple's production response to even a valid Indian MLAT-routed warrant returns only the account metadata and an explicit "data is end-to-end encrypted" line. The user becomes the sole keyholder.

The Indian anchor: a 2024 Mumbai economic offences wing matter against a listed-company director surfaced exactly this gap. The accused's iPhone was extracted with Cellebrite Premium; the local artefacts gave a partial picture. An MLAT-routed iCloud production order returned account metadata and a confirmation that ADP was enabled on the account. The cell pivoted to the user's Mac (which still held the offline copies of iCloud Drive files via a Time Machine snapshot) and to the iCloud authentication token recovered from the phone (which let Elcomsoft Phone Breaker pull the non-ADP classes). The lesson lodged in the cell's SOP: confirm ADP status from the device's Settings > [Name] > iCloud > Advanced Data Protection screen during the seizure, and plan the cloud route from there.

There are three working paths to iCloud and Google Drive data. The first is the provider production order, served through BNSS 91 (domestic) or MLAT (US-based providers). The provider returns what it holds in a readable form, subject to the class restrictions above. Apple's India LE liaison, contactable via lawenforcement@apple.com and the Apple Legal Process Guidelines, processes Indian orders directly when the data is held in Apple's India region; data on US-region servers requires MLAT. Google's response model is similar: Indian intermediary obligations under IT Act Section 69 and Intermediary Guidelines 2021 cover Significant Social Media Intermediaries (Google's India entity is one) for India-region data.

The second path is the user's account credentials, voluntarily given or recovered during interview, fed into a cloud acquisition tool. Elcomsoft Phone Breaker's iCloud Acquisition module takes an Apple ID and password, completes 2FA if required (with the user's cooperation or a recovered trusted-device code), and downloads the backup, iCloud Drive, Photos and a configurable set of app data into a local container. Magnet AXIOM Cloud, Oxygen Forensic Cloud Extractor and E3 Forensics implement the equivalent for Google accounts using OAuth and the Google Takeout and Drive APIs. The download size for a heavy iCloud account often exceeds 200 GB and runs overnight.

The third path is the iCloud or Google authentication token extracted from a logical or filesystem image of the seized phone. iOS keeps the iCloud authentication token in the Keychain class kSecAttrAccessibleWhenUnlockedThisDeviceOnly; a passcode-unlocked extraction (Cellebrite Premium AFU, GrayKey, or jailbreak-assisted) lifts it. Elcomsoft Phone Breaker accepts the token and pulls cloud data without re-entering the password and without triggering a 2FA prompt, because the token has already been blessed by the device. The catch is that the token is short-lived; it expires within a few weeks if the user's session is otherwise terminated, and Apple invalidates it when the user signs out of iCloud on the device.

1. Confirm legal basis
   BNSS 91 for domestic Indian intermediaries (Jio Cloud, Bharti); IT Act Section 69 read with Intermediary Guidelines 2021 for SSMIs; MLAT request through MHA to DOJ-OIA for Apple, Google, Meta US-region data. Document the order in the case file before any token use.
2. Acquire account material
   From the seized phone: Apple ID/Google account name from device Settings; authentication token from a Keychain or filesystem extraction (Cellebrite Premium AFU, GrayKey, MSAB XRY). From interview: account password and any backup codes the suspect has.
3. Run the cloud tool
   Elcomsoft Phone Breaker for iCloud (backup + Drive + Photos + selected classes). Magnet AXIOM Cloud or Oxygen for Google (Takeout, Drive, Photos, Location History). E3 Forensics for both. Log the tool version, the operator, the start and end timestamps and the download size in the chain of custody.
4. Hash and store
   SHA-256 hash every downloaded container, write to the working storage, and write a second copy to an air-gapped archive. Note the difference between the cloud-snapshot timestamp (when the backup was made) and the acquisition timestamp (when the IO downloaded it); both are needed under BSA Section 63.
5. Parse to artefacts
   Open the container in the same toolkit (AXIOM Process, Cellebrite Reader) or in a downstream parser (iLEAPP, ALEAPP, SQLite Forensic Browser) to surface chats, photos, locations, contacts and app data as evidence artefacts.

WhatsApp writes a daily archive of its on-device msgstore.db (Android) or ChatStorage.sqlite (iOS) to Google Drive or iCloud at the user's option. The Android backup lands in Google Drive under the WhatsApp folder, encrypted with a key the WhatsApp server holds, unless the user has enabled end-to-end encrypted backups. The E2E backup feature rolled out in October 2021 and reached Indian accounts through 2022; when enabled, the backup is encrypted with either a user-chosen 64-digit key or a password-derived key, and WhatsApp can no longer decrypt it. The forensic implication is that a provider order to Google for the Drive file returns an encrypted blob; the IO needs the user's E2E password or 64-digit key to read it. Elcomsoft eXplorer for WhatsApp and Magnet AXIOM both parse the legacy non-E2E backup; the E2E backup requires the key.

Telegram is the opposite. Cloud chats (the default) are stored on Telegram's servers, encrypted with keys Telegram holds. Telegram can decrypt them and, under its published transparency reports, has historically produced data for terrorism-related requests in limited geographies but has resisted broader law-enforcement disclosure. Secret chats are end-to-end encrypted between two specific devices, leave no cloud copy, and are not synced across the user's devices. The forensic implication is that secret chats live or die with the device; cloud chats live or die with Telegram's cooperation.

Signal keeps no cloud backup at all. Local backups on Android are end-to-end encrypted with a 30-digit passphrase the user must record at backup time; iOS has no Signal backup option beyond manual chat transfer between two physically present devices. A provider order to Signal returns the account registration timestamp and the last connection date; that is the entire menu. Signal is the messenger of choice for parties who do not want their content recoverable; the IO's only path is the unlocked device.

The Indian anchor is the cluster of dowry-and-banking-fraud matters that turn on WhatsApp Drive backups. Hyderabad Cyberabad cyber cell publicly reported in a 2024 briefing that of 318 banking-fraud FIRs that named WhatsApp evidence, 89 percent of usable conversational evidence had been recovered from Google Drive backups served on Google through BNSS 91 within 60 days of the deletion event. Cross-link to social media OSINT collection for the parallel surface on Instagram, Facebook and X.

App permissions analysis answers the question: at the time of the alleged act, could the suspect's app actually access the camera, the microphone, the photo library, the location stream, the contacts, the calendar? An IO who claims an Instagram clip was filmed on the suspect's phone must show that Instagram had camera permission at that moment; the defence will argue the opposite.

On Android, three layers cooperate. The static layer is AndroidManifest.xml inside the APK, which declares every permission the developer requests. The runtime layer is /data/system/users/0/runtime-permissions.xml (or under a different user ID for multi-user devices), which records the user's actual grants and denials. Android 10 (2019) introduced the foreground/background location distinction: an app can be granted "while in use" without "all the time." Android 11 (2020) added one-time permissions, granted for a single session and revoked when the app is backgrounded. Android 12 (2021) added approximate-versus-precise location and the camera/microphone privacy indicators in the status bar. Each grant carries a timestamp in the system's permission events table.

On iOS, the canonical store is TCC.db at /var/mobile/Library/TCC/TCC.db, a SQLite database that the Transparency, Consent and Control framework reads and writes. The table access carries one row per app per service: client (the bundle ID), service (kTCCServiceCamera, kTCCServiceMicrophone, kTCCServicePhotos, kTCCServiceLocation, kTCCServiceContacts, kTCCServiceCalendar and others), allowed (0/1), and prompt_count and last_modified timestamps. A row showing allowed=1 with last_modified before the disputed event proves the app had access; a row with allowed=0 disproves the claim. iLEAPP parses TCC.db automatically; Cellebrite and Oxygen surface it in their iOS extraction reports.

A 2024 Bengaluru voyeurism matter under BNS Section 77 illustrated the importance. The accused argued that the alleged covert recording app on his iPhone had been installed but never granted camera access. The state's expert pulled TCC.db from the Cellebrite extraction: the row for the app showed allowed=1 with last_modified two days before the disputed event, contradicting the defence. The court accepted the TCC.db row as a Section 63 BSA electronic record with the examiner's certificate. The defence's argument collapsed.

The Indian IO's cloud-evidence path runs through four legal instruments depending on the data location and the provider's identity. The first is BNSS Section 91 (which replaced CrPC Section 91 from 1 July 2024). A court or an officer in charge of a police station can issue a written order requiring production of any document or thing for the purposes of an investigation. For domestic Indian intermediaries (Jio Cloud, Reliance, Vi, BSNL), a BNSS 91 order is the standard instrument and is honoured within 30 to 90 days.

The second is IT Act Section 69 read with the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021. Section 69 authorises designated agencies to direct interception, monitoring or decryption; the 2021 Rules impose specific obligations on Significant Social Media Intermediaries (SSMIs), defined as intermediaries with more than 50 lakh (5 million) registered Indian users. SSMI obligations include appointing a Chief Compliance Officer, a Nodal Contact Person for 24x7 coordination with law enforcement, and a Resident Grievance Officer, all of whom must be resident in India and reachable. Apple India, Google India, Meta India and X India each have these appointments published on their respective compliance pages.

The third path is MLAT. India has Mutual Legal Assistance Treaties with 45+ countries including the United States (treaty signed October 17, 2001, in force from October 3, 2005). The US MLAT route for evidence held by Apple, Google, Meta or Microsoft on US-region servers runs from the Indian IO to the Ministry of Home Affairs CBI MLAT cell, to the US Department of Justice Office of International Affairs (DOJ-OIA), to the provider via a US subpoena, search warrant or 2703(d) order under the Stored Communications Act. Typical turnaround is 6 to 18 months. The CLOUD Act 2018, while permitting executive agreements that bypass MLAT, has no executive agreement in force with India as of 2025; the MLAT route remains the default.

1. Classify the data and provider
   Identify the provider (Apple, Google, Meta, Telegram, Signal, Jio Cloud, Bharti). Determine whether the data is India-region (subject to BNSS 91 and IT Act 69) or foreign-region (subject to MLAT). Apple, Google and Meta publish their data-region maps in their LE guidelines.
2. Preserve before production
   File a preservation request first. Apple, Google and Meta accept preservation requests by email at lawenforcement@apple.com, lis-india@google.com and records.india@fb.com and freeze the account for 90 days extensible. The preservation prevents the account from being rotated or deleted while the production order is being prepared.
3. Issue the order
   BNSS 91 for domestic; IT Act 69 plus 2021 Rules for SSMIs operating in India; MLAT request prepared by the SP-level officer and routed through the State Home Department to MHA CBI MLAT cell for foreign-region data. Each order must specify the account identifiers, the date range and the data classes sought.
4. Receive and authenticate
   Provider response arrives as an encrypted ZIP with a BSA Section 63 certificate (or its foreign equivalent for MLAT returns). Hash the package, log receipt, and have the certifying officer (BSA Section 63 sub-section 4) sign the Section 65B-equivalent certificate before tendering in court.
5. Track ADP and E2E exclusions
   If Apple's response includes an ADP notice or Google's response notes E2E-encrypted WhatsApp backup, document the limitation in the case file. The court will weigh the inability to decrypt against the totality of other evidence; concealing the limitation is itself a defence opening.

The Indian anchor: the TikTok ban of 29 June 2020 under IT Act Section 69A complicated cooperation with ByteDance for the subset of cyber-crime matters that named TikTok evidence. ByteDance retained operational data on Singapore-region servers, and a US MLAT does not reach it. The Indian IO route for ByteDance evidence post-ban runs through informal LE cooperation with ByteDance's Singapore office under MLAT with Singapore (in force from 2005), with typical turnaround similar to the US route. The lesson lodged in the cyber-cell SOP is to identify the provider's data region at the outset, not after the order has been drafted to the wrong jurisdiction.