Right after unboxing my w530 and changing some settings in the firmware setup menus, before even booting from the hard drive I wanted to clone the preloaded closed source operating system to an old 100GB. I do not want a dual boot box, but a backup of the virgin preloaded system might come handy in the future - e.g. if I decide to pass on the box some day to someone else...
The brand new w530 did not accept the hard disk password I have found on a sticky note attached to the old 100GB sata disk. This disk I have found lying around, it has not been touched for the last 4-5 years - maybe more. I inherited it from a colleague, and to my knowledge at that time I verified the password on the sticky note was working.
I wanted to get the drive working and ready for use - preferably also to check the contents before wiping it. In order to do so, I wanted to collect information about the disk I could use to find out why the password is not working. Based on the SMART self test and error logs, I could have found out how long ago the drive was actively used. Even if I cannot recover the password, I should be able to set a new password - which would mean losing all the contents, but at least having a functional hard disk. More information on ATA passwords and security: https://en.wikipedia.org/wiki/AT_Attachment#HDD_passwords_and_security.
The tool hdparm is a great tool to collect detailed information about the problematic hard disk, and it is also able to issue ATA security commands, such as unlock, secure-erase or change both user and master passwords...
Unfortunately, if this disk is attached, and your password is not accepted after 5 attempts, the system shuts down - it does not give you any chance to boot from a livecd or usb and tinker with hdparm.
My first idea was booting a livecd, then hot-plugging the SATA disk - this would definitely work with a hard disk bay (undock the optical drive, and dock the hard disk bay) but I do not have a bay that is compatible with w530. I tried hot-plugging into the internal slot for the primary hard disk, but that did not work - after attaching the disk, I ran dmesg, but it did not show any event or activity related.
Nevertheless, I do have a hard disk bay compatible with my old t60p, so I booted quickly and investigated how I could safely unplug my optical drive and insert the drive bay with the problematic SATA disk.
$ for D in $(ls /sys/devices/platform/dock.?/type ); do echo $D; cat $D; done;
/sys/devices/platform/dock.0/type
dock_station
/sys/devices/platform/dock.1/type
battery_bay
/sys/devices/platform/dock.2/type
ata_bay
$ cat /sys/devices/platform/dock.2/docked # the output above shows dock.2 is the drive bay
1
$ echo 1 | sudo tee /sys/devices/platform/dock.2/undock
$ dmesg | tail # shows the optical drive was powered off and is safe to detach
sudo hdparm -I /dev/sdb | grep -A 10 Security
I quickly read https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase and tried to unlock the drive with using the provided password both as a user password and master password, without luck. I carried on with some brute-forcing until I exceeded the number of allowed attempts. This is indicated by the line ‘expired: security count’ in the output of the hdparm command listed above. Undocking and redocking the bay will give another handful of attempts, but this kind of bruteforcing is not very efficient...
From the output of hdparm I also found out the factory master password was not changed “Master password revision code = 65534” which is equal to 0xFFFE in hex. I quickly used google to find out the factory master password for hitachi disks, and multiple sites mentioned 32 spaces but somehow I was not able to unlock or even secure-erase the disk. (If maximum security mode is used - like in my case - the master password cannot be used to unlock a disk locked with a user password, but it should be able to secure erase the disk - however it did not work.)
I have found some information, that some buggy controllers or BIOSes mess up the password under circumstances, and if the 32 bytes dedicated to hold the hard disk password contain non-printable bytes then strange things will happen. Also, depending on the actual BIOS, you may or may not be able to set/input an empty password - especially, Lenovo is mentioned to be unable to unlock a disk locked with an empty password. (Hitting enter at the password prompt might mean no password or empty password as well... I guess this might be the root cause.)
It also became obvious at that point, that some BIOSes might not want to send/store the provided hard disk password to the disk, but might want to scramble/obfuscate/transform it first by design. While this is a reasonable decision from the security point of view, it clearly leads to interoperability problems - putting the same disk into another box and providing the same hard disk password will just not work unless the two boxes use the exact same (including none) scrambling algorithm.
This made me want to boot my old t60p with the hard disk bay inserted at power on time as opposed to hot-plugging it after boot. Magically, the hard disk password was recognized and accepted, and the disk unlocked. Although I could not change the security settings form within the operating system, as the ATA security configuration was frozen by the BIOS, I could easily remove the hard disk password from within the BIOS menu and confirm from within Linux that the change indeed happened. Problem solved.
No comments:
Post a Comment