Mac EFI PIN lock brute force attack (unsuccessful)

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

81 thoughts on “Mac EFI PIN lock brute force attack (unsuccessful)

    1. 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?

        1. 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?

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

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

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

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

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

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

      1. 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…

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

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

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

    2. Any results are good results if you publish them. People can learn from your mistakes or, better yet, figure out where you went wrong.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1. 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?

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

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

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

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

  12. 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?

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

    2. One of the best “Points” in the thread.

      Blocking a USB OS Install is how the OEM tells us that Puppy Linux SCARES them.

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

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

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

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