[Oliver] wiped the hard drive from a Macbook Pro using the ‘dd’ command on another machine. This does a great job of getting everything off the drive, but he was still faced with the EFI PIN lock protection when he tried to put it back into the Mac. You used to be able to clear the NVRAM to get around this issue, but that exploit has now been patched. So [Oliver] set out to use a microcontroller to brute-force the EFI PIN.
You can read his back story at the link above. He had the chance to enter a 4-digit pin before the format process. Now that he’s wiped the drive the code is at least 6 characters long, which is a lot more possibilities (at least it’s numeric characters only!). To automate the process he programmed this Teensy board to try every possible combination. It worked great on a text editor but sometimes the characters, or the enter command wouldn’t register. He guesses this was some type of protection against automated attackers. To get around the issue he added different delays between the key presses, and between entering each code. This fixed the issue, as you can see in the clip after the break. Unfortunately after two 48-hour runs that tried every code he still hasn’t gained access!
there’s probably some reason why it won’t work.
^No shit Mr. Obvious
that is TRUE!! he just needs to find the reason why, then determine a solution, and implement it!
at least 6 characters long is the culprit. so he has no idea of length?
code is probably 000000 but he starts at 000001 :)
Try AWARD_SW :-D hey, you never know someone might have a sense of humor.
Note that he owns this computer, it is his. Yet DRM is keeping him from using it.
Agreed. UEFI was only designed to prevent people being able to do this kind of thing and make it difficult to install other OS’s. The whole “we made UEFI to protect against MBR viruses” is a load of bullshit. When was the last time anyone had an MBR virus?
Polio shots are bullshit. When was the last time anyone had Polio?
Oh.
Actually people still catch polio. Because it’s something that actually exists and is communicable, and actively infectious.
This rock I have, on the other hand, keeps tigers from taking down the site. And when was the last time Hackaday was brought down by tigers, hmm?
What a stupid comparison. Would you take a Polio vaccine if it meant you were no longer able to exercise any form of free will? In some cases the cure is worse than the virus.
If you were starving and I gave you a hamburger and a box of staples, which would you eat? Probably the hamburger, unless you’re mentally ill, in which case the staples. In either case your decision is a product of your knowledge, experiences, and personality, which is itself the product of the complex interplay of inherited and environmental factors. The philosophical concept of free will–that is, the ability to choose actions unconstrained by outside factors–is an illusion. You are free insofar as you may act within your nature.
BTW: I agree with you, just sayin’. :V
That’s that bullshit analogy ever.
The last MBR virus died when most BIOS’s added a “lock MBR” option.
We use them to prevent students from shagging around with each others machines. If we could disable command+s boot we wouldn’t even use the EFI password.
Anyway all he has to do is call his local apple shop, ask them to do a TSPS chat to get the file, put it on a USB stick and boot with it in. Unlocks EFI really quickly, and they shouldn’t even charge for it (because it is literally so damned easy). But failing to brute force is far funnier.
UEFI is terrible but FYI I see MBR viruses on a weekly basis. They started being revived about 1 1/2 year ago. Fortunately they are pretty easy to find and remove, for now.
It’s odd since intel when it fiirst came with UEFI found it met massive resistance due to the DRM part.
But now we suddenly life in an age where people aren’t the ones having any influence anymore and it’s the weasels that decide and the people all bow.
BIOS were outdated not to mention beyond salvation and needed a replacement.
UEFI is fine, except for the third party limitations and overzealous security measures.
So the choice is currently between a rock and a hard place.
No UEFI isn’t fine. It is a bad solution that’s over complicated and bloated. And there have never been a good reason to develop a new system when something like e.g. OpenFirmware (or some other alternatives) already had a superior solution.
And don’t get me started on ACPI…
I’d love to hear about ACPI from an expert.
Open firmware was able to do everything UEFI could do and more.
UEFI is something that never needed to be created in the first place as a superior in every respect alternative already existed.
What’s up with all the failed hacks lately? A brute force attack that didn’t work, a locked-bootloader android hack that requires an unlocked bootloader, a (failed) try at replacing multiple RFID cards with a single tag, etc.
The ideas and designs that go into a hack are still worth mentioning, regardless if they are successful or not. At least I think so anyway :)
Any results are good results if you publish them. People can learn from your mistakes or, better yet, figure out where you went wrong.
Exactly. Dont do what donny dont does.
It is the end of winter. The deadline is fast approaching for inside activities and some are dropping out.
Anyway why has he not tried to use setregproptool?
Reasonable directions:
https://groups.google.com/forum/?fromgroups=#!topic/macenterprise/MJLFGnPQZMQ
Not that I know anything about the process, just something others use to wipe the pin.
the pin, is that like a butt??
If more people published failed results, others would not waste time duplicating their experiments.
If more people published failed results, others may give them valuable feedback in what went wrong and what to try different.
Double win
IIRC, changing the amount of ram would allow you to erase NVRAM, clear PRAM and Bob’s your uncle. I think this was intentionally done for cases just like yours where you have physical access to the computer but can’t remember the EFI password. Easy enough for most people to do, but something that takes some amount of time and effort and physical access.
RAM and NVRAM are two different things. If this is like other Intel platforms, then NVRAM is some number of erase blocks on an SPI NOR flash part. In this case, it sounds like the PIN (or the resulting hash) is stored in some sort of vendor specific storage, so it might be some other special NVRAM store, storage behind some sort of micro controller, or some other security device. There may be ways to hack it with physical access, but it would take specialized knowledge.
I think that if you read more closely, you will that that what peter is suggesting is that the firmware may allow you to clear the the NVRAM when it detects a change in the hardware configuration (since that pretty much proves that you have physical access to the machine). I have no idea if that is correct, but it doesn’t appear to me that he is confusing NVRAM with RAM.
Phsyical access? If you are entering a EFI password in the first place then you have physical access unless youre talking about some obscure scenario with a IP based KVM.
Oops, my mistake.
Still, it’s general not good practice to wipe out all of NVRAM because of a simple config change, we aren’t dealing with battery backed up CMOS these days.
If you’re curious, you can have a look here at the EDK2’s NVRAM variable service code: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
The function VariableServiceGetVariable () is the GetVariable() runtime service.
I did find mention of the RAM trick. I don’t know if that worked for Intel based Macs though. It just doesn’t make any sense to me based on what I know about (U)EFI.
It may have a simple rate-limiter. If it took 48 hours, he is doing around 3 attempts per second. I would try slowing it down, with random sleeps between attempts.
One other alternative, possibly in addition to the rate limiter, it could simply be disregarding any attempts after a given number of incorrect attempts (say 3-5) until the hardware is reset. It may just be presenting the prompt again to combat those that don’t think of this possibility.
I’m pretty sure the Apple firmware is based on either the EDK or EDK2 at http://www.tianocore.org. If they are using the old Tiano USB driver, then I believe it will poll EHCIs via a periodic timer callback and all the timers in EFI only guarantee a minimum delay rather than a min and max. It’s possible that is getting in the way and causing the dropped keystrokes.
I doubt it. Apple’s EFI is officially EFI 1.0 (or was it 1.99? I don’t feel like rebooting to rEFInd to check.). The newer the machine is, the more UEFI 2 features it supports though, with some of the machines since 2010 supporting enough to boot Windows through EFI. Additionally, Apple’s EFI has a couple of extensions, such as supporting fat 32/64 bit binaries and including an HFS+ driver in addition to the required FAT driver.
I got curious and burned a rEFIt disk and it reports version 1.10 in the shell. I’m seeing some wonky behavior for a couple commands. I’ll have to throw together a shell app to try working some of the 2.0 and 2.1 extensions to see what happens.
But back to my original point, the EDK2’s USB driver looks like it’s still using polling based on EhcExecTransfer() in https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c
It might be possible that Apple invested the time to rewrite the USB driver to use SMIs instead like another IBV’s UEFI product but that would be a lot of work for something that isn’t used much.
FAT support has been part of the EDK for a long time and I don’t think writing a EFI HFS+ driver would be that bad. Doing crazy stuff to a UEFI core is pretty much par for the course when it comes to OEMs :)
there is a much easier way to clear the NVRAM and all the PINs
– shut down your MB
– open the back and remove one of its RAM sticks (if it has only one, the you have to add one)
what this does is changing the configuration, and all the EFI passwords are removed
– power on MB and do a NVRAM reset, (search KB-shortcuts in the intarwebs)
thats it… you are done… after checking the MB powers up normally, put back the RAM stick you took out (or remove the one you put in)
its not my idea, found it somewhere else, since i had a customer w. same problems (forgotten login-pw and non-fixable filesystem-errors, and EFI-Password, so no booting from external media)
hope apple never fixes that backdoor…
greeting fm. Kaohsiung/ Taiwan
love hackaday
Erich Honecker
It doesn’t work on new MBPs I tried it
They “fixed” it with soldered RAM in the Retina MBP.
It is not the soldered RAM.. it is a dedicated chip for this.
The chip reads “ATMEL 1123 TINY13V 10SU”
Here is a picture of it http://jerseycityrepair.com/wp-content/uploads/2012/03/atmel.jpg
The most nefarious use of an Atiny ever.
Keyboard.press(pin[1]);
delay(450);
Keyboard.release(pin[1]);
delay(420);
Keyboard.press(pin[1]);
delay(398);
Keyboard.release(pin[1]);
He’s missing pin[0]–so technically not the entire range of values–and possibly why it didn’t work.
PS: Does hackaday have code tags? Because it needs some.
Thank you for pointing this out. I am sure it is a typo since I am typing all 4 digits but… I was checking at my history and I might be sending pin[1] twice.
Here is what I ma reffering too.
I will leave the teensy running tonight with the actual code that it has loaded on it to see what happens after I reach 0099, If I am seding pin[1] twice at the begining it should pirint 0000 instead of 0100
Yep, he seems to have updated his code and is going to try again. Hope this time he gets it.
PS: Does hackaday have code tags? Because it needs some.
it’s just <code> and </code>
I don’t know if it’ll work for you…
it also needs to randomness in the delays to simulate a human.
Just a hunch, but perhaps the EFI pin is stored in the HDD non-volatile storage.
From his post
Couldn’t your find a clean MBP firmware someone online?
I tried to post this:
A little more extreme alternatives.
In a conversation with an Australian who specializes in pentesting mac EFIs (among other things) I was told that an alternative solution would be to get a fresh MBP, extract its firmware and flash it using a PIC programmer. He also told me that there are ways to get around this attacking the thunderbolt port but these two options have a high risk in bricking the $2.000 laptop
apparently pre tags dont work in this comment section
I think most hardware makers have switched over to SPI flash parts which can be flashed in circuit. I don’t know if Apple has left something there to attach a programmer, or if the chip is not a BGA part so an interposer clip can be used.
If there is a header or the chip is not BGA, then http://www.dediprog.com/SPI-flash-in-circuit-programming/SF100 might be a solution.
He needs to add RANDOM waits of a couple seconds and more.
I would add waits from 2 to 10 seconds, with each keypress, then wait like 10-20 after hitting enter,.
That is insane amount of time, It would take weeks if not months (I have not done the math)
it would only a week, assuming the max wait time(10per keypress, 20per Enter).
10*4 = 40seconds + 20secs (for enter) = 1min
9999 mins to go through all 9999 combinations
9999 mins / 60 = 166 hours
166 / 24 = 6.94days
Is my math wrong?
Yes, you’re wrong because the amount of combinations is not 10^4, but 10^6 = 1.000.000. That would take a hundred times longer, so 694 days.
the article says the pin is at least 6 digits.
Cool :-)
If every pin was indeed used, I would hazard a guess the firmware is ignoring successive attempts after a pre defined “limit”. The machine might need to be power cycled after every n attempts. (At least this is what I would do if i wrote the firmware)
To find “n” find another (working) mac, set a pin, and try a newton raphson (i think it’s called, could be Runge cutter) method to find the “limit” (if it has one)
i.e.: wrong = deliberate incorrect pin attempt; right = correct pin.
wrong, wrong, wrong, wrong, wrong, wrong, wrong, wrong, wrong, right (does it unlock?)
Y -> double the wrongs.
N-> half them.
Repeat process until you find n.
If n is massive, it might be hard to find manually, but, I’m sure the teensy can be re jigged to do this. It would be more of a pain it if it’s relatively small as the reboot will eat into the brute force time.
how did you get 9999 combinations? isnt the max amount of combinations possible 6^6 which is 46 656
000000
000001
000002
….
999998
999999
is 10^6=1000000 (not so hard math)
It is not really hard to calculate. The maximum time will take to crack the password would be 15 days max. This is because 10^6=1000000. 1000000 attempts to find out the password. Lets assume the tool can enter 6 digits and enter buttons in about 5 second. 1000000 * 5 = 5000000. to minutes it would be 83333.33333 minutes. 83333.33333 to days would be 57.87037037 days, this is assuming you don’t have to wait for next attempt like 5 minutes every five attempts. so if we were to delay five minutes for every five attempts the maximum days to crack the password would be 57.87037037+6.94444444=64.81481481.
That is all guys Good luck waiting more than two months to solve the password.
each of 6 digits has 10 possible values so it’s 10^6, would only be 6^6 if you were rolling cube dice.
He could just take it to an AppleStore: they can reset the pin.
Just take it to an AASP, the EFI pin can be reset with a special boot image (once proof of ownership is confirmed).
Source: I’m an ACMT.
As a CCE none of this is forensically sound …
I took mine in to an Apple Store sat there for 4 hours and they could not get my efi password reset
1. lesson learned dont erase a drive before removing the efi protection.
2. if you are preparing the mac for donation or recycling you could just remove the drive and replace it with a new drive ( drives are very cheap less than $100 1 tb.
or you can remove the drive pop in in a linux box and do a bootnNuke on the drive with dod standards…
To reset the firmware password on newer Macs, you must now follow these steps:
1. Boot with Option key held to display the boot menu’s firmware password prompt.
2. Press Control-Option-Command-Shift-S to reveal a 33-digit hash (mixed letters and numbers) that contains an identifier for your specific motherboard and the Atmel chip used for your system. In this hash, the first 17 digits are an identifier for the system’s motherboard, and the last 16 digits are a hash for the password.
3. Submit the hash to Apple, where someone will put it through a special utility to create a keyfile that is specific for your machine.
4. Place the file on a special USB boot drive and hold Option to load the boot menu and select this drive.
The system will read the file and properly reset the firmware password stored in the Atmel chip.
Makes me feel better about having to boot from a usb key, format the hard drive, copy the windows 7 install files to the hard drive, and then boot from the hard drive to install both to and from the hard drive at the same time, just to get around the drm on my new toshiba…at least the bios would let me get away with it…even if it was designed to block dvd booting and usb os installs.
I’m not a mac guy, only use it on pcs; and not in a few years now…so this might be a dumb idea…but couldn’t you just put in another hard drive, resetting the drm…and then put the old drive back in after a complete random overwrite?
Nope – motherboard bios is where the lockout password is stored / checked. He can install clean hard drives with good OS images on them until the cows come home, the hardware won’t run code off them until he provides this access code.
Ugh, really? Toshiba just made my “no way in hell I’ll ever voluntarily pay for one” list.
One of the best “Points” in the thread.
Blocking a USB OS Install is how the OEM tells us that Puppy Linux SCARES them.
Did anyone else notice he’s taking about 6 seconds per pin number? If it’s 10^6 possibilities, then this should take ~69 days to go through all combinations, not 48 hours. Is my math sound?
10^6 * 6 = 6,000,000 s
ans / 60 = 100,000 min
ans / 60 = 1666.67 h
ans / 24 = 69.4 days
I think he’s doing about 3 hits per second, so it all took about 48 hours to complete. (right?)
it will take 34.722222222222222222222222222222 days not hours my man…. Second if you are dealing with 5 mins wait you will have to add 2.3148148148148148148148148148148 days to the above number so in total about 37 days
Friends,
Those of you assuming that it is a 6 digit PIN. When you lock it with an iOS device it is only a 4 digit PIN. I have screenshots of the screen that prompts for 4 digits in my article.
iUnlockEFI.com can unlock it.