Inside the Phone Crackers: How Forensic Extraction Tools Work, and Why the Bench Has to Be RF-Quiet

Ask most people how a tool like GrayKey or Cellebrite gets into a locked iPhone and you'll hear some version of "there's a secret backdoor." There isn't. What these tools actually do is stack up a handful of unglamorous engineering advantages — a device left in the right state, an unpatched bug in a driver nobody thinks about, and enough guesses per second to make a short passcode fall — and grind their way in.

Understanding that chain matters to us at JRE Test for one specific reason: every link in it depends on the phone sitting still, in a known state, wired to a workstation, for hours or days at a time. And a phone that can hear a cell tower is a phone that will not sit still. That is an RF shielding problem, and it is why the forensics bench looks less like a repair counter and more like an RF test setup.

This paper walks through how the extraction tools work at a conceptual level, why the modern countermeasures have made the state of the seized device the whole ballgame, and how the JRE 1812F Forensics Analysis Enclosure is built around that reality.

Start with the thing standing in the way. On any current smartphone, the storage is encrypted at rest, and the key isn't stored anywhere an attacker can simply copy. It is derived from two ingredients: the user's passcode, and a secret fused into a dedicated security chip at manufacture — Apple's Secure Enclave, Google's Titan M, or the equivalent in other silicon.

That combination is what makes the problem hard. You cannot lift the flash chip off the board and read it, because what you'd get is ciphertext. You cannot extract the hardware secret, because it never leaves the security chip. And you cannot simply guess the passcode a few million times, because the security chip enforces the guess limit and the escalating delays in hardware — it doesn't matter what you do to the main processor or the operating system, the security chip counts your attempts and eventually stops answering.

So the tools don't attack the encryption. They attack everything around it.

If you take away one technical idea from this paper, make it this one.

BFU — Before First Unlock. The device has been powered on but the passcode has never been entered since boot. The user data keys do not exist in memory. Almost everything on the device is genuinely, mathematically inaccessible. What an examiner can pull is thin: some unprotected system files, basic device identifiers, maybe a little metadata.

AFU — After First Unlock. The passcode has been entered at least once since the last boot. Now the keys are decrypted and sitting live in system memory, and the lock screen has quietly changed character. It is no longer a cryptographic barrier — it is a user interface element. The data underneath is already unlocked; the screen is just refusing to draw it. Get code execution on the device and a large fraction of the file system is readable.

The gap between those two states is enormous. It's the difference between a handful of artifacts and a full file system image. Which is why the first rule of seizing a phone is don't let it power down and don't let it reboot, and why the countermeasures we'll get to in a moment are aimed squarely at forcing devices back to BFU.

Working from that foundation, commercial extraction tools pull on three levers.

1. Code execution via an unpatched bug. This is the real product being sold. These vendors are not discovering fundamentally new cryptography — they are industrializing exploitation, maintaining a rotating inventory of vulnerabilities matched to specific hardware and firmware combinations. The most valuable ones live in the boot ROM, the immutable first-stage code baked into the silicon. Because boot ROM code is mask-programmed and cannot be patched by a software update, a flaw there is permanent for the life of that chip — Apple's checkm8 is the well-known example, affecting a generation of iPhones that will never be fixed.

Where boot ROM exploits aren't available, the USB interface is the next-best door. An AFU device exposes a surprising amount of kernel code to whatever is plugged into it — video class drivers, audio drivers, HID drivers, hundreds of them. A tool that can impersonate a rapid sequence of different USB peripheral types gets to knock on all of those doors looking for one that's unlocked. Several real-world extraction chains have been built exactly this way.

2. Brute force at speed. Once there's code execution, the passcode still has to be found. If the guessing has to go through the security chip — and on modern hardware it does — each attempt is rate-limited no matter how fast the attacker's hardware is. That single design decision is what makes passcode length so decisive. A four-digit PIN falls quickly under almost any conditions. Six digits is a matter of time. A long alphanumeric passphrase, checked against a chip that enforces backoff, is realistically out of reach.

3. Harvesting what's already decrypted. On an AFU device, a good share of the work is simply reading keys and cached data out of live memory. No cryptanalysis required — the device already did the hard part when the owner typed the passcode.

Since roughly 2018 the platform vendors have been closing this down deliberately, and the two most consequential changes both target device state.

USB Restricted Mode shuts off the data pins on the phone's port after a period without an unlock, leaving charge-only. The USB attack surface — those hundreds of drivers — simply stops answering the door.

Inactivity reboot is the bigger one. Beginning with iOS 18, an iPhone that sits locked and untouched reboots itself, and Apple tightened the timer to 72 hours in iOS 18.1. The reboot dumps memory and drops the device straight back to BFU. This closed a strategy examiners had relied on for years: seize a phone in AFU, keep it powered, and park it on a shelf until a tool version shipped that could handle it. That shelf now has a three-day expiration date.

The practical consequence for the lab is a countdown clock. From the moment a device is seized in a useful state, there is a bounded window in which the good extraction is possible — and everything the examiner does in that window has to happen without the device rebooting, without it losing power, and above all without it hearing anything from the outside world.

Here is the part that gets underestimated.

A seized smartphone with a live radio is not a passive piece of evidence. It is a networked endpoint that is still logged in to its owner's account. The moment it reassociates with a cell tower or a known Wi-Fi access point, several things can happen, none of them good:

• Remote wipe. Find My, Android's device manager, and any enrolled MDM can issue an erase command. It executes in seconds. Depending on the case, that is the destruction of the only copy of the evidence.
• Remote lock or credential change. A password change pushed from the account side can invalidate a state the examiner was depending on.
• State drift. Incoming messages, sync operations, background app refresh, and OS updates all write to the device. Every one of them alters the exhibit after seizure, and every one is something defense counsel gets to ask about.
• Location leakage. A phone that checks in tells whoever is watching the account roughly where the lab is and that the device is powered.

The standard answer at the point of seizure is a Faraday evidence bag, and it's the right answer for transport. But a bag is a sealed container. You cannot work in one. The extraction itself needs a USB cable to a workstation, mains power to keep the phone alive against the 72-hour clock, a view of the screen, and hands on the device — all while the radios stay dead. That is precisely the job an RF shielded test enclosure was invented for, and it is why forensic labs increasingly run acquisitions inside a chamber rather than on an open bench.

Worth stating plainly: the enclosure is a containment tool, not an access tool. It doesn't help anyone get into a phone. What it does is make sure that the phone you finish with is the phone you started with.

Translating all of the above into shielding requirements:

Continuous attenuation across every radio the device has. Not just cellular. A modern handset will also try Wi-Fi, Bluetooth, GNSS, NFC, and increasingly UWB. Any one of them is a path to a sync or a wipe command. The word that matters is continuous — a shield with good numbers at 900 MHz and a hole at 2.4 GHz is not a shield.

Enough margin over ambient, not laboratory-grade dynamic range. This is a different problem from RF conformance measurement, and it's worth being precise about why. A test lab measuring low-level spurious emissions needs 90–100 dB of isolation because it is trying to see signals near the noise floor. A forensics enclosure only has to defeat real-world ambient signal levels. A cellular downlink at a bench is typically somewhere around −60 to −90 dBm; a phone needs roughly −110 dBm to camp on a tower at all. Knock 70–80 dB off a −60 dBm signal and you are down around −130 to −140 dBm — well beneath what any receiver can do anything with. The device sees nothing, hunts, and gives up.

Hand access that doesn't break the seal. The examiner has to swipe, tap, seat cables, and press buttons. Anything that requires opening the door mid-acquisition defeats the purpose.

Visibility. You cannot document what you cannot see, and screen photography is routine in this work.

Filtered I/O, not a hole. A USB cable run through an unfiltered pass-through is an antenna delivering outside RF straight into the shielded volume. The filtering is what preserves the isolation while still carrying the data.

Filtered power inside. The device has to stay charged, and the workstation-side hardware often needs mains — but unfiltered power entry is another leak path.

The 1812F is our standard 1812 chassis configured specifically for this workflow rather than for general RF measurement.

Three design elements are worth calling out because they exist for this application specifically.

Hand entry — your choice of two methods. Both of the practical ways to get hands into a shielded enclosure without opening it were developed by JRE Test's founder, and we now offer either one on the 1812F:

• Sleeve entry. Conductive Spandex-style sleeves let the examiner put hands directly into the enclosure with bare-hand tactile feel while the shield stays closed. For placing a phone, seating a Lightning or USB-C connector, and swiping a screen, unimpeded fingertips are hard to beat.
• Legacy shielded glove entry. The original approach — conductive gloves bonded to shielded ports in the enclosure wall. The patent covering this method has since expired into the public domain, and we continue to offer it because a number of labs simply prefer it: gloves keep skin off the exhibit entirely, they suit examiners who already work gloved for contamination or trace-evidence reasons, and some people just like the familiar feel of the older setup.

Neither is a compromise version of the other — they're different ergonomics for different benches. Tell us which way your examiners work and we'll build it that way.

The patented window. Better than 70 dB of shielding with better than 70% light transmission, which means the examiner can watch the screen and photograph it through the window without opening anything.

Interior LED illumination. Roughly 350 lumens of bright white light on a rechargeable Li-Ion battery — battery-powered specifically so the lighting isn't another wire through the wall. Phone screens and connector work both need real light.

The unit also ships with a shielded Faraday evidence bag, which covers the transport half of the chain — seized into the bag, carried to the lab, transferred into the enclosure without the device ever seeing a network.

The isolation numbers are lower than our standard chambers, and that's deliberate. A standard JRE enclosure specs −100 dB at 1 GHz. The 1812F specs −80 dB, because the window and the hand-entry sleeves are apertures, and apertures cost you. As covered above, 70–80 dB is comfortably sufficient to starve a receiver of any usable ambient signal — but if the same box also has to serve double duty for sensitive emissions measurement, that's a different requirement and probably a different configuration.

Watch the top of the band. The 1812F is specified to 6 GHz. Wi-Fi 6E and Wi-Fi 7 operate up to 7.125 GHz, UWB sits around 6.5–8 GHz, and 5G FR2 is far above both. For most phone casework this is academic — the wipe command is going to arrive over cellular or 2.4/5 GHz Wi-Fi. But if your caseload includes newer handsets with 6 GHz Wi-Fi or UWB in play, talk to us about the microwave (MW) upgrade, which extends performance to 28 GHz.

The forensic access story is genuinely cat-and-mouse, and the mice are winning more often than they used to. But every technique in this paper — every one — assumes a device that stays in the state it was seized in. Shielding is the only thing that guarantees that, and unlike the exploit inventory, it doesn't expire when the next OS update ships.

If you're specifying a bench, the questions we'd start with are: what device volume are you handling, do you need more than the filtered USB 2.0 port, and does the same enclosure need to serve any measurement role alongside acquisition?

Related JRE resources:

• How to select and configure an RF Shielded Test Enclosure
• Understanding data signals through filtered I/O connectors
• USB-3 and USB-C special considerations
• Measuring and verifying the shielding isolation
• Using an RF test chamber at 5G and microwave frequencies

This paper describes the operation of forensic extraction tools at a conceptual level only, based on published security research. It contains no operational detail, and JRE Test does not supply extraction tools or services.