800+ IT
News
als RSS Feed abonnieren📚 Hard Disk Firmware Hacking (Part 4)
💡 Newskategorie: Video
🔗 Quelle: malwaretech.com
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.
After poking around, i found it was reading some code into memory from somewhere, which I assumed to be 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.
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
...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
 |
| 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