Cracking the WD Passport INIC-3608: A Firmware Reverse Engineering Journey

• Target: Western Digital My Passport WDBXH5000ASL-03
• Objective: Recover data from a drive with a forgotten password using the Initio INIC-3608 bridge.

1. The Challenge

We started with a locked Western Digital My Passport (model WDBXH5000ASL-03). The password was forgotten, so the hardware-encrypted data was inaccessible. Our aim was to bypass authentication or recover the KEK directly from the bridge.

2. Reconnaissance

We identified the USB-to-SATA bridge that handles encryption. USB descriptors confirmed the Initio INIC-3608.

We relied on Got HW crypto? On the (in)security of a Self-Encrypting Drive series and wdpassport-utils. That work noted a likely backdoor Vendor Specific Command (VSC) to access the KEK but omitted the opcode.

3. Fuzzing the Bridge

Expecting a hidden command, we fuzzed the bridge. Opcode 0x3C (standard SCSI read buffer op) was the breakthrough: instead of a rejection, it returned data that looked like code. Further review showed we were receiving pieces of the bridge firmware. The dumping code is in dump_fw.py. We used mode 01 (unsupported mode):

sg_raw -r 512 /dev/sdb 3c 01 01 00 XX 00 00 02 00 00

4. Firmware Extraction and Reverse Engineering in Ghidra

We dumped the full firmware via the 0x3C vulnerability.

Platform notes:

• Architecture: ARC 600 (Argonaut RISC Core)
• Tooling: ARC processor extension for Ghidra for correct disassembly

There is a pull request for ARC compact support: NationalSecurityAgency/ghidra#3006. With the firmware loaded, we mapped the SCSI dispatcher:

• 0x2544 – Main loop handling USB events and handing off to SCSI logic
• 0x9C1C – SCSI dispatcher switching opcodes to handlers
• 0x0E54 – SCSI C1 handler (unlock, set password, remove password); it compares the user hash with the KEK in RAM via memcmp
• 0x8B60 – SCSI 3C read-buffer handler; contains the undocumented VSC that leaks memory: sudo sg_raw -r 4096 /dev/sdb 3c 01 00 03 00 XX 00 10 00 00 25 c9. We dumped the memory with dump_mem.py.

5. The Exploit

The memory dump exposed a plaintext KEK at 0x68.

We used it successfully; see unlock.py. With the KEK, we sent a valid 0xC1 0xE1 unlock command. The bridge accepted the key, decrypted the path, and the volume mounted.

6. Status: UNLOCKED. 🔓