Most vendor datasheets tell you what a product does. The one Cellebrite circulates for its new Advanced Unlocks service also tells you how far away you can stand while it does it: about eight meters, or 26 feet for customers who think in imperial. Nobody puts a range on a cable. Once I read that line, the rest of the page started to look like a puzzle with a missing piece, and a researcher at justin.sh has spent weeks trying to work out what the piece is.

His post reached me by email, sent by the author himself, which I took as a polite invitation to poke at it. So I did. What follows is a review of the argument rather than a retelling, with my own opinions attached and a clear line between what the post demonstrates and what it merely suggests.

cover

In brief

  • A leaked Cellebrite Advanced Unlocks datasheet quotes a working range of about eight meters, which points to a wireless vector rather than a cable.
  • The coverage stops at the iPhone 16 and iOS 26.4+, leaving the entire iPhone 17 generation and every release since March unsupported.
  • A diff of the bluetoothd binary between iOS 26.4 and 26.5 turned up a use-after-free in the pre-pairing L2CAP path that could become remote code execution.
  • The iPhone 17’s switch to Apple’s own N1 chip does not explain the gap, but Memory Integrity Enforcement (MIE) plausibly does.
  • Apple patched the Bluetooth code silently, with no CVE, while Cellebrite has been unusually specific about range and appliance requirements.
  • If the theory holds, a single point release closed a commercial capability within months, and AFU state becomes fragile evidence that examiners must handle carefully.

What the datasheet promises and what it leaves out

cover

The document is marked CONFIDENTIAL and the author keeps the original under wraps to protect his source, so I am reading it through his screenshots, with the usual caveat that I have not seen the file itself. On the page, Advanced Unlocks (AU from here on) offers AFU access, meaning After First Unlock: the phone has been unlocked at least once since boot, so the data protection keys sit in memory and the Secure Enclave will hand them to the kernel on request. The coverage is iPhone 11 to 16 on iOS 26 through 26.4+, with more models promised later. It reportedly works even with Stolen Device Protection enabled, a feature that, as Elcomsoft explained earlier this year, tightens the USB restrictions forensic tools rely on. Every lab needs one dedicated appliance, online deployments require whitelisting, on-prem ones a dedicated server, and the whole thing is sold next to UFED and Inseyets, not instead of them. The pitch is a vector that is “more resilient to Apple’s OS changes”, which in the current climate is the sentence every mobile examiner most wants to read and least expects to be true.

The interesting part is the revision history. The author compared the three versions of the flyer with the iOS releases available on the day each one was issued. In March the datasheet claimed 26.3+, when 26.3.1 was the newest build. In May it claimed up to 26.4.2, nine days after 26.5 shipped. By the September revision it still said 26.4+, a day after iOS 26.7 and iOS 27 appeared. Read charitably, “26.4+” means “and newer, trust us”. Read the way the author reads it, support stopped at 26.4 and the gap has been widening ever since. The iPhone 17 and Air, on the market for about a year, are missing as well, and the flyer does not say whether the SE and e models fall inside “11 to 16”.

I would not hang a theory on a version string. Datasheets are written by people paid to be vague, and a number that has not been updated may simply mean nobody opened the template. What the pattern does is raise a question, and the post’s value lies in how seriously it tries to answer it.

From eight meters to a Bluetooth daemon

The reasoning starts from the range. The author went through the radios in an iPhone and found that the cellular modem and NFC did not fit, while Bluetooth matched Apple’s own figure of about ten meters rather well. That is an inference, and a good one, but it is worth saying plainly that the datasheet never mentions Bluetooth. Everything below hangs on that first step.

From there he did what researchers do with a suspect: he diffed the patches. He compared the bluetoothd binary in iOS 26.4 and 26.5, the daemon that manages every Bluetooth connection on the phone and holds a broad set of entitlements, and found a small cluster of security changes, all in L2CAP, the multiplexing layer between the radio and everything above it. The relevant detail is that L2CAP signaling messages are processed before pairing, so any device within range can send them without anyone touching the screen.

One fix stands out. In the channel manager, the loop that receives aggregated L2CAP packets walks through the open connections and calls each one’s handler. In 26.4, if a handler freed its connection object halfway through, the loop kept going with a dangling pointer. That is a textbook use-after-free, the kind of memory bug that, with enough skill and patience, becomes code execution. The vulnerable code has been around since at least iOS 17 and probably became easier to exploit when Apple restructured the connection manager in iOS 18. The author is honest that he has not built an exploit, and he separates this bug from a second one in the reassembly path that needs an established channel and is therefore a worse candidate.

Then comes the part that made me raise an eyebrow. iOS 26.6 added bounds checks elsewhere in the Bluetooth stack, and iOS 26.7 and 27 fixed CVE-2026-65414, a separate and uncredited Bluetooth remote code execution bug that lands in the same aggregated-packet path, only earlier. Apple hardened that exact code in 26.5 and was still sitting on a remote code execution flaw in it two releases later.

Put together, the theorized chain goes like this: crafted packets over the air, a hijacked Bluetooth daemon, an escalation to the kernel through one of the many IOKit connections the daemon holds, and finally USB restrictions lifted and the phone imaged over the cable. No passcode is cracked at any point. It is consistent with the Stolen Device Protection claim too, since by the time anyone plugs in a cable the kernel is already compromised.

Here is where I part ways with the post’s enthusiasm. The diff is the solid piece, because anyone with two firmware images and a disassembler can reproduce it, and the bug quite probably exists exactly as described. What cannot be checked is the link between that bug and a commercial product. The chain rests on a range, a stalled version number and a plausible code path, and any pre-authentication parser that received a fix will look plausible to someone who is looking for a candidate. The CVE finding cuts both ways: it shows a target-rich surface, which makes a working exploit believable, and it also means the 26.5 fix was not the only thing standing in the way. The author says as much, and flags the rest of the post as speculation. He deserves credit for that.

Why the iPhone 17 is the best clue

If I had to pick the single most persuasive argument in the post, it is the hardware gap. Starting with the 17 generation, Apple replaced the Broadcom Bluetooth chip with its own N1 in the 17, 17 Pro and Air, but the 17e kept Broadcom. If AU depended on Broadcom components, the 17e should be supported, and it is not. The chip cannot explain the gap.

What does explain every missing phone is Memory Integrity Enforcement, or MIE. Apple introduced it with the iPhone 17 and Air as an always-on defense built on Arm’s tagging extension, covering the kernel and more than seventy userland processes and aimed squarely at mercenary spyware. It targets exactly the family of bugs discussed above, buffer overflows and use-after-free. The author notes that the vulnerable bluetoothd binary is byte-identical on MIE and non-MIE devices at the same iOS build, so the defense, not the code, makes the difference.

His arithmetic is worth repeating. MIE uses four-bit tags, so a blind guess succeeds one time in sixteen, which means about 94 percent of attempts at the memory-corruption step fail. A failure crashes bluetoothd and resets the Bluetooth connection, which in a lab is a nuisance, because an attacker can keep trying for a few minutes until luck turns. The kernel step is a different story. If it also depends on corrupting memory, failure there panics the phone, which reboots into BFU, Before First Unlock, and the keys that made the whole exercise worthwhile are gone from memory.

I find that asymmetry the most interesting part, and it is a forensic problem more than a hacking one. For an examiner, AFU state is the evidence. A method that can destroy it by failing is a method you think twice about, regardless of how good the demo looks. The datasheet’s reassurance about lower risk of lockouts and device damage starts to read differently once you know what the audience is most afraid of.

There is also the March Cellebrite document the author mentions but does not publish. It reportedly credits the 11 to 16 range on iOS 26 and later to AU specifically, while listing the 17 under the general Inseyets capability for things like consent-based extractions. That would suggest the 17 is absent from AU not because Cellebrite cannot touch it, but because this particular method does not work on it. I cannot verify the document, but the inference is neat and it fits.

The author offers the charitable counterargument himself. Cellebrite’s leaked 2024 support matrix listed the iPhone 15 as available only through its flagship service, where a team flies to your office, ten months after launch. Running a generation behind has precedent. Still, he asks why the flyer does not simply say “coming soon”, and having read my share of vendor matrices I know the answer: marketing teams prefer a silent gap to a footnote that commits them to a date. After three revisions in six months, I agree with his assessment that this looks like a hard limit rather than a backlog.

Silence from Cupertino, candor from Petah Tikva

The other half of the story is Apple’s quiet. The 26.5 security bulletin carries no entry for the L2CAP fix. There is a vague acknowledgment about CoreBluetooth, without a CVE, but it sits in the framework layer, not in the daemon, and it was added to the bulletin after publication. Apple sometimes updates bulletins retroactively, or credits nobody when a bug comes from its own engineers. Here it did neither. The author has found no public discussion of any of it, and wonders what else has been fixed without a word.

I would resist the temptation to read intent into that silence. He suggests journalists look into the timing, and I would be curious about the results, but the boring explanations are many: an internal fuzzing find, a cleanup of a bug class, no evidence of exploitation. A quietly patched bug is evidence of a disclosure policy, not a conspiracy. It is, however, a real cost for defenders. A CVE number is how a patch gets priority from a risk committee, and a fix that never earns one gets deployed on the same timetable as a new emoji set.

The roles, as the post points out, have reversed. Apple usually documents its fixes and Cellebrite keeps the specifics for private meetings. This time the vendor publishes a range and an appliance description while Apple stays mute. The author’s explanation is credibility pressure: as the average iPhone gets harder to break, a vague promise to unlock iPhones stops moving anyone. I think that is right, and it fits the pattern I described when Citizen Lab caught Russian authorities using Cellebrite well after the company had cancelled its contracts: this is a business that sells access to a diminishing resource, and its marketing now has to prove the resource still exists.

Ai miei tempi, a bootrom flaw like checkm8 was forever, because you cannot patch silicon that has already shipped. Today the useful bugs come with an expiry date measured in point releases, and the charging port, for years the default door for forensic tools, keeps getting narrower. The post’s closing question is the right one: has the Bluetooth front now closed too, or are things just getting started?

What this changes for the people holding the phones

Right before publishing, the author added a note that Calif had shown something wireless at Hexacon, which he had not yet had the chance to watch. The public record is thinner than that summary. On October 16, in Paris, Calif rebooted an iPhone 18 Pro running iOS 27.0.1 on stage and showed a jailbreak coming back on its own, but it disclosed neither the vulnerabilities nor the initial vector, and published no tool. Whether any of it is wireless is not established. What the demo does establish is that the wall around the newest hardware has, at the very least, a door that somebody found. If a firm like that can do it, Cellebrite’s customers will soon ask when AU gets one too.

For defenders, the story is mostly a lesson in the value of updating. If the author is right, a point release closed a commercial capability within months, and people who stayed on 26.4 remained inside the range of an appliance in someone’s lab. If you face a serious threat model, newer hardware with MIE is a better answer than any setting, and the habits I described in the Lockdown Mode piece still apply, including powering the device off before any situation where seizure is plausible, since a phone that is back in BFU has lost the keys everyone is chasing.

For examiners, the lessons are more practical than glamorous. Record the exact iOS build and the tool version for every acquisition, and do not trust a support matrix as a statement of fact, least of all one that lists a range in meters and a stalled version number. Treat AFU state as the fragile evidence it is. And mind a tension that the post does not spell out: for years we have taught first responders to put seized phones in a shielded bag, and a method that works over the air, if it is what the author thinks, needs the shield open. That raises process questions about warrants, scope and documentation that labs will have to answer before an appliance with a range arrives on the bench.

Whether or not AU is what the author believes, the post leaves the right problem on the table. The cables are closing, so the next fight will happen wherever a phone listens without asking, in Bluetooth, in ultra-wideband, in the baseband, even in the SIM, which as I showed in the piece on hostile SIM commands can order a phone around more than anyone budgeted for. The phone in your pocket is a very polite device. It answers whoever speaks first.

FAQ

What is Cellebrite Advanced Unlocks?

A service that unlocks iPhones already in an AFU state, advertised as working from roughly eight meters away, without cracking the passcode or the device encryption.

Why does the datasheet stop at iOS 26.4 and skip the iPhone 17?

A researcher argues that Apple’s Memory Integrity Enforcement, introduced with the iPhone 17, defeats the memory-corruption bugs the method relies on, explaining both the missing hardware and the stalled version number.

Does Advanced Unlocks work over Bluetooth?

The datasheet never names Bluetooth, but the eight-meter range fits it better than any other radio, and a diff of the Bluetooth daemon found a use-after-free in the L2CAP path patched in iOS 26.5; the link to the product remains unproven speculation.