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

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 …