Hard Disk Firmware Hacking (Final)

Core 2, I choose you.

Less than 5 minutes after posting the last article, i discovered the final piece of my puzzle: a second CPU core. I was looking through my OpenOCD configuration when I realized it had a single tap definition hardcoded, so i decided to comment it out and let OpenOCD try to automatically discover the taps. 
Auto probing found two TAPs with the same id, which I assumed to be two different cores, so I updated my config accordingly. 
Here’s a new config designed to work with both cores:

transport select jtag
adapter_khz 100

jtag newtap auto0 tap -irlen 4 -expected-id 0x121003d3
jtag newtap auto1 tap -irlen 4 -expected-id 0x121003d3

target create auto0.tap feroceon -endian little -chain-position auto0.tap
target create auto1.tap feroceon -endian little -chain-position auto1.tap

reset_config srst_only
adapter_nsrst_delay 200
jtag_ntrst_delay 200

After a few small adjustments, all that was left to do was run OpenOCD and see what secrets the new core holds.
Once I’d connected to the JTAG via IDA, everything was clear. I could see that the second core was stopped on the breakpoint I’d written to the flash chip. This was the core responsible for loading and executing the bootloader, whilst the core I had been looking at before just waits in a loop. Obviously the bootstrap code must be different for core 2, because the other bootstrap just loops until a later time. 
It’s clear that core 1’s bootstrap is just debugging / management code, whilst core 2 has a completely separate region of code mapped to the same address. Core 2 not only loads the bootloader from the flash, but also appears responsible for most of the interesting operations such as handling SATA requests and writing the cache descriptor.


So there you have it, using very little experience I was able to JTAG a WD hard disk, dump the firmware, and even discover how to read / write the flash chip using ICP. I’m definitely going to spend some more time poking about in the firmware to see how parts of it work, but because that’s outside the scope of these articles, and to avoid boring people, this will be the last article of the series. If I manage anything interesting, I will likely post my findings in a whitepaper and upload it alongside a demo video. 
I’d like to continue posting both hardware and software articles (and some tutorial), so if you have any suggestions for either, send them to admin@malwaretech.com. 
Hope you’ve enjoyed a slightly different style of writing and learned something new.