Preface
This post documents the journey of extracting data from a locked hard drive, including the various detours I took along the way.
I previously bought an NTG55 head unit and installed it in a Mercedes-Benz E-Class.
After opening the target device, you can see an automotive-grade HDD.
The drive specifications are as follows: MQ01AAD032C Serial ATA 2.6 / ATA8 3.0 Gbit/s , 1.5 Gbit/s 320 GB
The image below compares the HDD from an older head unit (right) with the newer one (left). “New” here refers to the NTG5.5 generation, though the technology has since advanced to NTG7.
Exploration
This HDD complies with the SATA 2.6 standard. When I first connected it via a USB SATA enclosure, it failed to mount, leading me to suspect it had been damaged during shipping. In reality, this automotive-grade drive is surprisingly robust—it survived multiple impacts without issue.
Later, I connected it directly to a desktop PC. Upon booting, the BIOS reported that the drive was password-protected. I attempted various default and common passwords, but none were successful.
In Linux, I queried the drive information for two different models; the Security section reported locked for both.
$ sudo hdparm -I /dev/sdb
# Toshiba
ATA device, with non-removable media
Model Number: TOSHIBA MQ01AAD032C
Serial Number: 46NHP01LT
Firmware Revision: AK001Y
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
Supported: 8 7 6 5
Likely used: 8
Security:
Master password revision code = 7
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level high
116min for SECURITY ERASE UNIT. 116min for ENHANCED SECURITY ERASE UNIT.
# Hitachi
ATA device, with non-removable media
Model Number: HGST HEJ423232H9E300
Serial Number: F63001FNJ7W93L
Firmware Revision: F6BOA200
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b
Security:
Master password revision code = 7
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level high
104min for SECURITY ERASE UNIT. 106min for ENHANCED SECURITY ERASE UNIT.
At the time, lacking a hardware background, I found this task extremely daunting. I even reached out to data recovery companies, but none were able to assist.
Online information was scarce, and I couldn’t find practical resources on unlocking SATA drives. While some techniques exist for sniffing IDE signals to recover passwords, this drive uses the SATA interface.
Reference: Open Sesame: Harddrive Password Hacking with a OpenBench Logic Sniffer
I considered sniffing the SATA bus, but the high speeds involved made it impractical. Implementing a sniffer with an FPGA would have been too costly in terms of both time and money, so I abandoned that approach.
Reference:
Hard disk data recovery technology SATA interface implementation technology (I)
I disassembled the HDD to identify its key components:
MCU：88i8317-RAI2
DDR：Winbond 4MB
Flash：MXIC MX25V4006EZNI 512K
HDD Motor Combo IC: TLS2605
Subsequently, I desoldered the internal Flash chip and dumped the firmware. Since the BIOS allows unlocking via keyboard input, I hypothesized the password might be stored as a plain string, but I failed to find any suspicious text. (As it turned out, the password consists of non-ASCII bytes.) I proceeded to dump the firmware from two Hitachi drives for comparison. If the security mechanism relied on a unique per-device password and a simple comparison check, recovery might have been possible. (In reality, the password is identical across devices.)
Although the firmware consists of ARM instructions, my skills in embedded reverse engineering were limited at the time, and I had no prior experience with HDD firmware source code, so I hit a wall.
I attempted to locate a debug interface. I had seen others debug HDD firmware via JTAG to bypass authentication, but no public documentation existed for this MCU. Lacking a JTAGulator, I was forced to abandon this path as well.
References:
Hard Disk Firmware Hacking (Part 1)
Hard Disk Firmware Hacking (Part 2)
Another viable strategy is to allow the head unit to unlock the drive, and then—without powering down—transfer the drive to a PC. The unlock key remains active in the HDD’s RAM, granting direct access. I only discovered this technique after I had already succeeded in unlocking it.
Reference: Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)
I reviewed the ATA/SATA 2.6 specification but found no details regarding an unlock password, leading me to suspect it was a vendor-specific feature of the drive controller. A deeper dive into the HDD documentation finally revealed relevant information.
The password is 32 bytes long. My analysis of the bootloader revealed no relevant keys aside from the SD card key.
The 0xF2 command serves as a promising entry point for reverse engineering. It is useful whether you are dynamically debugging the MCU via JTAG or analyzing the HDD driver.
Decryption process
The head unit’s bootloader generally does not perform the HDD unlock. Rather, after the bootloader decrypts the WinCE image, the ATA driver sends the 0xF2 command to unlock the drive. (This implies that the HDD contents are not critical for the initial boot process.)
Since the system image was already decrypted, I analyzed the driver files directly.
The raw passwords are listed below. A search revealed that someone had already recovered them using a logic analyzer back in 2014. (Note: NTG4 uses an IDE interface). NTG4 und NTG4.5 Festplatte Einsehen, Clonen, Ändern
MELCO SANDA NTG55HUH Navi Master
MELCO SANDA NTG55HUH Navi User
The decoding logic is straightforward. (At the time, I simplified the process by emulating the code. Upon closer inspection, Hex-Rays F5 decompiler output was slightly inaccurate; the actual assembly for the transcoding is only 4 lines.)
for b in 'MELCO SANDA NTG55HUH Navi Master':
print(hex(0xff-ord(b)), end=" ")
print()
Note: MELCO refers to Mitsubishi Electric, and SANDA refers to Mita Manufacturing. The HU55 is manufactured by Mitsubishi Electric. They are extremely meticulous—even minor security issues can trigger late-night emergency meetings. Consequently, this device employs bootloader encryption, an SD card lock, an HDD lock, and a self-destruct-style secure boot mechanism.
Next, use these commands to unlock the HDD:
# MASTER PASS
sudo hdparm --user-master m --security-unlock $(printf '\xb2\xba\xb3\xbc\xb0\xdf\xac\xbe\xb1\xbb\xbe\xdf\xb1\xab\xb8\xca\xca\xb7\xaa\xb7\xdf\xb1\x9e\x89\x96\xdf\xb2\x9e\x8c\x8b\x9a\x8d') /dev/sdb
# USER PASS
sudo hdparm --user-master u --security-unlock $(printf '\xb2\xba\xb3\xbc\xb0\xdf\xac\xbe\xb1\xbb\xbe\xdf\xb1\xab\xb8\xca\xca\xb7\xaa\xb7\xdf\xb1\x9e\x89\x96\xdf\xaa\x8c\x9a\x8d\xdf\xdf') /dev/sdb
Upon executing these commands, the partitions became visible. They contained map data. Since the older device had limited performance, it likely used redundant map data to optimize speed. In the newer NTG65, the HDD was replaced by a high-capacity eMMC, rendering such a large mechanical drive unnecessary.
Disk /dev/sdb: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Disk model: TOSHIBA MQ01AAD0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x17192a08
Device Boot Start End Sectors Size Id Type
/dev/sdb1 36864 31494143 31457280 15G c W95 FAT32 (LBA)
/dev/sdb2 31494144 195071999 163577856 78G c W95 FAT32 (LBA)
/dev/sdb3 195072000 358649855 163577856 78G c W95 FAT32 (LBA)
/dev/sdb4 358649856 625137344 266487489 127.1G f W95 Ext'd (LBA)
/dev/sdb5 358651904 503355391 144703488 69G b W95 FAT32
/dev/sdb6 503357440 545300479 41943040 20G b W95 FAT32
/dev/sdb7 545302528 576759807 31457280 15G b W95 FAT32
/dev/sdb8 576761856 578207743 1445888 706M b W95 FAT32
/dev/sdb9 578209792 592889855 14680064 7G b W95 FAT32
/dev/sdb10 592891904 597086207 4194304 2G b W95 FAT32
/dev/sdb11 597088256 603379711 6291456 3G b W95 FAT32
/dev/sdb12 603381760 609673215 6291456 3G b W95 FAT32
/dev/sdb13 609675264 625135615 15460352 7.4G b W95 FAT32
Related links
Open Sesame: Harddrive Password Hacking with a OpenBench Logic Sniffer
Toshiba_2.5_disk_product_specification.pdf
SerialATA_Revision_2_6_Gold.pdf
Hard Disk Firmware Hacking (Part 1)
Hard Disk Firmware Hacking (Part 2)
Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)
NTG4 und NTG4.5 Festplatte Einsehen, Clonen, Ändern
Geek Notes: SATA protocol analysis (Part 1)
Geek Notes: SATA protocol analysis (Part 2)
Geek Notes: SATA protocol analysis (Part 3)
CC BY-NC-SA 4.0