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.
Best Languages to Learn for Malware Analysis

One of the most common questions I’m asked is “what programming language(s) should I learn to get into malware analysis/reverse engineering”, to answer this question I’m going to write about the top 3 languages which I’ve personally found most useful. I’ll focus on native malware (malware which does not require …

Investigating Command and Control Infrastructure (Emotet)

Although the majority of botnets still use a basic client-server model, with most relying on HTTP servers to receive commands, many prominent threats now use more advanced infrastructure to evade endpoint blacklisting and be resilient to take-down. In this article I will go through and explain my process of identifying …

Creating a Simple Free Malware Analysis Environment

Computer Requirements: A CPU with AMD-V or Intel VT-x support (pretty much any modern CPU). 4 GB RAM (more is better). Make sure Virtualization (AMD-V or Intel VT-x) is enabled in the BIOS. To do this, you’ll need to google “enable virtualization” along with your bios or motherboard version, then …