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 [email protected] 
Hope you’ve enjoyed a slightly different style of writing and learned something new.
Why Open Source Ransomware is Such a Problem

A while back 2sec4u posted a poll asking if people considered open source ransomware helpful to detection and prevention, with 46% voting yes. Although the poll wasn’t limited to people working in the antimalware industry, 46% is scarily high. Trying to prove a point, help me out Twitter. Is open source ransomware helping …

Mapping Mirai: A Botnet Case Study

Mirai is a piece of malware designed to hijack busybox systems (commonly used on IoT devices) in order to perform DDoS attacks, it’s also the bot used in the 620 Gbps DDoS attack on Brian Kreb’s blog and the 1.1 Tbps attack on OVH a few days later. Although Mirai isn’t even close to …

Dridex Returns to the UK With Updated TTPs

With the exception of a few unconfirmed reports of Dridex targeting Baltic countries (which doesn’t make much sense economically), infection campaigns have ceased since mid August when Dridex briefly resumed spreading to propagate multiple new botnets aimed at Switzerland. This morning a friend of mine, Liam, reported receiving a malicious email which unusually didn’t …