Mobile Phone Forensics: Acquisition, JTAG and Chip-Off

Mobile evidence handling begins before the device reaches the lab. The on-scene first responder makes three decisions in sequence: containment (block radios), state preservation (avoid power-cycling), and documentation (photograph before touching). Each decision directly affects what an examiner can recover later.

Containment is the first decision because remote wipe is the highest-impact loss event. A live phone with mobile data and Wi-Fi enabled is reachable through the manufacturer's account ecosystem (Find My iPhone, Find My Device for Android, Samsung Find My Mobile, Xiaomi Mi Cloud) and the linked account holder, who is often the suspect or the suspect's accomplice, can issue a remote wipe in under a minute. Faraday bag is the default control: a conductive mesh pouch that blocks cellular, Wi-Fi, Bluetooth and NFC signals. Quality matters: a cheap pouch attenuates only by 60 dB at 1800 MHz and may still pass an EDGE signal at the cell tower's edge. CFSL specification calls for at least 85 dB attenuation across 800 MHz to 6 GHz and a tested seal. If a Faraday bag is not available, the responder enables airplane mode and disables Wi-Fi and Bluetooth manually, then removes the SIM, then powers off only if no other option exists.

State preservation is the second decision. If the phone is unlocked at seizure, the responder enables the longest available screen timeout, disables auto-lock if possible, and immediately starts a live logical acquisition with a portable Cellebrite UFED Touch 2 or a laptop running mvt (Mobile Verification Toolkit) plus a USB cable. Charge is the practical concern: a phone running low will power off mid-acquisition. Indian cyber cell responder kits include a 20,000 mAh power bank and a small armoured USB cable specifically for this case. Live acquisition while the phone is unlocked recovers session cookies, in-memory app states (active WhatsApp Web pairings, currently-running banking sessions) and SQLite WAL pages that vanish after the next reboot.

Documentation is the third decision and the easiest to skip in a hurry. The responder photographs the phone face-up showing the lock-screen content (visible notifications, time, carrier name, signal bars, battery percentage), then face-down showing model, IMEI label if visible and any accessories. The responder records the IMEI from *#06# if the phone is unlocked, the IMSI from the SIM packaging if present, the SIM tray for iPhones via the eject pin, the device serial from Settings if available, and a description of any attached cables, chargers or SD cards. The chain of custody form (see chain of custody) is opened with the seizure timestamp, the seizing officer's name and badge, the location of seizure, the storage type used (Faraday bag model and serial), and the next custodian.

1. Approach: do not touch the screen, photograph from above
   Capture screen state, time, lock-screen notifications, carrier name, signal strength and battery percentage with a body-worn camera or service phone before any handling. This photograph is the baseline against which later state changes are measured.
2. Contain: Faraday bag or airplane mode + SIM removal
   Faraday bag is preferred. If unavailable, enable airplane mode, then turn off Wi-Fi and Bluetooth manually (airplane mode on iOS does not disable Bluetooth in all cases), then remove the SIM. Power off only if no other containment is possible.
3. Charge: keep the phone alive
   A low battery is a wipe risk. Connect the phone to a portable power bank inside the Faraday bag through a battery-pass-through port if available, or remove the phone from the bag only inside a Faraday-shielded room at the lab.
4. Record identifiers: IMEI, IMSI, model, serial, SIM tray
   Dial *#06# only if the phone is unlocked and the operator can do so without disturbing other state. Otherwise read the IMEI from the SIM tray imprint or the back-cover label. Record the IMSI from the SIM packaging if found; otherwise leave it for lab extraction.
5. Bag, label, log: chain of custody opens here
   Bag the device with a sealed evidence label naming the case number, date, seizing officer and storage type. Bag the SIM separately. Bag the SD card separately. Bag any chargers, cables and accessories with the same case number cross-reference.

The Indian anchor for seizure procedure is the CCTNS (Crime and Criminal Tracking Network and Systems) standard operating procedure for digital evidence, which Indian state police forces adopted in stages from 2019 onward. The CCTNS module for mobile seizure explicitly requires the Faraday containment step, the on-scene photograph of lock-screen state and a recorded IMEI before the device leaves the scene. The 2023 Karnataka State Cyber Crime Police Station handbook adopted the same checklist verbatim. Deviations are not fatal but degrade evidentiary weight at trial under Bharatiya Sakshya Adhiniyam Section 63 (electronic evidence), where the chain of custody for the underlying device must be demonstrable.

A modern Indian smartphone carries three distinct storage tiers from the examiner's view. The SIM is the smallest and most regulated; the internal user-data partition is the densest; the external SD card (where present) is the most variable. Each tier needs a different acquisition path and yields a different evidence class.

The SIM card carries an ICCID (Integrated Circuit Card Identifier, 19 to 20 digits printed on the SIM and burned into ICCID file 0x2FE2), an IMSI (the subscriber identity used at the cellular layer), and a small EF (Elementary File) tree with operator-defined data. Practical evidence on a SIM is limited and shrinking: the SMS storage area (EF_SMS) holds the last few messages the OS chose to store on the SIM rather than in the OS database, the ADN (Abbreviated Dialling Numbers) phonebook holds contacts the user explicitly saved to the SIM, the LND (Last Numbers Dialled) file holds recent dialled numbers, and the LOCI file holds the last cell ID the SIM registered with. Most modern Android and iOS handsets store contacts and SMS in OS databases rather than on the SIM, so the SIM yield is small. The SIM is read with a smart card reader (a basic PC/SC reader plus pyscard, or the Cellebrite UFED SIM extractor) and the data is dumped through the operator's STK (SIM Toolkit) interface.

Internal memory is the volume case for forensics. The user-data partition holds the app sandboxes (each app's /data/data/<package>/databases/ and /data/data/<package>/files/ on Android, the equivalent in the container path on iOS), the Photos and Videos camera roll, the Downloads folder, the system logs (/data/system/, /data/log/, dropbox logs on Android), the call log database, the SMS database, the location-history databases (Google Location History cache, Apple Significant Locations), the Wi-Fi network history, the Bluetooth pairing history, and the deleted-but-not-yet-overwritten regions that file system extractions and physical extractions reach. The relative density per app is the working examiner's mental model: WhatsApp's msgstore.db plus the media cache typically yields the highest-volume content per case; Google Maps Timeline yields the highest-fidelity location data; Truecaller and the dialler database yield the most reliable contact resolution.

External memory is where the user stored what the OS would not. SD cards still carry photos, videos, app caches, WhatsApp media (when the user moved it off internal storage), encrypted backups and occasional deliberate evidence hiding (steganographic image hosts, encrypted containers). The SD card is removed and imaged separately with a write-blocker (USB write-blocker for forensics, or a Linux blockdev --setro on a mounted device) using dd or dc3dd for the bit-for-bit copy, then carved with photorec or scalpel for deleted content. Carving recovers JPEG, MP4, PDF and similar files even when the file system metadata is gone, because the format-specific headers and footers are recognisable in raw blocks. The full carving workflow lives at data recovery and file carving.

The forensic interpretation per data class is its own discipline. Call logs and SMS reconstruction from calllog.db and mmssms.db (Android) or CallHistory.storedata and sms.db (iOS) is straightforward. Location data reconstruction requires understanding the source-specific quirks: Google Location History Records.json is per-event with confidence radii; Apple Significant Locations is aggregated by visit and stored on-device only, requiring file system extraction; Wi-Fi positioning history is in wpa_supplicant.conf plus per-OS scan caches; BLE beacon proximity is in app-specific logs. Social media app data lives in the app sandbox under app-specific schemas: WhatsApp's msgstore.db with WAL pages, Telegram's cache4.db, Signal's encrypted SQLite with the key in Android Keystore. The cross-link to mobile operating systems and SQLite covers the per-app database layout in depth.

NIST Special Publication 800-101 Revision 1, "Guidelines on Mobile Device Forensics" (2014, still the working reference) defines a six-level extraction ladder. The ladder is doctrine in Indian state cyber cell training and at CFSL Hyderabad's mobile forensics laboratory. The examiner climbs only as far as needed; each level costs more time and more risk than the level below.

1. Level 1: Manual extraction
   The operator navigates the phone's UI directly and photographs or videos each screen of interest. No tool, no cable, no risk to data integrity, but very limited yield: only what the user could see at the lock-screen plus the apps the operator can open with the user's passcode. Used as a first pass when the phone is unlocked and a logical acquisition is queued.
2. Level 2: Logical extraction
   OS-exposed backup APIs: ADB backup on Android (pre-Android 12 limited; backup-disable flag respected), iTunes/Finder backup on iOS (encrypted backup with known password gives more), MTP for media. Fast and reversible but limited to OS-exposed files. App data not in the backup whitelist is not recovered.
3. Level 3: File system extraction
   Full file system dump including system partitions, app sandboxes, and unallocated regions visible at the file system layer. Requires elevated access: ADB with root on Android, Cellebrite's AFU exploit chain on iOS, or a vulnerability the tool vendor has weaponised. Yields system logs, deleted SQLite rows in WAL, and Keychain entries on iOS.
4. Level 4: Physical extraction
   Bit-for-bit image of the NAND through the SoC. On Android with a supported chipset (Qualcomm EDL mode, MTK BootROM, Spreadtrum) the tool puts the device into a low-level mode and dumps the raw NAND. On iPhones 6s and earlier the checkm8 BootROM exploit enabled physical for forensic purposes; later iPhones do not. JTAG is the practical Level 4 path when boot-mode physical is unavailable.
5. Level 5: Chip-off
   Desolder the NAND or eMMC chip from the PCB, place it in a NAND reader (UFI Box, eMMC Pro, Medusa Pro), and read the raw flash directly. Bypasses any locked-bootloader or live-OS constraint. Destroys the device. Used when JTAG access is unavailable, the device is damaged, or the device's encryption is tied only to a key that survives the chip removal.
6. Level 6: Micro-read
   Electron microscopy of the NAND memory cell gates to read charge states directly. Research-grade, costs in the hundreds of thousands of dollars, and is not in the routine workflow of any Indian state cyber cell or CFSL lab as of 2026. Treated as the theoretical ceiling of the ladder.

The trade-off at each level is the practical guidance. Levels 1 and 2 are fast (minutes to a couple of hours), reversible, and yield maybe 30% of what a full physical extraction would recover. Level 3 is the workhorse: most modern cases stop here because the file system extraction includes the app sandboxes that contain the case-relevant evidence, and the cost (a few hours per device on Cellebrite UFED with a current licence) is acceptable. Level 4 is reserved for cases where Level 3 hits a locked partition or the case requires unallocated-space carving. Levels 5 and 6 are reserved for damaged devices, locked devices that exploits cannot bypass, and cases where the loss of the device is acceptable to the case's evidentiary needs.

The Indian anchor here is the CFSL Hyderabad mobile forensics SOP, last revised in 2024, which formally adopts the NIST six-level ladder and adds an India-specific Level 0 step: a documented attempt at user-consented unlock and PIN entry, photographed and timestamped, before any tool acquisition. This Level 0 step exists because Indian courts under Bharatiya Sakshya Adhiniyam Section 63 expect a clear chain of attempts that did not coerce the suspect, and an unprompted user-provided passcode resolves the bulk of acquisition friction at zero cost when the suspect cooperates.

JTAG extraction is the bridge between software-only physical acquisition and full chip-off. The Joint Test Action Group standard (IEEE 1149.1) defines a Test Access Port left on most phone PCBs for manufacturer-side debugging. The TAP exposes a Boundary Scan interface that, with the right command sequence, lets a forensic tool read the NAND memory through the SoC without removing the chip. The practical work is locating the JTAG test points on the board (vendor schematics, board-view files leaked or licensed from repair shops, or community resources like the AllinBox or Z3X database), soldering thin enamelled wires to the test points, and connecting them to a JTAG interface tool.

The JTAG workflow has six practical phases. The examiner identifies the phone model and locates the board diagram; opens the phone with manufacturer-specific separators and heat; locates the JTAG test points (typically labelled TPxx on the PCB); solders enamelled wires using a fine-tip iron and a steady microscope; connects the JTAG tool to the board; powers the board through the tool's controlled supply; reads the eMMC or UFS through the SoC into a raw image file; and re-images the board to verify the read. The whole operation takes between two and six hours depending on board complexity and examiner skill. The output is a raw image identical to what a chip-off would produce, with the advantage that the device is still functional and can be returned to the owner or retained for re-acquisition.

Chip-off is the destructive alternative. The examiner desolders the NAND (or in modern phones the combined eMMC or UFS package, which is a single BGA chip on the PCB) using a hot-air rework station at 280 to 320 Celsius with low-residue flux, lifts the chip, and reads it in a specialised NAND or eMMC programmer (UFI Box for eMMC, Medusa Pro with NAND adapter, ProgSkeet for raw NAND). After reading, the chip may be reballed (replacement solder balls applied to the BGA pads using a reballing stencil and a hot-air pass) and re-soldered to the original board or to a donor board to verify the read. The verification step is non-trivial; most chip-off in Indian state cyber cells is one-way (chip read, image preserved, chip not returned to the board).

Chip-off use cases in Indian state cyber cell labs cluster around three scenarios. First, water damage: a phone dropped in a river or sewer that no longer boots after 48 hours of rice. JTAG often fails because the board's TAP traces are corroded; chip-off lifts the NAND from the corrosion. Second, fire damage: a phone burned but the chip package intact. The PCB is unusable; the chip is read in a programmer. Third, severe physical damage plus device lock: a screen-smashed phone where the user cannot enter the passcode and JTAG is unavailable on the model. In all three the FBE caveat applies: chip-off recovers ciphertext, and the user passcode (or a Cellebrite-Premium-grade passcode brute-force capability) is still required to decrypt.

The commercial mobile forensics market is dominated by four vendors and a long tail of niche tools. Indian state cyber cells and CFSL Hyderabad standardised on Cellebrite UFED as the primary acquisition platform from around 2015 onward; Magnet AXIOM Mobile was added widely from 2019 onward as a cross-validation and analysis tool; MSAB XRY (Sweden) and Oxygen Forensic Detective (originally Russia, with significant team relocation to Czech Republic after 2022) appear in select labs. Belkasoft Evidence Center and MOBILedit Forensic appear in smaller deployments and at private digital forensic consultancies.

The workflow in a representative Indian state cyber cell case proceeds as follows. The phone arrives in a Faraday bag with a chain-of-custody form. The examiner records the case number, takes high-resolution photographs of the device, and queues the device for acquisition on the Cellebrite UFED Touch 2 or 4PC station. Cellebrite's Selected Manufacturer flow identifies the make and model and prompts the examiner to pick the acquisition profile (Logical, File System, Physical, Advanced Logical). For most Android devices below Android 13 with a Qualcomm or MediaTek SoC, an Advanced Logical or File System acquisition completes in 2 to 6 hours. The output is loaded into Physical Analyzer for parsing. Cross-validation against Magnet AXIOM Mobile runs in parallel on a second workstation against the same image, and the parsed output (timelines, contact graphs, location maps, chat exports) is compared. Discrepancies are investigated; consistent output is exported into a structured case file.

The open-source stack matters for two reasons. First, validation: a parser is only as good as its assumptions, and a critical case benefits from running iLEAPP (iOS) and ALEAPP (Android) against the same image as Cellebrite and Magnet to catch parser drift. Second, court-facing reproducibility: open-source tools allow defence experts to verify the examiner's results without licensing Cellebrite. Indian courts under BSA Section 63 require that the process be demonstrable; an open-source replay of a key artefact (a deleted WhatsApp message recovered from WAL, say) significantly strengthens the report. iLEAPP and ALEAPP, maintained by Alexis Brignoni and the Brigs/community team, are the de facto standard open-source mobile parsing toolkit and are widely used in both academic and professional digital forensics training.

Location reconstruction from a mobile device draws on four data layers, each with different fidelity and a different acquisition path.

Cell tower data is the foundation, especially for the period before the device is in the examiner's hands. The Indian telco supplies a Call Detail Record (CDR) under a Section 91 CrPC (now BNSS Section 94) request from the investigating officer. The CDR lists every call, SMS and data session for the target MSISDN within the requested period, with timestamps, duration, originating and terminating party, and the cell ID the device was registered with at the time of each event. The cell ID, mapped to the telco's tower coordinates, places the phone within a sector (a slice of the cell tower's coverage, typically 120 degrees wide) at each event. Multiple events at known towers across an evening triangulate a movement path. Indian state cyber cells run CDR analysis as a near-routine first step in any phone-linked case; the typical timeline is two to ten business days from request to receipt of CDR.

GPS data, where the user enabled it, is the highest-fidelity source. Google's Location History (when the user opted in) is stored at com.google.android.gms on the device and as a Google Takeout export Records.json from the Google account; each record has a latitude, longitude, accuracy radius (often 10 to 100 metres in open sky), timestamp, source (GPS, Wi-Fi, cell), and the device that originated the record. Apple's Significant Locations is stored on-device only at ~/Library/Caches/com.apple.routined/ (file system extraction required) and aggregates frequent visits with timestamps. App-specific GPS logs (Uber, Ola, Zomato, Swiggy, Google Maps Timeline) supplement the OS-level data and are often the highest-fidelity record of a specific journey.

Wi-Fi positioning fills the gap when GPS is unavailable indoors. Phones scan Wi-Fi networks continuously and submit BSSID-to-location samples to Google (via Google Play Services) and Apple (via the Location Services API). Forensic look-up of a BSSID in the WiGLE database (a community-maintained BSSID-to-coordinate map) or in the device's own scan cache (wpa_supplicant, iOS com.apple.wifi.plist) places the phone within range of a known AP at a known time. BLE beacon proximity, less common in current Indian deployments outside large airports and malls, adds another fidelity layer.

1. CDR request: file under BNSS Section 94 (formerly CrPC 91)
   The IO drafts a notice to the relevant telco listing the target MSISDN(s) and the period of interest. Common period: one to three months. Bharti Airtel, Reliance Jio, Vi (Vodafone Idea) and BSNL respond with a structured CSV or Excel containing per-event rows. Some telcos add a separate cell-tower master file mapping cell ID to lat/long.
2. Parse and normalise: ingest CDR into a CDR analysis tool
   Tools used in Indian state cyber cells include Cellebrite Pathfinder, Magnet AXIOM Cloud with CDR import, and home-grown Excel+QGIS workflows. The normalised data has one row per event with timestamp, party, duration, type (call in/out/SMS in/out/data), cell ID and tower coordinates.
3. Tower-plot the events on a map
   Each event is plotted at its tower's coordinates. A sector colour or arrow indicates the antenna direction. The result is a movement chart showing where the phone was at each event. Gaps (no events for a few hours) are noted; the phone may have been off, in a low-coverage area, or simply not used.
4. Triangulate where multiple cells are involved
   When an event involves a soft hand-off between cells, the device's position can be triangulated more precisely between three known towers. Most consumer-grade CDR analysis does not exploit this and rests on sector-level resolution.
5. Correlate with device-side location data
   Once the phone is acquired in the lab, cross-check the CDR-derived movement against Google Location History, Apple Significant Locations, and app-specific GPS logs. The cross-check tightens the temporal and spatial fidelity from sector-level to GPS-grade where the device-side data is available.

Deleted and encrypted data recovery extends the acquisition workflow beyond initial extraction. SQLite is the dominant database format on both Android and iOS, and SQLite's Write-Ahead Log holds recent transactions that the main database has not yet absorbed. Deleted rows often survive in the WAL file for hours or days after the user-visible deletion. Tools like Andriller and the SQLite Forensic Toolkit parse WAL pages and recover deleted records. The cross-link to mobile operating systems and SQLite covers the schema-level details.

Live ADB pull while the phone is running unlocked is the highest-yield deleted-data recovery technique on Android. The examiner ADBs into the device, becomes root if available, and copies the WAL and the journal files for the target databases (WhatsApp's msgstore.db-wal, the SMS provider's WAL, the call log WAL) before they are merged or zeroed. On a rooted or jailbroken device, a full file system pull retrieves the same plus the device's keychain and Keystore-protected keys, enabling decryption of certain app data offline. Chip-off plus a passcode brute-force is the last-resort path for deleted-data recovery on a locked, modern, FBE-encrypted device.

The Indian anchor for this section is the body of CDR-driven case work that Indian state cyber cells produce monthly. The 2G spectrum case at the CBI in 2011 to 2014 included CDR analysis as a key plank of the prosecution's timeline, mapping accused parties' phones to meeting locations across a multi-month window. More recent Indian state cyber cell work, including the 2023 Karnataka SIM-swap and UPI fraud crackdown, used CDR plus device-side GPS plus Google Location History together to triangulate a Telegram-coordinated mule network across three states. CDR analysis is so routine in Indian cyber cell practice that it features as a core lab module in forensic science training programmes.