Hard Disk Firmware Hacking (Part 1)
I’ve not been doing much in the windows malware world for a while now, because quite frankly I’ve run out of ideas and I’m totally bored. Recently I decided to take the jump into electronics / hardware hacking and people have suggested I post some of that here. A couple of years ago I started looking into BIOS rootkits (back before (U)EFI was mainstream). I was aware that most hardware had a BIOS type setup that is usually initialized during the POST phase of the boot process, so I was looking into the possibility of modifying firmware to work in the same way as a BIOS rootkit would. My two main candidates were the GPU and Hard Disk, which I began looking into (but was mostly sandbagged by my lack of reverse engineering knowledge at the time).
My current project is on hold while I await the arrival of some expensive hardware which will allow me to overcome a setback (the manufacture disabled the JTAG interface prior to shipping), so I decided to have a play with something I saw on spritesmods in 2013 (Hard disk hacking).
Hard Disk Hacking
The guy on spritesmods had dumped the firmware by de-soldering the flash chip and dumping it manually, the only problem is the red circle is were the flash chip should be (thanks obama). Above the red circle is a Marvell 88i8846-TFJ2 ARM processor which has internal flash. I don’t fancy my chances of de-soldering the entire CPU and trying to access the memory manually, so I decided to go for the JTAG method.
The header for the JTAG is fairly well known, though it can be upside down (in my case the first pin of the header is denoted by a ‘1’ on the board). Pins 6 to 11 are all we need for the JTAG and the metal circle, which is the ground.
As you can probably see, I’ve decided not to solder the pins. This is for two reasons: They’re rusty and they’re too close together, so I could easily short the board. Instead I opted to use the test pads, which can be found using the ‘continuity’ mode on the multimeter (thanks to @McGrewSecurity for the tip).
By setting this mode on the multimeter it will show us the resistance between two points, the ‘1’ means total resistance (the points likely aren’t even connected) and ‘0.01’ is a good connection. The meter will also emit and audible (and incredibly annoying) high pitch tone when the resistance is low, so we only really need to use the tone to tell if two points are connected.
With the hard drive disconnected simply put one of the multimeter probes on the header pin you want to locate the test pad for, then move the other probe around the test pads in the area where mine are until you hear a beep. On my board you’ll see there are visible data lines running from the header pins to the test pads, which gives you a good idea where to look (depending on the quality of your eyesight).
I didn’t want the hard drive plugged into my computers power supply in case something went wrong, and my computer is the opposite side of the room, so I didn’t want to try and build a 10m long SATA cable either. Here’s my solution (disclaimer: If you injure yourself blame someone else i.e. not me). If you have a spare PSU lying around, you can short the third and forth pin of the ATX header to turn it on without connecting it to a motherboard. My PSU was very old and missing a fan, so I was pleasantly surprised when nothing shorted or caught fire (My entire house is on the same circuit breaker, so I’d be spend the next hour rebooting various devices).
I use a $5 SATA to USB connector, which is perfect for the data side of the hard disk connection. The red board on the right is a $30 TIAO USB Multi-Protocol Adapter, which is FT2232H based and also does SPI as well as JTAG.
|I really need a bigger desk|
Here we have a stupidly over-complicated setup due to the fact my Windows desktop reside on the other side of the room: The iMac is running a Linux virtual machine for the JTAG software (FTDI driver and OpenOCD) because they’re a pain to install on Windows or OSX . The Windows system (left monitor) is running IDA for reversing/debugging (I plan on trying to connect IDA to the OpenOCD GDB service over my local network when I start doing live analysis).
Part 2 (Dumping the bootstrap): http://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-part-2.html