ZEKASTRA

SOP-05 · Isolation, extraction type, verification

Mobile device acquisition

Documenting a phone's state, keeping it isolated, choosing and recording the extraction type, hashing the archive and noting what the extraction cannot contain.

01Purpose and scope

To obtain data from a mobile device in a manner whose completeness is known and stated, with the device's state before and after documented.

Smartphones, tablets, feature phones, SIM cards and memory cards, and computer backups of such devices. Covers the examination laboratory's handling; it does not describe security bypass techniques.

02Prerequisites

  • Authority covering the device and the data categories to be extracted.
  • Network isolation maintained since seizure and documented.
  • Extraction tools validated for the device model and OS version where possible (SOP-10).

03Steps

  1. Record the device state

    Photograph the device and screen. Record model, OS version if visible, IMEI, serial, SIM/ICCID, battery level, lock state, isolation method and the time displayed by the device against the reference clock.

    RecordDevice state section; clock offset.

  2. Maintain isolation throughout

    Work in a shielded environment or keep airplane mode with radios off. If the device must be connected to a workstation, the workstation is offline. Any change to isolation is logged with time and reason.

    RecordIsolation log.

  3. Handle SIM and memory cards separately

    Remove, photograph and record ICCID; image memory cards with SOP-04. Read the SIM with a dedicated reader; do not exceed PIN attempts.

    RecordCard identifiers and separate custody lines.

  4. Select the extraction type and record why

    Logical, file-system, full file-system or physical, in order of completeness. Choose the most complete type the tool supports for this device and the authority permits; record the type, the tool, its version and the reason if a less complete type was used.

    RecordExtraction type, tool, version, justification.

  5. Perform the extraction and hash the output

    Record start and end times (UTC), warnings and errors reported by the tool, the archive name, size and hash. Where the tool produces an internal file list with hashes, keep it with the archive.

    RecordExtraction record; archive hash.

  6. Record the device state afterwards

    Photograph the screen again; note any change caused by the extraction (installed agent, changed settings) so that it is not later mistaken for user activity.

    RecordPost-extraction state and changes.

  7. State the limits

    Write, in the record, what this extraction type does not contain for this platform: for example, deleted records, system databases not included in a logical extraction, app data excluded by the app's own settings.

    RecordLimits statement.

04Records produced

  • Device state before and after, with photographs and clock offset
  • Isolation log
  • Extraction record with type, tool, version, times, errors and archive hash
  • Limits statement

05Pitfalls

  • A device that reconnects to a network for seconds can receive a remote wipe or sync that changes the evidence.
  • Reporting a logical extraction's empty result as 'no messages' is a false negative; the type must be stated.
  • The extraction agent and its settings changes appear in later usage records.
  • Tool parsers lag app versions; verify parsed results against the raw database for any contested record.

06Forms

07Standards

  1. NIST SP 800-101 Rev. 1 — Guidelines on Mobile Device Forensics
  2. SWGDE — Best practices for mobile device evidence collection, preservation and examination
  3. ISO/IEC 27037:2012 — Identification, collection, acquisition and preservation of digital evidence