[mem0r1]

To my knowledge there is no technical reason why a hashed value of the passcode should be stored on the iPhone in any way. If a hashed value could be extracted from the device, there would be no reason to perform the brute forcing procedure on the device itself, which seem to be the case with GrayKey.

[web007]

How do you validate the passcode if you're not storing it or a hashed version of it on the device?

[mem0r1]

For example if you encrypt your disk or a file using a password, you also do not store a hash, the decryption/encryption key is derived from your password using a key derivation function such as https://en.wikipedia.org/wiki/Scrypt

[mem0r1]

https://support.apple.com/guide/security/secure-enclave-over...

[nostalgk]

My speculation is that it maybe tries to crack the hashed value and input that to the phone instead, rather than interfacing with the password screen.

in other words: the encryption/wipe code may be a function of the password screen, but the phone may accept a hashed key as a valid unlock attempt through a different interface that does not contribute to the failed attempts limit.

[mem0r1]

Of course it is highly unlikely that it interfaces with the password screen. My point is that if you could extract a hash from the secure enclave it would make much more sense to brute force it on a powerful external cluster. However this seems not to be possible as the decryption is only possible inside the secure enclave element unique to the device, thus decryption attempts have to be done on the the device itself, GrayKey seems to have managed to circumvent the wrong attempts counter and/or the triggering of subsequent protection mechanisms.