IDE Bus Sniffing And Hard Drive Password Recovery


shackspace member [@dop3j0e] found himself in a real bind when trying to recover some data after his ThinkPad’s fingerprint scanner died. You see, he stored his hard drive password in the scanner, and over time completely forgot what it was. Once the scanner stopped working, he had no way to get at his data.

He brainstormed, trying to figure out the best way to recover his data. He considered reverse engineering the BIOS, which was an interesting exercise, but it did not yield any password data. He also thought about swapping the hard drive’s logic board with that of a similar drive, but it turns out that the password is stored on the platters, not the PCB.

With his options quickly running out, he turned to a piece of open-source hardware we’ve covered here in the past, the OpenBench Logic Sniffer. The IDE bus contains 16 data pins, and lucky for [@dop3j0e] the OpenBench has 16 5v pins as well – a perfect match. He wired the sniffer up to the laptop and booted the computer, watching SUMP for the unlock command to be issued. Sure enough he captured the password with ease, after which he unlocked and permanently removed it using hdparm.

Be sure to check out [@dop3j0e’s] presentation on the subject if you are interested in learning more about how the recovery was done.

34 thoughts on “IDE Bus Sniffing And Hard Drive Password Recovery

  1. So…why not just plug the hard drive into another machine, dump data…and then format the disk. I’m all for creative solutions to inane problems, but this is a bit overboard, unless I’m missing something. A neat hack nonetheless…but why?

    1. Because the password is stored on the drive. Hard-drives sometimes have their own password mechanism, which operates independently of the computer they are plugged into. My question is why didn’t he reverse engineer the scanner for the password?

    2. Because they were LOCKED. Most BIOSes won’t even exit the POST screen if the HDD is locked.

      A MUCH easier way to get around this is to boot up a machine that unlocks the hard drive (which his clearly did), and then unplug it from that machine (not the power just the IDE cable) and plug it into another machine (also already running).

      You’re not really supposed to do that, but if you’re careful it works pretty well. The original XBox can be soft-modded like this (if you can’t find the right version of Mech-Warrior. ;D)

  2. I am confused how he could be sniffing the password on the bus if indeed the fingerprint scanner was broken. Who is transmitting the password on the IDE bus? Does BIOS actually reads the password from the drive, then uses that password to unlock the drive?! That is hardly a secure system.

    1. No, the password is stored in two places in order to work, the BIOS or some other hardware on the laptop must have the password, and the harddrive itself must also know the password.

      If I sent an unlock command to the harddrive, and it didn’t know the password (or have some other way to verify the password), it wouldn’t know if I got it right or not — so how would it know to unlock itself? — This is why he tried changing the board on the drive — if the password/drive lockage was stored on the hdd’s board, simply swapping it out would be enough — which he did — and which was not enough — so the data telling the controller that the hard drive is locked (and any corresponding verification data) was being stored on the disk platters themselves.

  3. Am I mistaken to assume that the information (fingerprint and password) is stored in the bios or similar? So replacing the scanner would have also been enough?

    Very interesting read. Thanks for the presentation @dop3j0e

  4. ColinB, if you read the linked blogpost at you see that this is sort of a misunderstanding. In the post it says “How do you access the disk if your fingerprint scanner dies?” which would actually be a problem when not knowing the HDD password anymore.
    hackaday seems to have misread this, the fingerprint scanner was obviously still working and used to sniff the password.

  5. I’m guessing he wanted to recover the password while the fingerprint scanner still worked. Because he had forgotten the password, and this would be fatal should his fingerprint scanner break.

  6. To answer some of the questions that have been asked:

    The fingerprint readers on Lenovo laptops store your password locally in the reader itself. The passwords are encrypted, and when the proper fingerprint is read, it can submit the appropriate password to whichever component is asking for it.

    BIOS and HDD passwords can be stored this way, as can Windows passwords.

    When the reader dies, your passwords go along with it. Since the hard drive was password protected, the only way to get at the data (within reason) is sniffing the bus for the password like @dop3j0e did. Swapping it into another computer unfortunately won’t do a thing – that’s how ATA master passwords work.

    It’s the same principle behind the HDD locking mechanisms in the original Xbox. You either needed a mod chip or softmod to extract the password from the drive. Simply connecting your drive to a PC or another Xbox would do nothing.

    1. The password obviously was being sent to the HDD as he was able to sniff it. Using your original Xbox analogy, it would seem that once the drive receives that info the PATA cable could be swapped to another machine without removing power from the drive. A common ground between the two machines is also needed. This is a working method for exploiting the original XBox HDD locking as well

  7. This is a thinkly veiled advertisement (with referral link) for the OpenBench device. Faced with the same problem, I would have pulled the data off the drive while the fingerprint scanner still worked and then replaced the drive. Unless you are a broke college student it or someone looking for a challege, it is not worth the time to sniff a password to a $50 HD.

  8. @ColinB @VV — The article is a little misleading there; my FP reader never broke. Had it been broken, I would have had no way of recovering my password.

    @Mike Nathan — Right you are, thanks for the detailed explanation.

  9. @Elias,

    Ah, I obviously misread. He did indeed forget the password (and thus could not change it), but he wanted to recover it before the reader died. That’s what I get for writing articles late at night.

    So yes, the reader was working, he swiped his finger and sniffed the bus to recover it.

  10. I think it is possible to get the password from the HDD. Since the HDD stores the PWD on the platter itself, the controller needs to be able to read the PWD from the platter to compare with the PWD provided through the ATA bus. So, in theory, if you sniff the bytes read by the controller from the platter during the UNLOCK command one should be able to see what the password is. However, if the controller stores the data encrypted on the platter, it becomes very complex.
    What do you guys think?

  11. @Chris H, you are totally right. I found an original Xbox while dumpster diving with a busted DVD drive. I pulled it apart and used the cable swapping method you mention in order to circumvent the HDD lock, which enabled me to softmod it.

  12. @veneficus

    More likely the drive platters only store a hash of the password. That way, even if you have physical access to the data, you can’t recover the password.

    Hashes work by exploiting mathematical formulas that are incredibly easy to calculate one way, but impossible to do it the other way around, so you may have a function “hash(password)” that returns a hash string, but making a function “password(hash)” would be impossible.

    All you could do is brute force it by generating billions and billions of passwords and calculating their hashes to see if one of them matches, but that can be thwarted by employing a secret “salt” that is added on by the hardware, which changes the password and the resulting hash slightly.

  13. @Dax: Hashes doesn’t make me worry that much as long as they use a standard hashing algorithm. There are pre-calculated hash databases around called Rainbow Tables. It is very easy to reverse the password if it is found in the rainbow table, granted that it is not salted.

    I am more curious to learn how different manufacturers store the PWD on the platter. Do they store the HASH? is it clear text? Can someone reverse engineer the firmware on the controller? Is it possible to access to the controller’s memory? What if someone flashes the firmware with one that doesn’t care about the set PWD?

  14. @veneficus: Rainbow tables only have the hashes that were generated, thus usually mostly dictionary based and short pw’s.
    Having every possible combination with standard chars and numbers, upper and lower case, spaces and no spaces etc. takes immense amount of disc space when hashed with every possible hashing algorithm.
    That is why with proper passwords rainbow tables are not very useful.
    Most people would only have a fraction of the HDD space required to store the table so some massive cloud service would be required.

  15. @veneficus: I am definitely no expert, but my understanding is that the whole point of the concept of “salting” the password (even with a perfectly public “salt” – but not a constant one, ie. no “rand()=4”) is to render rainbow tables useless.

    As long as there’s no salt being used, a specific password will always have the same specific hash, so it makes sense to spend horrible amounts of time calculating these huge collections of hashes of all possible passwords called rainbow tables, because they will work again and again in different systems you are trying to crack (as long as the used hash algo is the same, which it tends to be). You just look up the hash you have, and it gives you the password.

    However, if you “salt” your password before hashing it by altering it somehow with an (even public – it may well be stored in plain view alongside the hash value) salt, now you’d have to have a separate set of rainbow tables (already huge) for EVERY SINGLE VALUE your salt can take. That would mean not 1, but 256 sets of rainbow tables for even a 8-bit salt. Which is just unfeasible in practice. And actual salts are quite longer these days, so the number would be astronomical.

    An added advantage is that you can’t tell if the same password is used in different places simply by comparing hashes (as long as the salts used were different).

  16. @Max adding hash doesn’t make rainbow tables useless, it just forces you to use a larger rainbow table.
    PAWS: secret
    SALT: salty

    what you look for in the rainbow table: “saltysecret” or “secretsalty”.
    Once you find the “long” password, it should be trivial to figure out which part is the password and which part if the salt.

    Now granted, there are some hash’s that are designed to take a salt, but many of them simply concatenate them salt and password, then perform the hash.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.