Trojans Can Lurk Inside AVR Bootloaders

If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside, it could be carrying a virus. Research by one group focused on hiding a trojan inside an AVR Arduino bootloader, proving even our little hobbyist microcontrollers aren’t safe.

The specific aim of the research was to hide a trojan inside the bootloader of an AVR chip itself. This would allow the trojan to remain present on something like a 3D printer even if the main firmware itself was reinstalled. The trojan would still be able to have an effect on the printer’s performance from its dastardly hiding place, but would be more difficult to notice and remove.

The target of the work was the ATmega328P, commonly used in 3D printers, in particular those using the Marlin firmware. For the full technical details, you can dive in and read the research paper for yourself. In basic terms, though, the modified bootloader was able to use the chip’s IVSEL register to allow bootloader execution after boot via interrupt. When an interrupt is called, execution passes to the trojan-infected bootloader’s special code, before then returning to the program’s own interrupt to avoid raising suspicion. The trojan can also execute after the program’s interrupt code too, increasing the flexibility of the attack.

Simply reflashing a program to an affected chip won’t flush out the trojan. The chip instead must have its bootloader specifically rewritten a clean version to remove the offending code.

It’s not a super dangerous hack, overall. Typically, flashing a malicious bootloader would require physical access to the chip. Furthermore, there’s not heaps to be gained by sneaking code onto the average 3D printer out there. However, it’s nonetheless a good example of what bootloaders can really do, and a reminder of what we should all be careful of when operating in security-conscious domains. Stay safe out there!

52 thoughts on “Trojans Can Lurk Inside AVR Bootloaders

      1. Not trivial for an Arduino or similar, their USB interface is over a UART adapter chip, so you aren’t accessing the raw USB pins.

        Also, the 328p doesn’t have a native USB interface. There are libraries to allow emulating a USB device, but IIRC they require clocks different from the “standard” Arduino 8MHz and 16MHz, which would lead to significantly (audibly and visually noticeable) different performance from the 3D printer. But again, that’s if the 328p had its pins wired directly to the USB pins, which it doesn’t on the vast majority of 328p products.

    1. A number of the 32bit 3d printer boards don’t interface to USB natively. Instead, they rely on a USB to serial bridge chip (like a CH340) to do the conversion. No room there for USB attacks if all there is at the end of the USB connection is a serial converter.

      OTOH some control boards do handle USB natively – those would be more exposed.

    1. Low end printers aren’t going to be compromised but high-end ones /could/ be using the same pull-down resistor chip method that became suspect in the Supermicro debacle. That is some NSA-level shit, so it’s unlikely for anyone not intending to print ICBM rocket engines.

        1. I have my doubts with that use case. How should a 3d printer with something with the performance of a 328p or similar recognize ghost gun parts? Those things are essentially motor controllers with g code interpreters and some nice extra features.

        2. It doesn’t work that way though. The gcode file that tells the printer how to print just tells it very basic instructions like “move the x axis this far while moving the extruder this amount”. Open an unknown gcode file in Notepad and see if you can figure out what the final print will be.

  1. Hobbyist microcontrollers are insecure by design so as to not impede the hobbyists, so I don’t see what all the hubbub is about. The point of using open or off-the-shelf hardware is to make the hardware accessible to amateurs.

    What’s the real world benefit of taking control of some random hobbyist 3d printers? Unwanted lewd prints in at odd hours of the morning? Who in the world would exploit this, and for what gain?

    Too much of security articles these days focus on rare and niche cases for exploit to scare the general public. I personally don’t care if the surface of attack requires that I make stupid decisions to expose non public information about myself. Every day I find more reasons that I should shut off my internet access and return to reading books, and reading material like this article does nothing to abate that sensation.

    1. The Microchip ATMega328p is definitively NOT a hobbyist microcontroller, as well as the rest of the ATMega-, Tiny- and the late SAM Series. Those MCU families have existed long before arduino started. I think one of the main reasons why it got popular in many open source hardware projects is the availability of a free / lowcost Toolchain and IDE solution.

      Just because specific hardware does not require you to buy compiler licences and SDKs for several thousand dollars does not automatically classify it as “amateur hardware”.

      I think the main reason for this article is to sensitize people for the possibility, that your new stock hardware could get delivered to you with unwanted firmware extensions – which is a universal problem when using preinstalled / precompiled software. It’s not fair to blame the a standard hardware design for that. But people also do not expect their electric toothbrush to be operated by a signed, encrypted firmware on a PSA Level 3 certified chip, right?

      Kind Regards

      1. But people also do not expect their electric toothbrush to be operated by a signed, encrypted firmware on a PSA Level 3 certified chip, right?

        I would expect my electric toothbrush to use a masked ROM but only because it’s so simple. Get a Bluetooth toothbrush and any semblance of security goes out the window.

          1. Statistics? 🤷‍♂️ Some medical/fitness applications may be able to log how long you brush your teeth? Or maybe it has a built-in speaker for music playback, dunno ? 😀 I mean, XXX toys with Bluetooth do exist, too, don’t they? To upload new “moves”? 🤣

    2. “What’s the real world benefit of taking control of some random hobbyist 3d printers?”

      That’s entirely not the problem here. The target is the computer connected to the printer.

      1. “The target is the computer ” – yes, that would be the more interesting case. But that isn’t what this paper was about. It was very much “how to attack the prints made by the printer.”

    3. No, I think the main problem is the USB stack, both in silicon and in the OS. It originally was designed to interface trustworthy peripherals and has no concept to defend itself from the dark side of the force, hi.

      Personally, I think that Thunderbolt is much worse. It’s an external version of PCIe 1x, without any safety mechanisms. It allows DMA (USB3+ does too), for example, which technically grants total access to the address space of the PC’s main memory.

      Personally, I think that old FireWire (aka i.LINK aka 1394) could have done better, maybe, all in all. It was simply more mature and had a relationship to ethernet.

  2. With a quick skim, it seems like this is more of a “back door” than a “Trojan” – they haven’t figured out a way of replacing the bootloader with a compromised bootloader; they’ve just figured out a way for a compromised bootloader to affect 3d printing. Since most people don’t replace their bootloader, and since the bootloader can’t be replaced without some significant effort, it seems like a bit of a stretch.
    Using IVSEL to intercept application interrupts is clever, but I think also easily undone by the application.

    1. Yeah, mitigation is very easy. It’s sort of a clever idea, but not really a “risk”, as for replacing the bootloader, you could upload a special firmware that replaces the bootloader and then upload the normal firmware after that. No need for really special effort in other hardware tools or anything.

  3. You could use it to interfere with the operation of one axis of the machine just enough to encode a serial number into all prints made with the 3D printer, just enough to show up on forensic inspection but otherwise not noticable. A bit like the yellow dot codes on color printers.

  4. This is the same principe as what we (at my former employer) did use on a 8051 based remote io. We got tired of changing eproms after a software change at our customers (worldwide). So the eprom had only the “boot” code and the the “appl” code was downloaded from the “operating application” at its initializing stage, which did run on a DOS pc. The 8051 uses different memory maps for code and ram (both 64k) with the same address. By mappng the upper 32k of CodeMem and DataMem to the same SRAM you chould (needed) to download the “appl” code.
    For communication we are using (our) “multi master” implementaion of RS485 (375 kBps 9,N,1) the transfere speed was about 15 kbyte per second.
    This did happen in 1991/1992 and was in production for over 20 years, there are stil a few hundred machines running at the moment.

  5. And what do we learn from this (aka moral of the story)?
    Exactly! Do safer information exchange! Use traditional serial ports like EIA-232 (PC) or RS-422 (Mac) for a serial connection!
    Give USB no chance! 😎

    1. Macs haven’t had native RS-422 for…

      (flips through calendar)

      … 24 years and 1 month when the iMac replaced all I/O except Ethernet with USB.

      And while some PCs still have RS-232 like ports, they’re not common to be brought out to an external connector and rarely fully compliant to the spec.

    2. What makes those protocols safer than UART?
      Did you read the article? The Trojan isn’t on the FTDI or CHM UART-USB IC, just the AVR. As far as the AVR is aware, it IS on an RS-232 port. The AVR is unaware of USB.

      Reading is a great way to become less ignorant.

  6. “If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside, it could be carrying a virus.”

    Nope! Not this time! Can’t do that with a 555!

  7. maybe not so useful to do on an atmega. but think about all the wifi connected iot devices. you could flash a bootloader onto a bunch of WiFi chips before they are sent to a manufacturer to be baked into products. the main application works as expected so nobody is suspicious, and then the user connects it to their wifi themselves. boom, big botnet achieved

  8. I guess it’s way too much to hope for that people would actually READ the paper in question, or at least the full HaD article, before jumping to conclusions about what they think it must have said? Sheesh!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.