shackspace’s @dop3j0e had a big problem.  A password problem.  Quite a while ago he set up a password for his Thinkpad’s harddrive and chose to unlock his drive using the built-in fingerprint scanner.  Years passed, thumbs were drawn over the scanner countless times, passwords were changed frequently.  But not all passwords were changed.  That one password for his harddrive never did change and over time he simply forgot what the actual password was.

The thumb print scanner kept working.  However, to change or disable the password you have to enter it by keyboard in the BIOS since in this case it does not accept the thumb print scanner as input.
This poses a real problem.  How do you access the disk if your fingerprint scanner dies?  Or what if the laptop dies and you have to unlock the drive from a different machine that doesn’t have the password stored in the fingerprint scanner?

There’s various approaches to go about this issue.
One idea was  to reverse engineer the BIOS to find out where the actual password is stored.  This turned out to be especially nasty business and while a lot of insight was gained into how (ugly) a BIOS looks from the inside, no password was recovered.
Another idea which does not work was exchanging the control board of the harddrive with that of a similar model. Turns out the harddrive password is stored on the platter, not the controller.
You could of course use a logic sniffer (costs multiple kilo-Euros) and sniff the IDE bus for the password being transmitted.  Not really an option either… or is it?

Open Source Hardware to the Rescue

Thanks to the open source hardware movement, you can have a logic sniffer for just $50!  The OpenBench Logic Sniffer is exactly what you want and @hdznrrd at shackspace just happened to receive his first batch pre-order at the exact time @dop3j0e was about to fall into despair.

The OBLS comes with 16 buffered (3.3 or 5V) pins and another 16 unbuffered (3.3V only) pins.  The IDE bus happens to be a 5V bus, ruling out half of the capture pins, and to sniff everything you’d need 40 pins.

It turns out it’s good enough to just sniff the data pins and nothing else (details below).  And yes, the IDE bus has exactly 16 data pins 🙂

Sniffing the IDE bus for the Password Transfer

Next it was time to hook up the harddrive to the sniffer.  What makes this slightly complicated is that you have to sniff the bus while the harddrive is mounted inside the laptop.
To do this individual wires were connected to each of the 16 data pins.  Since the drive bay wasn’t large enough to accommodate the wiring, the laptop had to be partially disassembled.

The OBLS is compatible with the SUMP Logic Analyzer GUI which was used to control the analyzer and set up triggering.

The sniffer was set up to start logging data as soon as the 0xF2 unlock command is seen on the data bus which is then followed by the plain text password, which is exactly what you need to unlock the drive yourself. A from-memory reconstruction of the trigger settings can be found here.

Below screenshot shows the SUMP GUI displaying the results of a successful password sniffing run (note the ‚f2‘ command).  Note: the Prezi presentation linked below contains an annotated full length  screen capture of the sniffed password.

Unlocking the Drive

Now the drive can be unlocked using the handy hdparm tool:

# hdparm --user-master u --security-unlock \
  $(echo -ne "\036\023\042\046\006\002\004\013")

Once unlocked, the password can be disabled entirely:

# hdparm --user-master u --security-disable \
  $(echo -ne "\036\023\042\046\006\002\004\013")


Update #1: Exchanged the SUMP screenshot with one that actually shows the 0xf2 command.
Update #2
: Added more info why sniffing of the password was necessary.
Update #3
: Added link to the trigger settings.

Flattr this!

Urspünglich gepostet: April 27th, 2011
Tags: Allgemein, Projekte

Reader's Comments

  1. Adam | April 28th, 2011 at 17:04

    Nice and very interesting work.

    Do you think you can possibly annotate the SUMP screen shot? I’m having trouble seeing the 0xF2 (0b1111 0010) command come across. I’m assuming its somewhere near the 0x1E/0x22, but I’m having a hard time seeing it because I don’t know how the bus is ordered on the display.

  2. jocki | April 28th, 2011 at 17:57

    @Adam — The screenshot only shows a very small section of the trace. Check out the prezi, it’s got the full annotated trace near the very end.

  3. hadez | April 28th, 2011 at 17:57

    I’ve replaced the screenshot with the one used in the Prezi. It should now show the 0xf2 command as advertised

  4. JVas | April 28th, 2011 at 18:31

    great trick. actually have a few drives that i need to unlock that i have had sitting in my office for the past year or so. on another note i have just one question. the multi-colored alligator clip looking things. what exactly are those and where do you get them because i see them used in various projects debugging before final wiring

  5. hadez | April 28th, 2011 at 19:18

    You can find them at Seeedstudio as well:

  6. Adam | April 28th, 2011 at 20:33

    @joki and hadez – Thanks, I was feeling very stupid for not seeing it 🙂 its nice to know there was nothing to see. Good work, and thanks again.

  7. Chris | April 28th, 2011 at 20:55

    What I don’t get, and can’t make up from the article is why the password is sent.

    I’d expect the hard disk is only unlocked after presenting a correct fingerprint. Since you can sniff the unlock command, why isn’t the hard disk unlocked by this command?

    Interesting article nonetheless.

  8. hadez | April 28th, 2011 at 21:38

    the issue here is that you actually have to enter the password via the keyboard to disable or change it in the BIOS.
    if you forgot it, you can still use the thumb print scanner to unlock it, but you can never change or disable it.
    I’ll update the article to make this clearer. Thanks for the feedback.

  9. IraqiGeek | April 29th, 2011 at 02:06

    Seeing as this is for IDE drives, would it be possible to use two IDE-SATA bridges to accomplish the same with SATA drives?

    That is, SATA from the motherboard/chipset goes to the frist IDE-SATA bridge to get an IDE interface that we can tap, then this IDE interface is fed to the second IDE-SATA bridge to get SATA again which goes to a SATA disk.

    I don’t know if that would work, but if it does, that would still be an under $100 solution that can recover passwords for SATA drives.

    Just a thought…

  10. hadez | April 29th, 2011 at 02:12

    if your IDE bridge setup works, you should be able to sniff the bus.
    if you can manage the rates at which SATA transmits data, you can employ the same approach by sniffing SATA directly, it should be even easier since it’s a serial bus with way less pins. problem is, the data rate is usually a lot higher, possibly out of range of your sniffer (might try lower speed legacy modes).

    also note, that this approach only works in the specific case where you can still unlock the drive using (in this case) the password stored $somewhere but still accessible via the thumb print scanner, even if you forgot the actual password (as in this case). if you have no means of replaying the password in some way or other, you cannot use this method to unlock the drive.

  11. Gloria | Mai 19th, 2011 at 21:47

    Hi guys,

    i’m trying to understand how to use trigger option to activate logging when it „catch“ a particular char.

    How did you set/instruct OLS to activate logging when it „catch“ 0xF2 ?!

    Thank you for attention



  12. jocki | Mai 20th, 2011 at 21:32

    Hey, Gloria,

    I reconstructed the trigger settings from memory and took a screenshot — please have a look at

    Actual trigger settings depend very much on which wire went where, but the screenshot should help you get an idea of what I did.


  13. Gloria | Mai 23rd, 2011 at 13:40

    Hi Jocki,

    Now i understand how you did that.

    Thank you for the answer.



  14. JC | Februar 18th, 2012 at 15:45

    Nice work!
    I reviewed the extended presentation…
    One question for clarification if I may…. Did the pinout match one for one to the OBLS? (I.e. the data pin #14 on the IDE cable go to the labeled pin 14 on the OBLS) OR did it match the the Data transmission pins one for one from the HDD? If you could elaborate that would be awesome!

  15. jocki | Februar 21st, 2012 at 13:04

    Hi, JC,

    I connected the wires such that IDE data bit 0 (pin 17) went to OBLS pin 0, IDE data bit 1 (pin 15) went to OBLS pin 1, and so on until IDE data bit 15 (pin 18) went to OBLS pin 15.

    I used the pinout described in — it’s German, but I find it easier to digest than the pin listing in its English counterpart.

    Hope that answers your question.

  16. Problemhund | September 28th, 2013 at 17:20

    Hallo, Ich finde den Aufbau der Seite klasse. Macht bitte weiter

  17. Pete | Mai 21st, 2014 at 17:24

    Nice job!!!
    Where did you get that header connected to the HDD?

  18. Jocki | Mai 21st, 2014 at 18:53

    Hey, Pete,

    the HDD uses a 2mm pin pitch, so I used a standard 2×20 2mm header with machined pins. It’s important that the pins be machined, because those still work if you break the header apart and use the individual pins.

    As for the „where“, any well-equipped distributor should have these.

    Hope that helps,

  19. PhreakShow | November 18th, 2015 at 00:14

    Hi Jocki,

    nicely done. I find myself in a similar situation, but my problems lies with a SATA harddisk. That’s why I bought an adaptor to 2,5″ PATA, and locked an old PATA drive with a password I know. My plan:
    The PATA drive also gets an unlock command, but with the wrong password. For comparison, I can unlock it at my notebook with my known password and know where to look.
    If it fails, then I will hook up another adaptor to convert back to SATA again, but keep sniffing in between.

    My problem is: I hooked up all 16 lines of my LAPC logic analyzer by Zeroplus, set the trigger for 0xF2. How do I know the length, and how do I know the 0xF2 is not just some random data that triggered by accident? A lot of bytes seem to be 20ns long, although some are faster and they only take 10ns.

    Looking forward to your help.


  20. Jocki | November 18th, 2015 at 13:50

    Hey PhreakShow,

    We’re talking about one of the first commands the PC sends to the harddisk, especially before any actual sectors are transmitted, so the chances of a false positive should be relatively low.

    I had the same worries when I did it, but tried and it just worked.

    Good luck on the SATA-PATA conversion; that is a very interesting approach, please keep us posted here on your success!


  21. PhreakShow | November 20th, 2015 at 22:56

    What strikes me most about this problem: Both our logic analyzers run at a maximum of 100MHz. But isn’t this too slow for sampling a signal at IDE’s speed with a maximum of 133MB/s?
    Would you mind contacting me on my provided email?


  22. Jocki | November 27th, 2015 at 14:02

    Communication likely doesn’t start out at this high rate — the bulk of the controller is part of the harddisk after all, or used to be in the early days, so the BIOS will start out at a slow PIO mode and only ramp up the speed for actual transfer of sectors.

    In my case, the password was transmitted slowly enough that I had no problems tracing it. Just try it out.

    Re email, I’d rather keep the discussion in the open on here so others can benefit from it, too.


  23. PhreakShow | November 29th, 2015 at 03:37

    It’s working. Slowing the process down to PATA and looking for the password in the parallel bus did the trick 😀

  24. ConcernedThirdParty | Juni 9th, 2016 at 06:34

    Phreakshow can you let us know which IDE-Sata bridges you used? chipset? etc.

Leave a Comment