What a Locked iPhone Still Gives Up

SCIENCE & TECHNOLOGY · SEPTEMBER 13, 2026

The video below went around on X this week, posted by the account Bitcoin News, captioned "everything law enforcement can see when they get physical access to your phone — better not be keeping a seed phrase on there." The clip itself is a re-post: it's watermarked throughout with an Instagram handle, @khanjicyber, which appears to be the actual creator, part one of a two-part series. Having now watched the whole thing frame by frame, I can say plainly what it shows: a demonstration of two named, real forensic tools — Magnet Forensics' AXIOM (the "License: Axiom Essentials (Dongle)" watermark and the "Integrate with Magnet One" case screen are both visible on screen) run against an unlocked Google Pixel 6, and iLEAPP, a free, open-source parser, run against an iPhone's iTunes backup. Both are named further down, with what they actually surfaced.

Everything law enforcement can see when they get physical access to your phone.

Better not be keeping a seed phrase on there. pic.twitter.com/0f2CXQSqv5

— Bitcoin News (@BitcoinNewsCom) September 12, 2026

What's actually on screen

The first tool is Magnet AXIOM, a commercial forensic suite in the same category as Cellebrite's better-known UFED and Physical Analyzer.^[1] Before any device is touched, the case-setup screen's "Case type" dropdown is worth pausing on: the options scrolled past on screen include Major Crimes, Border Security, Child Exploitation and Counter-Terrorism, but also Civil Case or Investigation, Data Exfiltration/IP Theft, Fraud, HR/ Internal Investigation, Policy Violation, Probation/Parole Violation and Wrongful Termination — categories with nothing to do with law enforcement at all. The imaging step against the Pixel 6 lists "Confirm the device is unlocked" as a required step before "Running ADB backup" — the demonstration is an AFU extraction, exactly the category described above, not some novel way around the passcode. Once the image finishes, AXIOM's results are organized into a category tree, and two of its labelled branches are Passwords and Tokens (3 matches) and User Accounts (4 matches) — named, counted categories, sitting in the same list as Communication, Media, Documents and Location & Travel. The video doesn't open that category to show what the three items actually are, so I can't tell you whether they're Wi-Fi keys, saved site logins or something else — but the category existing, with matches in it, is no longer something I'm inferring from vendor literature. It's on screen.

The second half of the video switches to iLEAPP — iOS Logs, Events, and Properties Parser — run against what its own output labels an iTunes_Backup of an iPhone. iLEAPP is free and its source code is public.^[2] No dongle, no license, no vetted customer list: anyone who can get hold of an iPhone's backup file can run it. What comes out, in this demonstration: a Bluetooth-LE report listing 43 nearby devices the phone had logged; a Safari Tabs report recovering closed and private tabs, not just open ones; a Safari search-terms history; calendar entries; recovered "trashed" (deleted) photos, including their Live Photo component; and — the one worth dwelling on — a Notes entry, synced via iCloud, titled Passwords, with the snippet and full content both showing a plaintext password in the clear. iOS Notes carries no keychain protection at all; a note is a note, and it came back whole.

What "unlocking a phone" actually means in 2026

The device state that matters is not locked-versus-unlocked, it's Before First Unlock versus After First Unlock — BFU and AFU in the forensics literature. A rebooted iPhone that has never had its passcode entered since power-on is in BFU: the hardware keys for most protected data classes haven't been derived yet, and most user content is unreadable to any tool, forensic or otherwise. The moment the passcode is entered — by the owner, or by a tool that has found a way to guess or bypass it — the device moves to AFU, keys are derived, and the running operating system can read most of what's on it. Practically every publicized extraction, including both tools in the video above, is an AFU extraction: a full copy of the file system taken from a device that has, one way or another, already been unlocked. True bit-for-bit physical extraction — reading the raw flash independent of the operating system's cooperation — is reported not to be achievable on current iPhone hardware at all; the file system copy is the practical ceiling.^[3]

A short history of who has had this, starting with a case everyone remembers wrong

The 2016 standoff between Apple and the FBI over the San Bernardino shooter's iPhone is the origin story most people know part of: Apple refused to build a backdoor, the FBI said it didn't need one because it had found another way in, and paid for that way. FBI Director James Comey later said, without naming a figure, that the bureau had spent more than he'd earn in the seven years and four months left on his own term — arithmetic that puts it comfortably over a million dollars.^[4] For five years the assumption, reported as fact in plenty of places, was that Cellebrite had done the unlocking. A 2021 Washington Post investigation established that this was wrong: the actual work was done by Azimuth Security, a small, publicity-shy Australian firm whose founder had found a flaw in code Apple used to handle Lightning-port accessories, which two colleagues then chained into full control of the phone's processor and, from there, a program that tried every passcode without triggering the data-wipe-after-ten-tries protection.^[5] Azimuth described its own customer base as "democratic governments" — which is a policy, not a law, and policies are set by whoever owns the company.

The next turn in the story cuts the other way. In April 2021, Signal's Moxie Marlinspike published a technical teardown of Cellebrite's own UFED and Physical Analyzer software — the company whose name had wrongly become synonymous with the San Bernardino unlock — and found it riddled with the kind of bugs a security-focused company shouldn't have: unpatched years-old code libraries, missing standard exploit protections, enough holes that a maliciously crafted file placed on a phone being scanned could reportedly run arbitrary code on the Windows machine doing the scanning.^[6] The company built to break into other people's devices had, by outside account, done a mediocre job securing its own — the exact shape of the concern behind "assume more than law enforcement can get hold of this": a tool doesn't stay inside the fence of whoever it was sold to.

Apple's side of this has been a series of specific, dated responses, not one fix: USB Restricted Mode in 2018, which locks the Lightning/USB-C data pins after an hour unless the passcode has been entered since; Lockdown Mode in 2022, an opt-in mode that drastically narrows what a device will process from the outside world, aimed explicitly at people who think they're an individually targeted risk; and, in December 2022, Advanced Data Protection, which is the piece most relevant to the ADP question I was asked directly this week, so it gets its own section below. In 2024, iOS added Stolen Device Protection, which requires biometric confirmation and a time delay for sensitive changes — like viewing saved passwords or turning off Find My — when the phone is away from a location it recognizes as familiar.

What Advanced Data Protection actually covers

Advanced Data Protection is Apple's own name for end-to-end encrypting most iCloud data — device backups, Photos, Notes, and more — so that the decryption keys exist only on a user's own trusted devices, not on Apple's servers. Apple's announcement is explicit about the boundary this draws: turning it on means that even Apple cannot read that data, and so Apple has nothing to turn over in response to a legal demand for it.^[7] That is a real and separate protection, and it's a cloud-side one. The BFU/AFU distinction above is a device-side one. A tool that has already gotten a phone into AFU state and copied its file system never asked Apple's servers for anything — it read data the device itself had already decrypted to function — so Advanced Data Protection's guarantee and a physical-extraction tool's target are two different layers of the same phone, and turning on one doesn't touch the other. Apple's own security documentation keeps that boundary explicit for exactly this reason: it's the layer where a legal-process question and a stolen-or-seized-device question stop being the same question.

What actually helps against the thing this video is about

Advanced Data Protection answers a legal-process question. A physical-possession question — the one this video is actually about — has a different, shorter list of answers, and Apple has shipped real pieces of it. This is the "other thing" worth turning on, alongside ADP rather than instead of it.

Lockdown Mode (Settings → Privacy & Security → Lockdown Mode) is Apple's own opt-in answer to exactly this threat class: it drastically narrows what the device will process from outside sources, which is where exploit chains like the one Azimuth built typically get their first foothold. It shipped in 2022 for journalists, dissidents and executives who consider themselves individually targeted, but the switch doesn't check anyone's job title.

A long alphanumeric passcode (Settings → Face ID & Passcode → Change Passcode → Custom Alphanumeric Code) replaces the six-digit PIN most people leave in place by default. Nearly every publicized extraction still depends, at some stage, on brute-forcing the passcode once an exploit chain has gotten a tool past the ten-tries data wipe — a six-digit PIN is a million combinations to grind through; a real passcode is enough that the exploit chain goes stale before it finishes.

Stolen Device Protection — on by default since iOS 17.3, visible at Settings → Face ID & Passcode — adds a Face ID check and a one-hour delay before anything security-sensitive changes (viewing a saved password, turning off Find My, adding a new face to Face ID) when the phone is away from a location it recognizes as familiar. It's built for a stolen, already-unlocked phone in someone else's hands, a different scenario from a seized phone in a lab, but it's real and it's already on.

And the one that costs nothing: reboot the phone before any encounter where it might leave your hands — a border crossing, a stop, a repair counter. A phone that's been off comes back in BFU, which is the state that blunts every method described above.

The example that shows the ceiling is higher than "unlock the phone"

A case that surfaced this April is a cleaner illustration than any hypothetical. In a Texas prosecution over a July 2025 incident at an ICE detention facility in Alvarado, the FBI recovered incoming Signal messages from a defendant's iPhone — despite the Signal app having been deleted and the messages themselves set to disappear. Only incoming messages came back, not outgoing ones, and the reason given is mundane rather than dramatic: iOS caches the content of push notifications in a system-level database so it can show a lock-screen preview, and that cache persists independently of the app that generated it.^[8] Nobody broke Signal's encryption. The message had already been decrypted, on-device, to render a notification, and the operating system kept a copy of that for reasons that have nothing to do with forensics. It's a good instance of the general rule: "I deleted the app" and "the data is gone" are not the same claim, and the gap between them is usually an OS-level convenience feature, not a defeated cipher.

Where this lands for a Bitcoin key specifically

None of the above is really about phones-in-general so much as it's about what a phone is: a networked, general-purpose computer that a company you don't work for keeps updating, and that is built, on purpose, to keep working after you've unlocked it once. That's a fine trade for almost everything people use a phone for. It's a bad fit for a Bitcoin private key or seed phrase.

Which raises a natural next question: can a tool like this read Apple's own Passwords app — the thing that holds your actual saved passwords, and where some people, against every piece of guidance from every hardware-wallet maker, keep a seed phrase typed in as a password note. The video doesn't show that specific app being opened, so I can't point to it on screen. What it shows instead answers the broader question just as directly: AXIOM's own results tree, run against the Pixel 6, labels a category Passwords and Tokens with matches in it — three, in this case — sitting next to User Accounts with four more. And on the iPhone side, iLEAPP pulled an iCloud-synced Notes entry, titled outright Passwords, with a plaintext password sitting in both the list snippet and the full note body. Neither of those is the Passwords app specifically, and I can't tell you whether a true Keychain-backed, biometric-gated entry would have come out the same way — independent research on iOS Keychain extraction says items with a biometric access-control flag resist this, because unwrapping them needs a live round-trip through the Secure Enclave at read time, not just an unlocked device.^[9] What the video removes is the need to guess at whether "passwords" as a category survives this kind of extraction in general. It does. What's still open is only the narrower, more technical question of which specific storage mechanism a given password sits in.

What that uncertainty argues for isn't "hope it's the protected category" — it's the same answer either way. A seed phrase shouldn't exist as an entry in any app on a general-purpose phone, Passwords app included, regardless of how that app protects it. That's the entire reason hardware signers — devices whose only job is holding key material somewhere that never runs a general-purpose OS and never has anyone else's forensic tooling as an intended user — exist as separate hardware rather than a feature inside a wallet app. A hardware signer has no BFU/AFU distinction to worry about, because the key material was never on a device unlocked by anything but the physical button on the signer itself. That's the property this entire class of attack is built around not having, and it's the one place in this entry I'm not hedging: don't keep it on the phone.

Sources

1. Magnet Forensics. Magnet AXIOM — the product visible on screen in the video above ("License: Axiom Essentials (Dongle)," "Integrate with Magnet One"). magnetforensics.com
2. Alexis Brignoni (abrignoni). iLEAPP — iOS Logs, Events, And Properties Parser. Free, open-source; the tool run against the iTunes backup in the second half of the video. github.com/abrignoni/iLEAPP
3. Elite Digital Forensics. iOS Forensics (2026) — on Before/After First Unlock device states and the current ceiling on iPhone extraction. elitedigitalforensics.com
4. CBS News. FBI paid more than $1 million for San Bernardino iPhone "hack," James Comey confirms. 2016. cbsnews.com
5. The Washington Post. The FBI wanted to unlock the San Bernardino shooter's iPhone. It turned to a little-known Australian firm. 14 April 2021. washingtonpost.com
6. Signal. Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer from an app's perspective. 21 April 2021. signal.org
7. Apple. Apple advances user security with powerful new data protections. 7 December 2022. apple.com
8. Security Affairs. iPhone forensics expose Signal messages after app removal in U.S. case. 13 April 2026. securityaffairs.com
9. ElcomSoft. Extracting and Decrypting iOS Keychain: Physical, Logical and Cloud Options Explored. August 2020. blog.elcomsoft.com
10. @khanjicyber on Instagram. The original video — watermarked throughout, part one of a two-part series. Re-posted (uncredited) by @BitcoinNewsCom on X, embedded above. x.com/BitcoinNewsCom/status/2098825343721230464