Posted on 03/02/2016 11:57:21 PM PST by Swordmaker
John McAfee, the anti-virus program pioneer and gadfly U.S. presidential candidate, claimed that unlocking the Apple iPhone of Syed Farook, one of the shooters who carried out a deadly attack in San Bernardino, California, late last year, is a “trivial” exercise and explained how it should take the FBI just 30 minutes to complete it.
McAfee, who is among 12 candidates vying for the Libertarian Party nomination to run for president this year, spoke to Russia Today about the continuing debate over the FBI’s attempt to force Apple Inc. to unlock the iPhone 5C used by the terrorist by creating a specific version of iOS to bypass security. The federal agency and the company will appear before Congress to debate the issue Tuesday.
However, McAfee indicated he believes unlocking the iPhone is a “trivial” matter and that the FBI knows this, adding that if it doesn’t, then “we are in deep trouble.” And he said that if the FBI is indeed aware of how trivial it is to unlock the iPhone, then it is deceiving the public by “asking for a universal key” to access Apple’s smartphones.
According to McAfee, this is how the FBI could unlock Farook’s iPhone.
“You need a hardware engineer and a software engineer. The hardware engineer takes the phone apart, and copies the instruction set [the phone’s mobile operating system and installed applications] and the memory. You then run a program called a disassembler, which takes the 1s and 0s and gives you readable instructions,” McAfee said.
“Then the [software engineer] sits down and reads through it. What he is looking for is the first access to the keypad, because that is the first thing you do when you input your [personal identification number]. When he sees that, he reads the instructions for where in memory the secret code is stored.”
McAfee previously wrote he would be able to decrypt the San Bernardino iPhone free of charge so that Apple wouldn’t have to put a backdoor into one of its products. At the time, he said it would take three weeks, but he has now suggested he offered that time frame just as a precaution so he basically wouldn’t have to eat his words later.
The trivial nature of unlocking an iPhone does not serve as an indictment of Apple, McAfee said, as “any computer can be [cracked], and it is a half hour job.”
Lol.. Finally.. Could somebody please tell trumps makeup entourage that? His overly white eye are is too painful to watch. There.. I appreciate you speaking up.. I thought I was all alone in this kind of thinking.
McAffe is a McAss, and uncompiling code does not allow you to easily "read" the program, not like having the original source code does.
But of course the iPhone stores the passcode on the iPhone. If it didn't you couldn't unlock your phone while it was in "airplane" mode where the wifi and cellular data transmitters are turned off. But it is stored as an encrypted number, and cannot be decrypted without knowing the original number.
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).
I won't nit-pick with "reverse the hash", but effectively you are right. If you know the algorithm (generally published quite publicly, and for very good reason) and the hash, you can figure out the password that needs to be entered to match the hash though a "dictionary attack". Programs such as "cracklib" have been available for decades to do this, however this type of attack has become much less useful in the last 15-20 years (I hate being able to say such things, I'm NOT THAT OLD!) as we have stopped making the hash values so publicly available.
Swordmaker posted some very useful information on the internals of APPL's implementation here, last night
To be fair, this is not what Apple is fighting. Apple is fighting the creation of an OS that turns off the "ten tries then brick" option while the phone is still locked. The FBI also wants this new OS to also eliminate the wait period between three failed tries.
The FBI will then take this dumbed-down phone and just start at 0000 and work their way up until the phone unlocks. No need to reverse engineer the HASH.
Since I do not understand anything beyond “you need a hardware engineer and a software engineer, “ my reply to McAfee is either do it or get off the pot. Quit talking about it. Get a 5c with iOS 9 on it, have someone lock it and show the world how smart he is [or not].
“It may be possible to read the device’s memory using electron microscopy techniques and import it into a virtual machine”
Explain this a bit more if you can.
Tanning booth eyes are distracting, aren’t they? :)
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.
Most secure systems do not store passwords anyway. They only store one way hash values of passwords. There is no way to recover passwords from anything stored in the file system.
My understanding is that the FBI is not asking Apple to decrypt the phone. The FBI is asking Apple to produce a version of iOS that does not lock out or wipe the phone when an invalid passcode is used more than 10 times. Then they want to try to guess the passcode using brute force methods.
This is the coding equivalent to commenting out an "if" statement, to oversimplify it.
On CSI Cyber, Criminal Minds and Blindspot the FBI hack into anything they want. What’s the problem. Even McGeek on NCIS could do the job.
Since such a team would be billionaires after successfully completing such an exploit, money is not the issue here. McAfee has declared he would fund the venture himself. These codeheads (said with all due respect and affection for the codeheads here at FR...) would do it just for the status and notoriety.
So, the question I pose is, why doesn't John obtain a same model/build iPhone from someone who has used it for a few weeks in the same geographic area and set out to crack it for the world to see?
Wouldn't this "proof of concept" be enough to convince the tech world that it can/could be done? Assuming, of course, they could be successful at this...
Don't laugh -- you're next!
Are Technica rips John McAfee a new one. . .
Apple did not give the Chinese government any access to the iPhone. All that Apple did was prove to the Chinese government that the iOS devices had NO BACKDOORS that were being used by the NSA to spy on Chinese citizens and more importantly Chinese government employees. That was what the "security audit" was all about. China also required that any Server keeping Chinese citizen's data had to be within Chinese borders. That was the limits of Apple's "sacrificing" any "principles."
No, storing a HASH is not anything similar to storing the actual passcode. You can even store a HASH where it could be downloaded and worked with, it still won't get you into the iPhone because you cannot derive the original passcode from any manipulation of that HASH as it is purely a one-way result.
He can't be taken seriously.
Seems reasonable. First removed the flash and read the AES-encrypted content (easy). Second examine the SoC (probably destroying it in the process) and get the passcode hash. If you can get the hash (maybe hard) you can get the passcode (easy). Third, get the UID that is burned into the HW. You need that and the passcode hash to get the AES key. That might be hard or impossible. There are probably tricks to scanning for a hardware code, but those tricks will be part of an arms race to keep it trick-proof.
Exactly how I feel about a man who goes down on other men.
Just sayin'.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.