Saturday 5 July 2014

BootJacker: The Amazing AVR Bootloader Hack!

There's an old adage that says if you don't know it's impossible you could end up achieving it. BootJacker is that kind of hack: a way for ordinary firmware on an AVR to reprogram its bootloader. It's something Atmel's manual for AVR microcontrollers with Bootloaders says is impossible (Note the italics):

27.3.1 Application Section.
The Application section is the section of the Flash that is used for storing the application code. The protection level for the Application section can be selected by the application Boot Lock bits (Boot Lock bits 0), see Table 27-2 on page 284. The Application section can never store any Boot Loader code since the SPM instruction is disabled when executed from the Application section.

Here's the background: I'm the designer of FIGnition, the definitive DIY 8-bit computer. It's not cobbled together from hackware from around the web, instead three years of sweat and bare-metal development has gone into this tiny 8-bitter. I've been working on firmware version 1.0.0 for a few months; the culmination of claiming that I'll put audio data transfer on the machine (along with a fast, tiny Floating point library about 60% of the size of the AVR libc one).

Firmware 1.0.0 uses the space previously occupied by its 2Kb USB bootloader and so, needs its own migration firmware image to copy the V1.0.0 firmware to external flash. The last stage is to reprogram the bootloader with a tiny 128b bootloader which reads the new image from external flash. Just as I got to the last stage I came across section 27.3.1, which let me know in no uncertain terms that I was wasting my time.

I sat around dumbstruck for a while ("How could I have not read that?") before wondering whether[1], crazies of crazy, imagining that a solution to the impossible might actually lead me there. And it turns out it does.

The solution is actually conceptually fairly simple. A bootloader, by its very nature is designed to download new firmware to the device. Therefore it will contain at least one spm instruction. Because the spm configuration register must be written no more than 4 cycles before the spm instruction it means there are very few sequences that practically occur: just sts, spm or out, spm sequences. So, all you need to is find the sequence in the bootloader section; set up the right registers and call it.

However, it turned out there was a major problem with that too. The V-USB self-programming bootloader's spm instructions aren't a neat little routine, but are inlined into the main code; so calling it would just cause the AVR to crash as it tried to execute the rest of the V-USB bootloader.

Nasty, but again there's a solution. By using a timer clocked at the CPU frequency (which is easy on an AVR), you can create a routine in assembler which sets up the registers for the Bootloader's out, spm sequence; calls it and just at the moment when it's executed the first cycle of the spm itself, the timer interrupt goes off and the AVR should jump to your interrupt routine (in Application space). The interrupt routine pops the bootloader address and then returns to the previous code - which is the routine that sets up the outspm sequence. This should work, because when you apply spm instructions to the bootloader section the CPU is halted until it's complete.

Here's the key part of BootJacker:

The code uses the Bootloader's spm to first write a page of flash which also contains a usable outspm sequence and then uses that routine to write the rest (because of course you might end up overwriting the bootloader with your own new bootloader!)

BootJacker involves cycle counting, I used a test routine to figure out the actual number of instructions executed after you set the timer for x cycles in the future (it's x-2). In addition I found there was one other oddity: erase and writes always have a 1 cycle latency after the SPM in a bootloader. I fixed this with a nop instruction in my mini bootloader.

This algorithm, I think is pretty amazing. It means that most bootloaders can in fact be overwritten using application firmware containing a version of BootJacker!

[1] As a Christian, I also have to fess' up that I prayed about it too. Not some kind of desperation thing, but some pretty calm prayer, trusting it'll get sorted out :-) 

15 comments:

Snowcamo said...

[1] As a Christian, I also have to fess' up that I prayed about it too. Not some kind of desperation thing, but some pretty calm prayer, trusting it'll get sorted out :-)

This never fails, and has a habit of transforming impossible things into possible (Luke 1:37).

My most memorable case was a time critical piece of assembler 20 years ago, where I had to multiply a variable with a constant and there really was neither time nor fast multiply available. The constant was from a complex formula and when I finally got it calculated, it turned out to be 256.000xxxxxx. The precision was plenty enough.

Bubz said...

As an atheist, I must admit I don't believe prayer is what what made this awsome hack reality, but rather the unique skillset of a very talented hacker. I don't want to start any religious thing going, I just wanted to acknowledge how awesome this trick is.
I have had times when I needed to use a modified optiboot, as the braindead reset trickery to get to bootloader uses rts/dtr to do a hw reset, and optiboot makes this worse by ignoring soft reset. But by modifying the bootloader, you eliminate most casual Arduino users, as they would never get into that.
This is a very sweet trick, big ups!!!

Anonymous said...

reaction = current_mood ? yeah_sure : no_brainer;

ptdecker said...

Nice hack!

Snial said...

Hi guys,

Thanks for the comments! @Snowcamo - good one!

@Bubz, @quibelez, @ptdecker! Thanks for the encouragements and your takes on how insight comes about, it all comes into play! I wasn't trying to offer much in the way of theology, it's just the blogging equivalent of e.g. Daniel Sturridge giving thanks for his equaliser when playing against Italy :-)

Have a great week all of you: may your talents, moods and algorithmic precision bring you success!

-cheers from Julz

Ralf said...

You didn't need to do any of this to solve your original problem though!

There's a very straightforward serial programming interface (hold RESET low and program with pins PB1,PB2 and PB3. It's even documented in the manual! You can do a full chip erase and from there program any bootloader / application code you like.

Snial said...

Hi Ralf,

Yes, that's called an ICSP (or just ISP), an in-circuit serial programmer. I use a home-brew ICSP to program AVRs from scratch, but when I sell FIGnition computers, I can't expect them to have an ICSP so instead I provide a bootloader on the AVR so that users can upgrade their FIGnition firmware just using a FIGnition and no other hardware. This is the way arduinos are normally programmed, and if you mess up the bootloader there, you will brick your arduino!

Up until now I've used the excellent V-USB software USB bootloader from Objective Development. To provide complete flexibility without incurring USB licensing fees I've switched to audio data transfer and an audio bootloader. This means I really do need to supply a migration program which can update customer's bootloaders.

-cheers from Julz

witnessdigital said...

really cool, I was looking at fuse settings with the AVRdragon to make a self erasing application on AVR including the bootloader.. but this trick allows me to overwrite pretty much everything on the chip... Thanx
its a REALLY neat hack...

hzl

Matthijs Kooijman said...

Cool! Nicely thought outside the box :-)

Alex Dubois said...

Hi Julz,

Great post.

I am trying to do the opposite and be sure that my code cannot be modified via USB (which is my only interface for my keyboard).

Is this feasible with an AVR?

Do I have to make sure my code is free of any buffer overflow or other security related software bugs?

Alex

Snial said...

Hi Alex,

Thanks for the affirmation!

If you're using an AVR device and you can download application firmware updates via USB and the AVR chip has sufficient application flash and your hackers know what device they're trying to hack, then I'm afraid the technique in bootjacker will be able to jack your device.

Maybe I should head off to a Black hat conference or something ;-) But yes, it's a major failing because the major technique Atmel use to prevent inadvertent writes to Flash mean that it's easy to identify SPM sequences in flash - there are very few combinations and even code a little bit more complex than mine could identify them all.

The vulnerabilities recently identified in USB devices I think all depend on being able to program the internal firmware on the USB device via a device driver that runs on the host (or via, perhaps a device driver that's uploaded to the host, though I'm not aware of any USB device that does that). So, for example, the original EZ-USB devices by Cypress Semiconductor were exactly like that - they just have RAM for the firmware and can boot up in DFU (Device Firmware Upload?) mode which means they identify as one device on power-on whose only purpose is to upload new firmware. The TI TUSB3410 devices are similar (and both based on 8051 architectures).

I have an EZ-USB board of that kind and it's fantastic as a super-flexible arduino-type device.

USB devices that can't upload firmware, that just communicate via USB will be pretty resilient if implemented on an AVR. That's mostly because of the harvard architecture, you can't inject code by overflowing a buffer, because you can't execute from RAM on an AVR. To hi-jack it using buffer overflows you'd have to do something like sticking enough data in the buffer that it overwrites the stack with a return address to somewhere in your code that could directly or indirectly execute SPM instructions in a controlled manner. It's unlikely that any code sequences in your Flash can be exploited in this manner, even more unlikely if the hackers don't even know what's in the flash.

In that sense the AVR is pretty secure.

Hope this helps!

-cheers from Julz

Alex Dubois said...

Hi Julz,

Thanks for the info. Also my current undertanding of the various components is still a bit blur. So I am coming back with more question...

I am starting a project to build my own mechanical keyboard. I am at the moment aiming for the Atmel ATMEGA32U4 which has enough pins to drive my keyboard matrix.

I think that by reading your last paragraph, you are eluding that with this chip, using your technique to zap the bootloader and replace it by mine (which would not allow firmware update), I should be pretty safe. Correct?

Second point, could I still update my AVR via JTAG for example (I need the requirement to have physical attacks only, no logical possibility). Ideally having a PCB design which require a DIP switch to allow JTAG.

FYI, I am using QubesOS as my OS and feel pretty safe to protect my dev environment with it.

Unknown said...
This comment has been removed by the author.
WestfW said...

Does this end up working? It sounded great, but then I noticed that most of the Boot Lock bit protections have this clause "If Interrupt Vectors are placed in the Application section, interrupts are disabled while executing from the Boot Loader section."

Snial said...

Hi WestfW,

If the firmware programmer protects the flash using the Boot Lock bits, then I think yes, I think it would mean that the technique wouldn't work. However, the problem I faced when upgrading FIGnition to the 1.0 firmware on an AtMega168 was that even if the Boot Lock bits hadn't been programmed, it wasn't possible to program the bootloader from the application section. Using this technique, it was possible to upgrade the FIGnition bootloader from the application as described.

I hope this helps, cheers from Julz