GoKawiilSome time last year I was working on an exploit for the Xbox 360 console (which would later turn into the much anticipated softmod) and found myself in need of a way to modify the firmware for a HDD to try and exploit a race condition. This sent me down a rabbit hole of trying to modify the firmware for a few different brands of HDDs and SSDs I had on hand. In this series of blog posts I’ll cover all the work I did including: dumping and analyzing the firmware, live debugging a HDD via JTAG, modifying the drive firmware, and how I used AI to help with analysis and identifying an unknown MCU architecture.
This first post is going to focus on dumping, analyzing, and modifying HDD firmware. Everything in this post was done without the help of AI. In the next post I’ll cover how I used AI to do similar work on other HDDs/SSDs as well as using it to do black box reverse engineering on an unknown ISA, and giving Claude access to debug my hard drive.
Background
The bug I was trying to exploit was a race condition that occurs when the console is reading data from the HDD. I needed a certain amount of time between when the read request was issued and when the drive replied in order for my exploit to trigger successfully. At the time I didn’t quite understand all the variables at play and was having difficulty exploiting the race condition in the time it took the HDD to respond. One of my initial ideas was to modify the HDD firmware to introduce a delay of a few hundred milliseconds when a specific sector is read from the drive, which would give enough time for the exploit to trigger successfully.
Over the years I had read a few posts/articles about modifying HDD firmware but nothing I could pick up and run with. Regardless, I knew this concept wasn’t new and I just needed to find a drive that was easy to start messing with. At this point in time I just needed one HDD I could use to finish developing the Xbox 360 exploit and then I’d worry about trying to expand the firmware modifications to other makes and models. As it would later turn out I found other ways to dial in my race condition attack and ended up not needing to modify the HDD firmware at all.
The idea of modifying the firmware on a HDD/SSD is very interesting to me especially from attacker and pen-testing points of view. However, I’ve never cared to venture down this rabbit hole until now because embedded devices are typically very complex under the hood and massive time-sucks to reverse engineer. Do you know how a hard drive works? At a high level sure, discs spin at high speed, magnets pull data off them, but do you really understand how they work at a micro-controller level?
I had no idea how a hard drive worked internally but I knew I had found another bug where failure to exploit it was not an option I was willing to accept. If the only thing standing in my way of exploiting this bug was a hard drive then this hard drive was going down.
The Test Subjects
For this exploit I just needed any HDD or SSD I could easily obtain, modify, and reflash the firmware on. However, I was primarily focused on the brands of HDDs that were used for the Xbox 360 as anyone using the exploit would most likely already have one on hand. I also grabbed some Western Digital drives as I knew from some past endeavors that they have some backdoor vendor commands which could be used to get low level access to them. And lastly I grabbed a couple Samsung SSDs as I had a few of these on hand. Here are the brave test subjects that would (hopefully) survive whatever experiments I was about to do to them:
Here are the makes and models for anyone interested:
... continue reading