Hard Disk Firmware Hacking (Part 4)

It seems that the bootstrap code is just scattered around various memory addresses and there’s no simple way to dump all of it, so i decided to just dump a chunk of memory from 0x00000000 and look for any reference to addresses outside of that chunk (allowing me to build up a basic map of the code).

Although the exact addresses vary between disk models, my layout should give you a good idea where to look.

  • 0x00000000 – 0x0000A520
  • 0x0000EA24 – 0x00014F74
  • 0xFFE19E00 – 0xFFE34D9A
  • 0xFFFF2800 – 0xFFFF2800

After poking around, i found it was reading some code into memory from somewhere, which I assumed to be the flash.

First few bytes of the flash

The flash starts with a table which spans from 0 to 0x120 (the start of the first block), each table entry is 32 bytes and follows the same format (see: image). Each block has an id from 1 to n, with the exception of the first block which is always 0x5A.

The block at 0x5A is some kind of bootloader which likely reads and decompresses the rest of the blocks from flash, but I’m not sure yet as it’s proving a problem to reverse. I wanted to intercept this bootloader at the entry point, which sounds easy, it’s not.

  • At some point during the bootstrap process my hardware breakpoints stop working, it could be that the processor is overwriting the register, remapping memory, or disabling them all together; but I’ve not found the issue yet. This means I can’t simply set a breakpoint on the bootloader entry point (0x19000).
  • The bootstrap code responsible for loading and executing the bootloader is in ROM, so I can’t set software breakpoints either.
  • Watchpoints don’t seem to work at all, even before my breakpoints stop working I can’t get the code to break on any memory access.
  • Most of the code that isn’t in ROM is using some kind of paging (aka overlaying), which reads certain regions of code into memory when they’re needed, then replaces them when they’re not, preventing the use of software breakpoints.
All in all, this was proving to be must more of a pain than I expected so I decided the easiest option would be to buy a drive with an external EEPROM chip, instead of one built into the MCU. This way I could write software breakpoints directly to the flash chip with an EEPROM programmer.

 Hardware and firmware wise this disk is pretty much identical, except the firmware is now stored in a 256k SPI flash chip, instead of in the MCU’s internal memory. The first thing I did was use a multimeter to see if there’s anywhere on the top of the PCB i could connect to the flash chip (so I didn’t have to desolder it or keep unscrewing the PCB from the disk).

WP# and HOLD# are shorted to VCC, so they’re not a problem and the rest of the required pins are brought out to the test pads around E11. I tried connecting my TUMPA’s SPI interface to the test pads and using the flashrom software, but it was unable to detect the chip. I’m not sure if this is because my TUMPA isn’t capable of in-circuit programming, or there is other stuff on the same data lines, but it I simply couldn’t get it to work.

My new plan is to get a SOIC clip, a decent EEPROM programmer, and a desoldering station for if neither of the other option work; In the mean time I will be trying to find out what’s stopping my breakpoints from working and see if i can remedy that. I’ll probably not have another update until all my stuff gets delivered and I have a few days to try it all out.

Part 5 (Writing the flash): http://www.malwaretech.com/2015/05/hard-disk-firmware-hacking-part-5.html

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 …