Case Study 2 — The Phone That Rebooted

DataField.Dev

Case Study 2 — The Phone That Rebooted

A locked phone arrived at the lab in the best possible state — powered on, unlocked since boot, its keys live in memory — and left it as an inert brick of ciphertext. Nothing was hacked and nothing was cracked; a chain of small, avoidable handling errors simply let an AFU device fall to BFU on hardware where that transition is a one-way door. This is the cautionary contrast to the easy win: on mobile, the case is often lost or won before the examiner ever runs a tool.

Background

A stalking-and-criminal-threats investigation hinged on a single device. The complainant had received escalating threatening messages over several weeks; the suspect denied authorship and denied even owning the number. Investigators obtained a warrant for the suspect's phone — a current-generation iPhone, an A13-class device — and seized it during an arrest. Critically, the phone was powered on and unlocked at the moment of seizure: the suspect had been using it. In the language of this chapter, it was AFU — booted and unlocked at least once since boot, its Data Protection (Class C) keys live in memory, the bulk of its data decryptable in place. Acquired promptly and correctly, that device would almost certainly have given up the message databases, the deleted records in the write-ahead log, the location traces, and the account identifiers that would have tied the threats to the suspect.

It gave up nothing. By the time it reached the forensic examiner's bench three days later, the iPhone was at the lock screen demanding a passcode nobody knew — and on an A13, locked, BFU, passcode unknown, with no exploit available for its iOS version, that is the wall the chapter describes as final. The data was still physically present in the NAND, every encrypted bit of it, and permanently unreadable. The contrast with Case Study 1 is exact: there, sound handling and a high-level extraction made the case; here, the evidence was identical in potential and lost entirely to procedure.

What happened

The failure was not a single dramatic error but a chain of small ones, each individually survivable, that together walked a perfect AFU device into a forensic dead end.

  AFU at seizure  ──X──►  network left on  ──X──►  allowed to lock & sit
        │                       │                        │
        │              remote-lock attempt        battery drains over
        │              pushed to the device         a long weekend
        ▼                       ▼                        ▼
   keys live in RAM   ───────────────────────────►  device powers off,
   (decryptable)                                     reboots to BFU on
                                                     next power-up
                                                          │
                                                          ▼
                                          A13 + locked + BFU + unknown passcode
                                                  =  EXTRACTION NOT ACHIEVABLE

Error one: no immediate network isolation. The phone was bagged in an ordinary evidence envelope, not a Faraday bag, and airplane mode was never enabled. For most of a day it remained reachable on the cellular network. Someone with access to the suspect's account pushed a remote lock to the device (a remote wipe may also have been attempted). Network isolation at the scene — a Faraday bag, or even airplane mode entered before bagging — would have severed that channel instantly. This is the chapter's second common mistake, committed in the first ten minutes.

Error two: the AFU state was not preserved. Nobody kept the device powered and awake, and nobody understood that they needed to. It was allowed to lock; it was not connected to a battery pack; and it sat in property storage over a long weekend. The battery drained. When it died, the iPhone powered off — and on the next power-up it booted to BFU, evicting the in-memory keys that had been the whole prize. The single most consequential field error in mobile forensics, exactly as the chapter names it: letting a seized AFU phone reboot, lock, or die.

Error three: no triage urgency. Because the device's state was not understood to be perishable, nothing was treated as time-critical. A phone is not a hard drive; a hard drive's data is the same whether you image it today or next month, but an AFU phone's accessibility has a clock on it. Had the seizing officers known to write "AFU — do not let it power off, isolate immediately, expedite to the lab," the examiner would have received a live, decryptable device instead of a brick.

By the time the examiner saw it, there was nothing to do but document the loss honestly. The chain of custody recorded the seizure state (powered on, in use), the absence of network isolation, the discharge, and the BFU lock screen on arrival. The examiner determined the model and OS version, confirmed no exploit was available for that version, and wrote the only finding the device now supported:

  Device: Apple iPhone (A13-class), iOS [version], locked, BFU on receipt.
  Seizure state (per CoC): powered on and unlocked (AFU).
  Network isolation at seizure: none documented; remote-lock observed.
  Acquisition attempted: none feasible — no extraction method available for
     this model at this OS version in a locked/BFU state, passcode unknown.
  Finding: Extraction was not achievable. Data is present but encrypted and
     inaccessible by any means available to this examiner.

That sentence — "extraction was not achievable" — is a complete, professional finding. But here it was not a fact of mathematics the way it is for a never-backed-up locked phone in Chapter 11; it was a self-inflicted wall. The evidence that would have corroborated the complainant's account, and either confirmed or cleared the suspect, was reachable for the better part of a day and was lost to handling. The prosecution proceeded on the complainant's testimony and the carrier records alone, a materially weaker case than the phone would have made.

The analysis

On mobile, the case is often decided before the examiner touches it. Unlike a hard drive, a phone's accessibility is perishable. An AFU device with live keys is a fundamentally better — and time-limited — evidence prospect than the identical device powered off. First-responder handling, not lab skill, set the ceiling here, and the ceiling was the floor.
Network-isolate immediately, every time. A phone left on the network can be remotely locked or wiped before acquisition. A Faraday bag (or airplane mode entered before bagging) at the scene severs that channel. Skipping it is a ten-minute error with permanent consequences.
Preserve AFU state as if it were volatile evidence — because it is. Keep the device powered, keep it from locking-and-rebooting, keep it from dying: a battery pack in a shielded enclosure, charging, lock disabled where policy allows. A reboot evicts the in-memory keys, and on A12-and-later hardware that transition is effectively irreversible.
State at seizure must be recorded and acted on. "AFU — expedite, isolate, do not power off" belongs on the evidence record the instant the device is seized. The examiner three days later cannot undo a reboot; only the people in the first ten minutes can prevent it. Triage urgency is part of the chain of custody, not separate from it.
An honest "not achievable" is correct — but a self-inflicted one is a training failure. The finding the examiner wrote was professionally sound; the loss it described was avoidable. The lesson is not that the wall is real (it is) but that this particular wall was built by procedure. Distinguishing the unavoidable limit from the avoidable one is what separates a mature program from one that keeps losing cases it could have won.

Discussion questions

The phone was AFU at seizure and BFU on arrival. Identify the three handling errors in the chain and, for each, name the specific action that would have prevented it and who was positioned to take it.
Why does the A-series generation matter so much to this outcome? Walk through how this case would have differed on an A11 device (checkm8-eligible) versus the A13 here — and what that contrast says about building a case on a phone whose model you have not yet identified.
The examiner's finding — "extraction was not achievable" — is identical in wording to the honest "no" for a never-backed-up locked phone in Chapter 11. Explain why the two are profoundly different in cause, and why that difference matters for an agency's after-action review even though the report sentence is the same.
Draft the one-line instruction that should accompany every seized powered-on phone, and the short first-responder checklist (three to five items) that would have saved this case. Where should that checklist live so it is actually used at 2 a.m. at a scene?
⭐ The prosecution proceeded on testimony and carrier records alone. Argue both sides of a hard question: does the absence of the phone evidence cut only against the prosecution, or can a defense also exploit "the investigators destroyed the one neutral source that could have cleared my client"? How does sound documentation of the loss (the chain-of-custody record of the mishandling) affect each side's argument — and what does that say about why you document even your own program's failures?