Replies

iOS versions 8.0, 8.0.1, 8.0.2, and 8.1 the failed passcode attempt limit was not always enforced. This was corrected in version 8.1.1

Not quite true. I posted this problem back in 2014. It is very obscure and the security firms report ZERO break ins. You DO NOT get rapid multiple tries, just apparently unlimited manual passcode tries which take about two minutes per try.

But the KICKER is you have to do a FORCED COLD RESTART of the iPhone between every passcode attempt, and you have to catch it exactly timed right. If you don't the timer counts the attempt. OOPS! It is not a cure all method and of course you have to get put it on an iPhone that's never had the problem fixed. The issue did not have anything to do with the timer being re-written, but with reset software, outside of the control of the startup routines. That was what was fixed.

Here're the details of this bug including a YouTube of what the discoverer of this vulnerability and exploit, Stuart Ryan, demonstrating it and what he has to say about it:

Bypassing the lockout delay on iOS devices — by David Schuetz —November 18, 2014

Apple released iOS 8.1.1 yesterday, and with it, a small flurry of bugs were patched (including, predictably, most (all?) of the bugs used in the Pangu jailbreak). One bug fix in particular caught my eye:
Lock Screen
Available for:  iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later
Impact:  An attacker in possession of a device may exceed the maximum number of failed passcode attempts
Description:  In some circumstances, the failed passcode attempt limit was not enforced. This issue was addressed through additional enforcement of this limit.
CVE-ID
CVE-2014-4451 : Stuart Ryan of University of Technology, Sydney
We’ve seen lock screen “bypasses” before (that somehow kill some of the screen locking application and allow access to some data, even while the phone is locked). But this is the first time I’ve seen anything that could claim to bypass the passcode entry timeout or avoid incrementing the failed attempt count. What exactly was this doing? I reached out to the bug reporter on Twitter (@StuartCRyan), and he assured me that a video would come out shortly.
Well, the video was just released on YouTube, and it’s pretty interesting. Briefly:

Lock the iPhone.
Enter a bad passcode several times, until you have a “disabled for 1 minute” warning.
Wait a minute, and enter one more bad passcode. Now you should have to wait 5 minutes to try again.
As soon as the “iPhone is Disabled” message appears, hold down the power and home buttons until the phone reboots.
Once you see the Apple logo, release the power button, but keep holding Home.
After four seconds, release Home as well, and the phone should continue rebooting.
Once it’s rebooted, go back to the passcode screen and you’ll see that it’s enabled and there’s no entry lockout delay.

This doesn’t appear to reset the attempt count to zero, but it keeps you from waiting between attempts (which can be up to a 60 minute lockout). It also doesn’t appear to increment the failure count, either, which means that if you’re currently at a 15 minute delay, the device will never go beyond that, and never trigger an automatic memory wipe.
Combining this with something like iSEC Partners’ R2B2 Button Basher could easily yield something that could just carefully hammer away at PINs 24x7 until a hit is found (though it’d be SLOW, like 1-2 minutes per attempt….)
Why this even works, I’m not sure. I had presumed that a flag is set somewhere, indicating how long a timeout is required before the next unlock attempt is permitted, which even persists through reboots (under normal conditions). One would think that this flag would be set immediately after the last failed attempt, but apparently there’s enough of a delay that, working at human timescales, you can reboot the phone and prevent the timeout from being written.
Presumably, the timeout and incorrect attempt count is now being updated as close to the passcode rejection as possible, blocking this demonstrated bug.
I may try some other devices in the house later, to see how far back I can repeat the bug. So far, I’ve personally verified it on an iPhone 5S running 8.1.0, and an iPad 2 on 7.0.3. Update: I was not able to make this work on an iPod Touch 4th generation, with iOS 6.1.6, but it’s possible this was just an issue with hitting the buttons just right (many times it seemed to take a screenshot rather than starting up the reboot). On the other hand, the same iOS version (6.1.6) did work on an iPhone 3GS, though again, it took a few tries to make it work.

By the way, here's a YouTube of a DFU restart without a passcode