Discuss.
linky
https://www.youtube.com/watch?v=MG0bAaK7p9s
can /g/ do it?
>>53377013
http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/
I can't speak for iOS, but on Android your pin sits hashed in a database file, so if you don't have encryption turned on it takes under a second to pull that hash and bruteforce it (only 10,000 possible combinations for a 4-digit pin).
>>53377532
>http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/
Android is MORE secure because it has that "draw the picture" password.
iPhone only has the 4 digit pin.
Even if you didn't know the encryption, you could get the hashes from like 50 iPhones and do a rainbow table attack, which could get you the password in under 2 days TOTAL.
> Caring what a meth-addled murderer has to say.
>>53377567
McAfee has snorted more computer science than you'll ever know NEET
>>53377474
>arstechnica
>strawman cartoon
wew laddie quality post
>>53377577
It's right though.
Every phone after the 5s has a secure enclave in it. Even the phone doesn't know it's private key (that the passcode will be encrypted with)
>>53377564
Once again speaking only from experience with Android, I'm sure the hashes in iOS are salted like they are in Android to prevent rainbow table. The limitation is that the input is just so low entropy.
>>53377013
>buy enough iphones to try all the combinations
>put a carbon copy of the phone on each of them
>try all the combinations
Would this be possible?
>>53377752
If you could make carbon copies of the phone, then you wouldn't have to worry about the wiping mechanism.
>>53377061
/g/ had a bait post yesterday where it got trolled down with Jamal replies and to ask McAfee and Snowden. No doubt the FBI was asking /g/ on how to hack a locked iPhone.
>>53377013
>(insert random topic)
>"Discuss!"
That's not how it works, OP. You provide something insightful or at least slightly informative, and then we comment on that. We can't very well make your thread for you.
>>53377802
How do you protect the equivalent of the hard drive on an iphone?
Can't you just unplug it from any kind of power source so that the mechanism triggering the delete everything mechanism won't trigger?
Genuinely curious
why not just swap the on board memory from the terrorists iphone into a new iphone, then boot?
>>53377879
You need a power source to read the storage. The same firmware which contains the code to read the storage also contains the code to wipe everything. If you want to change the firmware, you need the vendor's help. If you want to rip the storage out and put it in another phone, you need a lot of time and expertise.
why do people still give this hack attention
>>53378015
Because he's dank.
>>53378008
I see, but what stops the FBI from copy-pasting the storage, even when encrypted and with the original firmware and putting it in another phone?
Is this firmware advanced enough to know when something is set to read the entire drive and trigger?
>>53378015
He's a cool guy to talk to
>>53378015
Bitches and Blow
Mcaffee 2016 baby
>>53377564
And the new default 6 number pin
And an alphanumeric password
>iPhone only has the 4 digit pin.
bullshit and that's not even the default when you have TouchID since years ago.
'iOS supports six-digit, four-digit, and arbitrary-length alphanumeric passcodes.'
>Even if you didn't know the encryption, you could get the hashes from like 50 iPhones and do a rainbow table attack, which could get you the password in under 2 days TOTAL.
your math is way off.
on Android <= 4.3 for a GPU of a mobile computer (NVIDIA GeForce 730M), hashcat can achieve more than 20,000 PBKDF2 hashes per second, and recovering a 6 digit PIN takes less than 10 seconds. On the same hardware, a 6-letter (lowercase only) password takes about 4 hours.
anyway that won't work on an iPhone because you will never get those hashes, because it's encrypted.
>>53377879
all iphones are encrypted, if you send the wipe command it just changes the keys, so it's instant.
additionally flash doesn't work like hard disks, the controller is integrated and once the controller gets the format command that's the command it will be executing. write-blockers for flash are hard to do.
>>53377817
Yesterday? Don't you mean every day every couple hours for as long as this ebin may may has been around?
>>53377013
I keep my passwords in a plaintext file, heck I'm pretty sure an important password is in my copy/paste cache right now
>>53378067
Only time and resources. I suspect that they expected asking Apple directly to be the path of least resistance, but that turned out to not be the case.
>>53377013
He will have fun eating that shoe, he promised to eat if he can't crack that iPhone
I make all my PINs 9999, it's the least vulnerable in the event of a brute force attack
>>53378371
dumbshit
>>53377564
You can find the picture password by looking at the smudges on the screen. Implying you handle it with care.
>>53378371
That's why when I brute-force iPhones, I start from other side
Can't FBI do something with "System update/upgrade"?
>>53378458
Only if the update is signed by Apple.
>>53378491
and signature is somekind hash or something, correct?
>>53378505
Yes. So either Apple has to sign it or you'd have to replace the public key the phone is using to verify that signature, which depending on the hardware is varying degrees of difficult.
>>53378527
It seems like Apple considered everything
>>53378541
>The reality is that Apple already has unfettered access to this device: they left themselves a backdoor to which only they have the key, in the form of a "secure" update mechanism that is so "secure" that even the user can't control it, only Apple can. To me the actual question here is whether the FBI should be allowed to ask and then force Apple to use the backdoor Apple built into their product; Apple painting this as if they are being asked to build a backdoor instead of use an existing one is them being nothing more than dishonest in an attempt to twist the story and shift the blame. So yes: I think it is fair to describe the security of this device, from the perspective of Apple, as nothing more than a ribbon, as Apple already has "unfettered access to [your] data". Apple trusts users so little that they don't give users control of the hardware they own... this is frankly a good lesson on them that this is responsibility they should never have hoarded. "Here's hoping that the iPhone 7 no longer has a backdoor that is controlled by Apple."
>>53378541
Say what you want about apple, but it's not like they can promote their phones as "high quality" just because they look good.
They have to back their facts up with actually high quality features, encryption being one of them.
Then there's the
goto fail
goto fail
thing
>>53378541
Depending on perspective. Many on /g/ will argue that Apple having the ability in the first place to update your phone without your explicit approval is a backdoor in itself (which I agree with).
>>53377013
I don't know how Apple's custom ARM chips are designed, but McAfee is making a lot of assumptions about the internal hardware AND software design.
Apple could easily have licensed the ARM core, made alteration to give it a special walled-off, on-CPU key/PIN storage and decryption engine, and McAfee would be out of luck even if he could hijack the DRAM interface and make a complete RAM copy.
At that point you can still maybe theoretically steal shit out of on-CPU SRAM, but you're doing shit like inducing soft faults in transistor with special coded light pulses through microscopes, etc., which is something that MAYBE other three letter agencies can do on a case-by-case basis when they don't already have the hardware backdoored.
This guy is literally "I was merely pretending to be retarded".
So pretty much our /g/uy.
>>53378595
>They have to back their facts up with actually high quality features, encryption being one of them.
they do not. secure enclave is a black box.
trust without control is very poor opsec.
>Apple could easily have licensed the ARM core, made alteration to give it a special walled-off, on-CPU key/PIN storage and decryption engine, and McAfee would be out of luck even if he could hijack the DRAM interface and make a complete RAM copy.
that would mean breaking the ARM license. secure enclave is an implementation of ARM's trustzone. don't let the Apple branding confuse you.
>>53378613
Confucius say man with open backdoor vulnerability something something faggot.
>>53378458
That's literally what they're asking of Apple. They keep refusing.
>>53378626
You do know he admitted this is for publicity
>>53378008
>You need a power source to read the storage. The same firmware which contains the code to read the storage also contains the code to wipe everything.
I have to give it to Apple, these are I-have-scat-CP-tier security measures. This is the most low level solution that still makes it near impossible to disable the wiping mechanism. Very nice.
>>53378733
nope, FBI are asking Apple to write a brute-forcer too.
I guess all this hooplah with the govt forcing Apple to submit to their demands is for show as it's possible for them to do it on their own but at the cost of great resources.
Though I doubt McAfee is correct about how to go about unlocking the device.
>>53378782
I kind of assumed it had to be, but I'm surprised he would openly admit that.
>>53378801
Pretty damn sure if Apple makes them a custom firmware where they can have a chance for infinite inputs then the case would pretty much be solved. Apple is not doing this because it violates their 'principles' or whatever. As far as I know the FBI only wants a custom firmware/OS update from Apple that gives them the option for infinite attempts. Never read that they also want them to code a brute-forcer, which is ultimately pointless and doable by pretty much anyone with half a brain. Getting the right signature (e.g. from Apple) for the firmware (that they don't have) is a bigger issue.
>>53378866
>too retarded to actually read the court order
>make some bullshit up
>>53377577
>strawman implications
>>53378886
Meh, the bruteforcer bit is irrelevant if they don't have the firmware first.
How come MS store email passwords in clear text?
>>53378927
https://www.youtube.com/watch?v=wr9IbTpiuug
>>53377943
encryption.
>>53377013
Somebody explain this to me:
Why can't you just brute-force it? It's only a few digits long.
Just try to decrypt the contents of the phone with every PIN until one works.
Doesn't matter how many fancy hardware IDs are involved, if you have access to the actual chips that send you these hardware IDs.
>>53378626
what if he already done it before.
Then what?
>>53378927
Soft boundaries within the user account do nothing to protect you from attacks. Your protection is to lock your OS user account.
>>53379010
After a certain number of failed attempts the phone gets wiped. The main thing the FBI wants is a custom firmware that gets rid of that feature so they can bruteforce it.
>>53378626
>Apple could easily have licensed the ARM core, made alteration to give it a special walled-off, on-CPU key/PIN storage and decryption engine, and McAfee would be out of luck even if he could hijack the DRAM interface and make a complete RAM copy.
Why not just hijack the bus they use to load instructions out of the flash storage and send it your own payload instead to brute force the on-CPU decryption module?
Or are you suggesting that the entire OS is encrypted and the on-CPU decryption engine decrypts the instructions in realtime?
>>53379062
but then everyone can bruteforce iphoons.
Niggers will have all the stolen phones now to keep.
>>53379062
>After a certain number of failed attempts the phone gets wiped. The main thing the FBI wants is a custom firmware that gets rid of that feature so they can bruteforce it.
Why can't they just write that firmware and flash it onto the phone? You just have to edit out the code that limits the number of attempts, or better yet, replace it by an automated routine for brute forcing the PIN.
Am I stupid or what am I missing?
>>53379081
It's not that they can't, it's more they don't want to and don't believe the FBI has the authority to make them do so. There's also the concern that this "one time use" build will leak out and lead to >>53379079.
>>53379081
Needs to be signed by Apple.
>>53379079
that's not how iOS updates work. every iPhone needs their own personalized signature for updates:
https://en.wikipedia.org/wiki/SHSH_blob
>>53378414
If the only time the person touches their phone is to enter the code.
>Dump phone memory/storage to disk
> Use emulator to start up saved data
> Attach debugger to emulator
> input pin follow to where it calls dec or inc to count tries.
> Nop out call
> Brute force pin
> Unlock iPhone
>>53379079
we already have all the pieces to brute-force iPhones except Apple's signature.
Apple's signature is in an HSM. you can't copy an HSM. FBI at most gets to borrow it for a very short time and won't be able to sign anything afterwards.
and then there's >>53379152
>>53379240
except there's a hardware key, which you can't dump
>>53377943
Why can't they unsolder the NAND, dump it, locate the OS partition, patch the lockscreen code and resolder the NAND on the phone board?
>>53379320
>what is PKI
everything is signed
>>53379158
Even after some usage it might still be recoverable. Though it obviously depends on the kind of usage.
>>53379121
Does the actual CPU contain a key verification mechanism for checking signatures on the instructions it's executing, in realtime?
>>53379433
no, what would be the point?
higher up hashes would still detect such corruptions.
>>53378966
why don't they use a d-wave to crack the encryption after dumping the memory contents?
>>53379728
So what's stopping you from sending the CPU your own code by hooking into the instruction bus directly?
The point is either the crypto and keys are directly on the CPU (i.e. a component you can't easily open up and poke around in), or it's external.
And if it's external, you can just replace or bypass it.
Unless the PIN-entry limit code is actually part of the cryptohardware itself?
>>53379753
>D-wave
Because it's slower than an old laptop.
>>53377013
It's not in plain memory, but you can disassemble the code running on the phone and prevent it from locking out after too many incorrect PIN attempts and then do what >>53379010 suggests.
John is too high to say what he means clearly or being interrupted by some FBI or CNN guy.
why don't they use a quantom flux trans capacitor to initiate a hymen-dosh phase field to decypher the binary into a quadrillion cageperemeter, then initiate the transphasic torpedo brute force method to intiate a 001 matrix extrapilation of the data?
>>53377576
LEL
MCAFEE HAS SHADY CONTACTS EVERYWHERE
JUST NEEDS TO HIT UP ONE OF HIS DRUG ADDICTED BUDDIES WORKING IN APPLE AND HAVE THEM SET A NEW PIN FROM THEIR SIDE
ITS SO OBVIOUS APPLE ALREADY HAS THE CAPABILITY, THEY CAN UNLOCK ANY OF THEIR DEVICES IN 2 SECONDS
>>53380071
>trans capacitor
triggered
>>53377564
>tfw fully encrupted with 16 digit pw
>tfw 6x6 "draw" lockscreen with only 4 used but three of them two times
>tfw no face because you cant access it
>>53379769
>The point is either the crypto and keys are directly on the CPU (i.e. a component you can't easily open up and poke around in), or it's external.
Package on package on modern SoCs makes nothing easy to access.
we only know there's some likely hw logic that does:get_masterkey(passcode)
return hash(hw_key, passcode)
no one managed to dump the hw_key ever, so it's likely not on any bus.
>Unless the PIN-entry limit code is actually part of the cryptohardware itself?
not on the iPhone 5c that doesn't have a secure enclave.
iPhone 5c just wipes the flash anyway, hw_key and hash function are still there, so just cloning the flash is easier (but still hard due to PoP) than to reverse engineer anything else.
>>53379068
there are tons of ways the security could be designed, but here's the simplest thing I can think of that would stop most anyone:
> walled-off, on-CPU crypto engine and primary key store
> RAM not encrypted when phone is active, but all user data encrypted or dropped when phone locks
> primary key needs PIN to unlock, but rate and total attempted limited in the HW unit itself
you could conceivably hijack the OS SW instructions to block the encryption sweep, but once the phone was locked, you're at the mercy of the instructionless crypto black box (or exotic shit like optical fault injection) to try to get the data back, since there's nowhere in the global HW memory space storing the key nor any way to tell the key store to not self-destruct on repeated access failure.
>/neo-g/ thinks a guy who wrote a bloated clickibunti progressbar ui for windumb knows shit about computers
>>53380922
FDE is totally overrated and not helpful in most cases:
it only protects when the phone is off or locked
it won't protect against common attacks when the phone is on
it won't hinder any tracking
fingerprint scanner make it easy to bypass
if you don't fear LEA, having the flash in some hard to access PoP SoC already defends against common thieves trying to dump your data
>> RAM not encrypted when phone is active, but all user data encrypted or dropped when phone locks
bad design.
a. masterkey might be in RAM
b. a locked phone is still supposed to function you can't just drop everything
>>53380087
If they did, they wouldn't be able to admit it publicly and this case has so much attention now cracking the phone in 2 seconds would cause the utmost shitstorm.
>>53381562
>If they did, they wouldn't be able to admit it publicly
except they did:
http://www.nytimes.com/2016/02/25/technology/apple-is-said-to-be-working-on-an-iphone-even-it-cant-hack.html
>>53377597
This is a 5 though
>>53381406
But he's on the new and is a presidential candidate.
>tfw password is the same default 0000
idgaf
>>53381406
Go to bed kid you don't know jack.
>>53377013
Can we just copy ALL data from the phone to disk
Try to brute force pin
If fail overwrite data and brute force pin again
>>53382046
>not using mathematical or physical constants
>>53377564
This person is totally retard, more so than McAfee ignore him.
>>53378899
checked, dubs confirm truth.
http://www.dailydot.com/politics/john-mcafee-lied-iphone-apple-fbi/?tw=dd
"My point is to bring to the American public the problem that the FBI is trying to [fool] the American public. How am I going to do that, by just going off and saying it? No one is going to listen to that crap.
So I come up with something sensational. Now, what I did not lie about was my ability to crack the iPhone. I can do it. It’s a piece of friggin’ cake. You could probably do it. By doing so, I knew that I would get a shitload of public attention, which I did"
>>53382340
No, Apple devices do not support file transfer.
>>53377564
Kek, the "draw picture" is still just a numerical password, just replace the "dots" with numbers and there you have your code.
>>53382340
hw-key is on device.
if you copy data and bruteforce you have to bruteforce the 256-bit AES key generated from the hw-key and passcode, not the 5.3-bit passcode, but you don't have to fear any auto-erase ever, which is bullshit anyway (see aclu link below)
>>53382702
it's easy to solder off:
https://www.aclu.org/blog/free-future/one-fbis-major-claims-iphone-case-fraudulent
>>53380922
>>53381411
on-die AES chip that transparently encrypts/decrypts ALL data fetched from storage (flash or ram).
Decryption key stored in a CPU register and derived from a hardware ID generated from per-chip design defects in the silicon. (Would that be possible? i.e. deliberately introduce a bunch of errors into a big grid of transistors and the resulting logic function will seed your PRNG)
Only way to break it would be to open up the die itself and inspect the silicon to reverse engineer what it's doing.
How easy can the 5-O get into my Note 5 if I have fingerprint scanner enabled?
>>53382848
Apple does
>Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space.
>>53383203
>entangled with its UID
d-does that make it quantum cryptography? :^)
>>53377564
>rainbow table attack
Any developer that is competent in security will be salting their password, so rainbow tables are obsolete.
>>53382925
Easy, they just take your fingerprints and put it on the phone.
>>53382340
Of course they can, but that would be too expensive to do on a regular basis and potentially destroy the information.
>>53382799
>if you copy data and bruteforce you have to bruteforce the 256-bit AES key generated from the hw-key and passcode, not the 5.3-bit passcode
You just need to use the same hashing scheme that apple is using, then you can brute force the pin.
>>53385199
>You just need to use the same hashing scheme that apple is using, then you can brute force the pin.
The hashing scheme is device-dependent and can't easily be reconstructed.
>>53385284
>device-dependent
How is it device-dependent? If you can dump the binaries on the device, you can reconstruct it.
>>53385351
>If you can dump the binaries on the device, you can reconstruct it.
What if the binaries are encrypted with a key that you don't know?
>>53385454
lol
>>53385409
Isn't that just effectively salting the password? I would be surprised if that wasn't stored in the ROM somewhere. Getting it out of the ROM could be near impossible though.
>>53385351
read
https://media.blackhat.com/bh-ad-11/Belenko/bh-ad-11-Belenko-iOS_Data_Protection.pdf
>>53385519
no, those are hw keys.
read up:
https://www.theiphonewiki.com/wiki/GID_Key
>>53385351
>>53385519
Key embedded in the silicon of the CPU chip.
Now what motherfucker?
>>53385561
https://www.theiphonewiki.com/wiki/GID_Key#Potential_attacks
>>53385519
You could theoretically get the info out but youd have to pull the chip, lap it down to the circuitry, inspect it with an appropriate microscope and manually reverse engineer what you find, every fucking time you switched devices.
>>53385561
>Key embedded in the silicon of the CPU chip
As I said, it's probably stored in ROM and that's not easy to read. Electron microscope, maybe?
It's the government, so they're not stranger to wasting money on fighting terrorism.
>>53385610
>not stranger
god damn it
>>53385569
The references to actual research on using side-channel attacks to break secure crypto devices are pretty neat.
Thanks for sharing.
>>53377013
Protip: John McAfee is an idiot
>>53378713
Underrated post
>>53379320
That's a cool way to ask "Why can't they permanently brick the phone?!
>>53378866
Apple doesn't want to do it because it's complex stuff that would cost them a lot of man hours. With a precedent like this, they and any other company would essentially be forced to work for the government for free whenever they clap their hands.
McAfee is a fucking crazy son of a bitch. Of course RT would be giving him an audience.
