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
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
SOCIAL SHARE CARD GENERATOR