Flash Glitching to Recovery Bootloaders

Occasionally, one comes across an interesting attack which is beautiful in both it’s simplicity and effectiveness. Earlier this week, I read a post around glitching Flash chips to get to recovery bootloaders (unfortunately, I didn’t save the link), and earlier today I reproduced the attack successfully.

The theory of this attack is rather simple: the purpose of a recovery bootloader is to allow a technicians to repair a device in a “bricked” state: for example, when a key component fails. If we simulate this behaviour, we get to the recovery bootloader.

My experiment was against a donated NetComm N300 wireless router. I started by taking apart the device, looking for the Flash memory chip in use:

This is on the underside of the PCB, where the UART and JTAG interfaces are also reachable. This Flash chip was a Macronix MX15L12835FMI – I proceeded to review the data sheet, to identify the pin out:

To simulate data corruption, I would temporarily ground pin 8 during the boot process, effectively causing data read operations to return incorrect data. The timing for this could be leeched from pin 16 (or really, 15), making this particular attack 100% reliable.

With this plan of attack, I wired up a transistor to the Flash circuit:

I then build a quick-and-dirty platform to demo the attack.

 always @(posedge youre_not_the_boss_of_me_in) # SCLK (or SI?)
   ctr <= ctr + 1;
   if (ctr == 3'b100)
     ctr <= 0;
     glitch_status <= 2'b10; 
   if (glitch_status > 0) begin
   glitch_r <= 1'b1;
   glitch_status <= glitch_status - 1;
   end else begin
   glitch_r <= 1'b0;

As you can see, I opted for the “wide net” approach, figuring that if I put glitches all over the slave out line, the kernel would surely be corrupted. My intial attempts met with failure, with the device not producing any output on the UART interface, and indicating an error state via it’s front LED’s (disabling all but two, then turning them off).

I hypothesized that this was due to the fault being injected too early into the Flash chip: that is, the device simply figured it wasn’t worth booting, instead of trying to read Flash and getting corrupted data. I quickly added a manual toggle switch, which I could hit while the device was booting, and was met with success:

From here, we’re able to dump (and modify!) the Jboot bootloader itself, otherwise inaccessible from the operating system:

The ability to write memory and jump to memory is both available – while there is no POC at the time of writing, this is clearly enough to compromise the bootloader and load whatever you want – in theory (with some effort, i.e. more than rewriting the Flash chip in this case), bypassing whatever controls the OS loads later.

You can download the final code used for the project here.

Note that in this particular example, all this is moot – you can enter the recovery bootloader by simply sending a newline during the boot process. Poor choice of target, but all I had at the time.

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s