Mac EFI PIN lock brute force attack (unsuccessful)

mac-efi-pin-lock-brute-force

[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!

Comments

  1. efter the fyhn. get 'im kijer. everynew'x wints awesre. says:

    there’s probably some reason why it won’t work.

  2. RoadWarrior222 says:

    Try AWARD_SW :-D hey, you never know someone might have a sense of humor.

  3. DasDas says:

    Note that he owns this computer, it is his. Yet DRM is keeping him from using it.

    • lloyd_atkinson says:

      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?

      • slowJim says:

        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?

        • Garbz says:

          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.

          • Blue Footed Booby says:

            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.

          • Blue Footed Booby says:

            BTW: I agree with you, just sayin’. :V

        • Ruri says:

          That’s that bullshit analogy ever.

      • fartface says:

        The last MBR virus died when most BIOS’s added a “lock MBR” option.

      • Gitsnik says:

        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.

      • Promethius326 says:

        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.

      • Whatnot says:

        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.

    • Rez says:

      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.

      • Megol says:

        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…

      • Ruri says:

        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.

  4. HC says:

    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.

  5. peter says:

    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.

    • matt says:

      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.

  6. fileoffset says:

    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.

    • 0x4368726973 says:

      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.

  7. matt says:

    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.

    • Paxswill says:

      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.

      • matt says:

        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 :)

  8. Erich Honecker says:

    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

  9. junkbox says:

    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.

  10. Perry Harrington says:

    Just a hunch, but perhaps the EFI pin is stored in the HDD non-volatile storage.

  11. Gee says:

    From his post

    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

    Couldn’t your find a clean MBP firmware someone online?

    • Gee says:

      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

  12. Gee says:

    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,.

  13. jfet says:

    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.

  14. spider says:

    how did you get 9999 combinations? isnt the max amount of combinations possible 6^6 which is 46 656

    • Truth says:

      000000
      000001
      000002
      ….
      999998
      999999

    • borkie says:

      is 10^6=1000000 (not so hard math)

      • Abs says:

        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.

    • RoadWarrior222 says:

      each of 6 digits has 10 possible values so it’s 10^6, would only be 6^6 if you were rolling cube dice.

  15. Rob says:

    He could just take it to an AppleStore: they can reset the pin.

  16. xMob says:

    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.

  17. ejonesss says:

    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.

  18. mgudiry says:

    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.

  19. KillerBug says:

    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?

  20. Tyler says:

    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

  21. 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.

  22. Damiani says:

    iUnlockEFI.com can unlock it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s