Exploits, Tools & Data Recovery · Passcode Bypass & the Unlocking Industry · Lesson 1 of 5

checkm8 Up Close

See what an unpatchable startup bug can and can't do to an older iPhone.

A bug in the very first code

You met checkm8 briefly in iOS Internals. This module looks at it the way an investigator or a security engineer would: what it is, what it can do and, just as important, what it can't.

Every iPhone starts up by running a small program called the Boot ROM (Apple calls it SecureROM). It's built into the chip at the factory, and it's the first link in the chain of trust. It checks that the next piece of startup software really comes from Apple before handing over control. Because it's read-only, nothing can change it later. Normally that's a strength, since malware can't rewrite it either.

In September 2019 a researcher known as axi0mX published checkm8, an exploit for a bug in the Boot ROM of Apple's A5 to A11 chips. That covers iPhones from the 4S to the iPhone 8 and iPhone X, plus some iPads, Apple Watches, iPod touch and Apple TV models. The CERT Coordination Center (CERT/CC), a US vulnerability clearinghouse, tracks it as CVE-2019-8900 and calls it a use-after-free bug. Picture a gym that reassigns a locker but forgets to cancel the old key. Whoever still holds that key can open a locker that now belongs to someone else. In software, a program keeps using a piece of memory after giving it back, and in the worst case that can let an attacker run their own code.

A bug in read-only code can't be fixed by an update. CERT/CC says it knows of no practical fix, and that replacing the device is the only guaranteed protection.

So what does an attacker get? CERT/CC lists firm limits. They need the device in hand, connected to a computer by cable while it starts up in a special recovery mode. Nothing they change survives a restart. And without the passcode or fingerprint, they can't reach data the Secure Enclave protects.

On the simulated phone, tap Restart and check which files are readable before anyone types a passcode. That restarted, locked state is where a checkm8 session begins.

Why it mattered, and why it faded

If checkm8 can't reveal the passcode, why did forensic examiners care so much? The answer depends on the chip.

Apple added the Secure Enclave with the A7 chip in the iPhone 5s. You saw in iOS Internals that it checks passcodes, mixes them with a secret built into the chip, and enforces the growing delays after wrong guesses. Three older iPhones in checkm8's range, the 4S, 5 and 5c, have no Secure Enclave. Forensic vendor Elcomsoft says that on phones like these, a Boot ROM exploit can be used to unlock the device. News coverage in 2019 quoted axi0mX saying checkm8 could have helped investigators with an iPhone 5c like the one in the 2016 San Bernardino case, which you'll study later in this course.

On A7 to A11 phones the picture is very different. Elcomsoft's own documentation says "checkm8 does not affect the Secure Enclave" and can't break the screen lock passcode. Guesses still go through the Secure Enclave, at its pace. What checkm8 gave examiners was a dependable way in that Apple couldn't close:

• On a locked phone after a restart, a limited set of data that isn't protected by the passcode.
• When the passcode was known, for example because the owner shared it, a much fuller extraction.

Apple couldn't patch the Boot ROM, but it could change the Secure Enclave's software. Elcomsoft wrote that a change in iOS 16 blocked its checkm8 extraction on A11 phones (iPhone 8 and X) if a passcode had ever been set. Even an unpatchable bug can be boxed in by the layers around it.

The A12 chip, in the iPhone XS and XR from 2018, shipped with a Boot ROM without this bug, so checkm8 doesn't work on any later iPhone. None of the phones it affects can run current iOS today. The lesson for defenders: a hardware bug only ages out when the hardware does.