Replies

Of course, there's the other problem, Apple doesn't ever store the passcode anywhere on the iPhone, only a one-way HASH representing that passcode with which a newly input and re-calculated HASH will be compared every time a user inputs his passcode to open his or her iPhone, so there IS NO STORED PASSCODE to locate.

I have cracked protected software of that kind many times. Namely, no matter what gets compared to what, there is a decision point in the code where the code takes different branch based on the result of comparison. To crack it, one forces the code in the debugger to take the "good" branch.

Of course, this can be tedious process, taking hours or days, since protection code will seek to obscure what it is doing. But that is always a finite number of steps before the action (go or no go) has to carried out. The hardware assisted debugger is useful to be able to block any writes back to non-volatile memory (done in the drivers) so each iteration can be restarted in the same initial state of the program. That includes resetting manually the stored nano-second clock counters the keeps in some variable.

The process requires in depth knowledge of OS. It is also helpful if the hacker has written protection software before so he has a good intuition about the thinking process behind the protections.

When I was developing Cyber Sentry protection library in late 1990s (for TLC/Mattel), the managers and the clients would always get upset by the disclaimer in the contract that their precious content can't truly be protected and the best that can be done is to make it tedious for the hacker to crack it.

I wrote similar code a decade later for anti-piracy protection of the iPhone apps. In that variant, since apps are cracked to let user run them many times, I would create an outer layer of false protection that was fairly easy to crack. After cracking that one, user could play with the seemingly unlocked app for couple weeks or certain count of runs. But then the real protection would kick in and start injecting series of increasingly more disabling flaws in the functionality (unfolding eventually into full crashes).

Namely, no matter what gets compared to what, there is a decision point in the code where the code takes different branch based on the result of comparison. To crack it, one forces the code in the debugger to take the "good" branch.

You will only have OS code running in a debugger:

Apple supports OS debugging which is why they move the branch you are talking about into the SoC. What you can't do is step through the passcode hashing, hash comparison and key unlocking in the SoC.

That still won't work to decrypt the iPhone, nightnight. The passcode is integral to the encryption/decryption process. The passcode is part of the four pieces of the entangled encryption key that will be built to decipher the data on the Flash drive. Without it, the data cannot be unencrypted and the iPhone cannot be unlocked. It is not just a matter of taking a different fork in the road.