Recently I changed my password on my iPhone. I opted for an alphanumeric one for security. However thanks to the likes of FaceId I did not have to re-enter it for a while to the point where I could no longer fully remember it. Eventually FaceId failed me and I was locked out. I tried various combinations of the passphrase that I did remember but to no avail. I searched the internet for an answer but found nothing more than a lot of blogspam articles, a forensic tool designed for governments with a price range in the four digits, and a bunch of shady websites, trying to sell me something.

Frustrated with the lack of useful information I opted for restoring from a backup. However all of this got me thinking:

Thought process:

If I knew where an iPhone stores the number of wrong entries I could use tools like checkra1n to access that particular file and alter it to reset the counter for false entries.

The iPhone cannot store this information with the rest of the user content as that part is encrypted, so it must be stored with information that is available at boot and hence accessible when rooting via checkra1n.

However the lack of public tools implies that accessing the number failed password entries is non-trivial. I could imagine the possibility of storing it in hardware, hence making it impossible to reset via jailbreaking but the existence of tools like GrayKey implies that there is some way to extract information out of the phone that allows you test password entries against it.


So my question is, is the location in which the number of failed passcode entries is stored known or are there at least hints that allow us to (roughly) deduce its location?


The number of failed passcode entries is stored within the Secure Enclave in the hardware. It is not stored as a file or anything like that on the Flash drive.

You cannot easily manipulate it.

  • Thanks for the answer. Makes sense. I suppose the reason tools like GrayKey work is by extracting (part) of the encrypted filesystem and running a bruteforce attack on the extracted data (possibly thanks to previously reverse engineering the used encryption algorithm). This would allow the tools to have "infinite password attempts" without affecting the counter in the Secure Enclave. – Orwits Oct 12 '20 at 15:09
  • It is not necessary to reverse engineer the used encryption algorithm as that is public knowledge. I doubt that it works the way you specify - it doesn't sound likely. The device passcode is entangled wiht the device UID, so you cannot start brute-forcing a device passcode by looking at a part of the encrypted filesystem only. – jksoegaard Oct 12 '20 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .