Hard Disk Firmware Hacking (Part 2)

Now that everything is ready to be connected, power up the hard drive an run openocd with the following command: openocd -f interface/<your interface here>.cfg -f target/test.cfg

test.cfg should be the configuration for the CPU used by your hard disk controller, for most marvell CPUs this config should work. I’m not sure of the adapter_khz, so I’ve set mine to 100 (as long as this value is lower than the actual it should work).

If all went well, you should see something along the lines of the above. Now you can use telnet to connect to port 4444 and issue commands.

The Marvell chips used in hard disk controller aren’t publicly documented; so if you want to know information such as their memory map, you’ll have to sign a NDA and probably pay some money. Instead, what I’m going to do is try to figure out as much as I can from the firmware and possibly by probing the circuit.

Getting the firmware isn’t easy when you can’t de-solder and dump the flash, so we’ll have to work through the boot process. Most ARM CPUs begin executing at address 0xFFFF0000, this is known as the reset vector. If we dump 65536 bytes from this address, we’ll find the bootstrap code which will be a good starting point.

In order o dump memory, we first need to halt the CPU, which can be done with the command “reset halt” (It’s required that we first reset the system as we can’t halt past a certain stage). If the reset command doesn’t work for any reason e.g: RST pin of JTAG isn’t connected to anything, you’ll need to disconnect and reconnect the hard drive’s power source then quickly tap into the JTAG and issue the halt command within a few second. Memory dumped with the command “dump_image <file name> <address> <size>”.

When we disassemble the dumped image, it’s some fairly small (4 kb) ARM bootstrap code, which should lead us to the rest of the firmware. I’ve not had much time to look, so I’ll reverse the bootstrap code and post the next part when I’ve found the rest of the bootloader and kernel.

Part 3 (Bootstrap analysis): http://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-part-3.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 …