Hacker News new | past | comments | ask | show | jobs | submit login

You are wrong. Apple cracked the other phones by installing software that brute-forced the password. They didn't have someone sit there and punch in 10,000 codes like a monkey.

Moreover, Apple won't comply with valid warrants for phones running iOS7, so it doesn't really have anything to do with the security of the OS. This started only because a federal judge made an issue of the legal justification for the first time ever:

http://arstechnica.com/tech-policy/2015/10/feds-since-apple-...




How do you know that's how they cracked the other phones? I would have expected that it would have involved taking advantage of some existing security vulnerability. The jailbreakers already have it nicely packaged up, even.


Again, do you have any evidence whatsoever for your claim that a piece of brute-forcing software written by Apple already exists?


How about the fact that these tools have existed in the public domain for every version prior to iOS8, plus the fact that Apple could do this in Apple stores for customers, plus basic common sense?

http://www.ibtimes.co.uk/translock-utility-ios-can-brute-for...

But OK, if you insist...here's "evidence" straight from the EFF:

"For older phones with no encryption, Apple already had a software version to bypass the unlock screen (used, for example, in Apple stores to unlock phones when customers had forgotten their passcode)."

https://www.eff.org/deeplinks/2016/02/technical-perspective-...

And before you go there: whether or not you call this "brute forcing" is, again, a distinction without a difference. The FBI wants access to a single, password-protected phone, under warrant, and Apple has historically maintained custom software that helped them comply with these exact requests. Nobody knowledgable about this case cares that the software has to iterate through 10,000 numbers, or uses some other method to gain entry. They just want the outcome.


Your first link requires an already-compromised boot path; it cannot be used on the San Bernardino phone. Your second link describes software that only works on unencrypted devices, which likely means it needs to be able to grab the password hash directly (which it's free to then brute-force off-device, avoiding the max-attempts erasure).

Whether Apple has previously signed a piece of PIN unlock software or not completely misses the point: they decided to do that. They were not compelled. They expressed trust in the software because they trusted it. Not because they were forced to. Compelled speech is constitutionally prohibited.

Maybe give CVE-2014-4451 a try?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: