Mobile Phone Forensics: Data Acquisition, JTAG and Chip-Off

Document visible state and identify immediate safety, remote-change, access and power risks before unnecessary interaction. Damaged batteries or wet/fire-damaged devices need appropriate specialist handling rather than routine charging.

Radio isolation can limit remote changes, but it can also increase power drain or interrupt useful access. Validate the chosen enclosure or supported configuration. Airplane mode can leave radios enabled, and removing a physical SIM does not remove Wi-Fi or eSIM connectivity.

Do not assume a fixed attenuation specification covers every device/band or that opening a bag for a cable preserves shielding. Record enclosure condition, closure and power arrangements under the actual procedure.

Unlocked, locked after first unlock and freshly booted states have different consequences. A locked screen does not mean every credential-encrypted item is unavailable, nor does an unlocked screen mean every item or key is accessible.

Changing timeout settings, unlocking, pairing or installing an agent changes state. Use an appropriate supported method, document why and record the footprint. Neither powering off nor keeping running is universally correct.

Record identifiers from available nonintrusive sources where possible. Do not dial or remove components just to fill a checklist when doing so risks access. Seal and track devices, cards and accessories with their relationships and actions.

Potential sources include internal storage, SIM/UICC applications or eSIM profiles, removable media, volatile state, linked endpoints and separately available cloud data. Scope and access differ.

SIM records can include selected identifiers and stored messages/contacts where present. They are not a complete handset history or precise last-cell location record. Standard card acquisition uses supported card/application commands, not merely the user-facing SIM Toolkit menu.

Internal storage can contain app data, media, configuration and system records under version-specific paths. A filesystem extraction need not include unallocated space or every key, and raw flash access may yield protected bytes only.

Removable storage may be portable or adopted/encrypted with device dependencies. Assess that relationship before removal or standalone interpretation. Use appropriate acquisition and write protection, not a command applied after mounting as a universal hardware blocker.

Location, contact and message sources have different quality and retention. A crowdsourced contact label is not automatically reliable identity, and an app cache is not necessarily the provider’s full record.

Preserve the acquisition’s selection, errors, exclusions and manifest. Report sources actually obtained rather than a standard list of everything a phone might store.

NIST SP 800-101 Revision 1 (2014) uses five acquisition levels: manual, logical, physical, chip-off and micro-read. It does not define the six-level ladder previously attributed to it. Modern filesystem-extraction labels should be described separately.

Select the least risky method that answers the question and preserves necessary context. Escalation is a case-specific decision, not a fixed percentage-yield or hours-per-device rule.

Micro-read is an exceptional research-level concept in the historical taxonomy, not a routine contemporary promise. Current device support must be verified independently of that 2014 classification.

Known credentials and tool exploits can help under specific conditions. Neither a short PIN nor a raw chip image guarantees offline access; hardware-bound keys, retry controls and the actual implementation matter.

JTAG can provide test/debug access through applicable components where enabled and supported. Boundary-scan compliance alone does not guarantee a complete memory-read facility or an unlocked production interface.

ISP accesses a supported storage interface in circuit, while chip-off removes a component for separate reading. They use different paths and can expose different representations from a processor-mediated acquisition.

Assess the model, board condition, storage type, encryption and tool support before hardware work. Screen repair or supported display/input access may be lower risk than component removal when appropriate.

There is no universal soldering temperature, pinout, timing or read duration. Use a validated device-specific procedure with specialist skill and record interventions, settings, errors and resulting data.

Repeated reads can help identify instability, but equal hashes do not establish that every hidden or protected area was accessed. Managed eMMC/UFS can expose logical data without all controller-internal flash pages.

Hardware-linked encryption can require the original platform and usable key hierarchy. A passcode entered into software against a removed ciphertext image is not a universal decryption route. Evaluate whether preserving or repairing the original board is necessary.

Chip-off risks damage and can be irreversible; it does not invariably destroy every device, and successful reassembly is not guaranteed. Preserve components and document feasibility and authority before escalation.

Acquisition tools and analysis parsers serve different roles. Check exact model/OS/app support, access conditions, installed version and the method used rather than infer broad coverage from a vendor name.

Commercial platforms such as Cellebrite, Magnet and MSAB offer different capabilities under their actual products and licences. Avoid unsupported market-share rankings, fixed extraction times or claims about what named laboratories own.

iLEAPP and ALEAPP parse supported acquired artefacts; they do not universally acquire locked devices. MVT focuses on consensual analysis for traces of compromise and is not a replacement for every full mobile acquisition.

Compare important parser output with underlying records and an appropriate independent method. Two tools can share assumptions, so agreement is useful without proving correctness.

Preserve source paths, record IDs, raw values, decoded values, time conversions, warnings and extraction scope. Derived graphs and reports should remain traceable to acquired material.

Reproduction can require licensed or specialised tooling, but the relevant logic and limitations should still be explained. Open-source output is not itself a legal admissibility guarantee.

Cellular records, GNSS/location-service data, Wi-Fi observations and app-specific coordinates describe different events. Establish source meaning, time, uncertainty and retained coverage before combining them.

A tower coordinate is the infrastructure location, not the handset location. Sector coverage is not a perfect fixed-angle wedge, and sequential tower events are not automatically triangulation.

GNSS-derived or fused location can be inaccurate, cached, manipulated or associated with another account/device. A stored point and confidence field need the actual schema and sampling behaviour interpreted.

Wi-Fi mapping databases can be outdated, crowd-sourced or affected by moved/spoofed access points. Seeing a network reference does not by itself prove a completed connection or exact position.

Plot observations with their uncertainty and source labels; do not join isolated points into a continuous movement path without support. A device’s possible location is separate from its user’s presence.

Deleted-data recovery depends on retained bytes, encryption, reuse and application behaviour. WAL presence does not guarantee a fixed hours-to-days recovery window, and ADB pull is not universally the highest-yield or coherent method.

For app-record and sidecar interpretation, use Android and iOS App Forensics. Report intact records, recovered fragments and missing coverage separately.