Planet Arduino

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!

We’ve been big fans of the Arduboy since [Kevin Bates] showed off the first prototype back in 2014. It’s a fantastic platform for making and playing simple games, but there’s certainly room for improvement. One of the most obvious usability issues has always been that the hardware can only hold one game at a time. But thanks to the development of an official add-on, the Arduboy will soon have enough onboard storage to hold hundreds of games

The upgrade takes the form of a small flexible PCB that gets soldered to existing test points on the Arduboy. Equipped with a W25Q128 flash chip, the retrofit board provides an additional 16 MB of flash storage to the handheld’s ATmega32u4 microcontroller; enough to hold essentially every game and program ever written for the platform at once.

Of course, wiring an SPI flash chip to the handheld’s MCU is only half the battle. The system also needs to have its bootloader replaced with one that’s aware of this expanded storage. To that end, the upgrade board also contains an ATtiny85 that’s there to handle this process without the need for an external programmer. While this is a luxury the average Hackaday reader could probably do without, it’s a smart move for an upgrade intended for a wider audience.

The upgrade board is currently available for pre-order, but those who know their way around a soldering iron and a USBasp can upgrade their own hardware right now by following along with the technical discussion between [Kevin] and the community in the “Project Falcon” forum. In fact, the particularly astute reader may notice that this official upgrade has its roots in the community-developed Arduboy cartridge we covered last year.

Security is something that’s far too often overlooked in embedded devices. One of the main risks is that if the device doesn’t verify the authenticity of incoming firmware updates. [Walter Schreppers] was working on a USB password storage device, so security was paramount. Thus, it was necessary to develop a secure bootloader.

[Walter]’s device was based upon the Arduino Leonardo. Starting with the Caterina bootloader, modifications were made to enable the device to be locked and unlocked for programming. This can be done in a variety of ways, depending on how things are setup. Unlocking can be by using a secret serial string, an onboard jumper, and [Walter] even suspects a SHA1 challenge/response could be used if you were so inclined.

It’s never too soon to start thinking about security in your projects. After all, we must stave off the cyberpunk future in which leather-clad youths flick all your lights on and off before burning your house down in the night by overclocking the water heater. Naturally, we’ve got a primer to get you going in the right direction. Happy hacking!

There’s a school of thought that says that to fully understand something, you need to build it yourself. OK, we’re not sure it’s really a school of thought, but that describes a heck of a lot of projects around these parts.

[Tim] aka [mitxela] wrote kiloboot partly because he wanted an Ethernet-capable Trivial File Transfer Protocol (TFTP) bootloader for an ATMega-powered project, and partly because he wanted to understand the Internet. See, if you’re writing a bootloader, you’ve got a limited amount of space and no device drivers or libraries of any kind to fall back on, so you’re going to learn your topic of choice the hard way.

[Tim]’s writeup of the odyssey of cramming so much into 1,000 bytes of code is fantastic. While explaining the Internet takes significantly more space than the Ethernet-capable bootloader itself, we’d wager that you’ll enjoy the compressed overview of UDP, IP, TFTP, and AVR bootloader wizardry as much as we did. And yes, at the end of the day, you’ve also got an Internet-flashable Arduino, which is just what the doctor ordered if you’re building a simple wired IoT device and you get tired of running down to the basement to upload new firmware.

Oh, and in case you hadn’t noticed, cramming an Ethernet bootloader into 1 kB is amazing. If doing big things in small codespaces floats your boat, check out the winners from our own 1kB challenge.

Speaking of bootloaders, if you’re building an I2C slave device out of an ATtiny85¸ you’ll want to check out this bootloader that runs on the tiny chip.

A few months back we first brought word of the progress being made in unlocking the SMART Response XE, an ATmega128RFA powered handheld computer that allowed teachers to create an interactive curriculum in the days before all the kids got Chromebooks. Featuring 2.4 Ghz wireless communication, a 384×160 LCD, and a full QWERTY keyboard, schools paid around $100 each for them 2010. Now selling for as little as $5 on eBay, these Arduino-compatible devices only need a little coaxing and an external programmer to get your own code running.

The previous post inspired [Larry Bank] to try his hand at hacking the SMART Response XE, and so far he’s made some very impressive progress. Not only has he come up with his own support library, but he’s also created a way to upload Arduino code to the devices through their integrated 802.15.4 radio. With his setup, you no longer need to open the SMART Response XE and attach a programmer, making it much easier to test and deploy software.

[Larry] has written up a very detailed account of his development process, and goes through the trouble of including his ideas that didn’t work. Getting reliable communication between two of these classroom gadgets proved a bit tricky, and it took a bit of circling around until he hit on a protocol that worked.

The trick is that you need to use one SMART Response XE attached to your computer as a “hub” to upload code to other XEs. But given how cheap they are this isn’t that big of a deal, especially considering the boost in productivity it will net you. [Larry] added a 5 x 2 female header to his “hub” XE so he could close the device back up, and also added a physical power switch. In the video after the break, you can see a demonstration of the setup sending a simple program to a nearby XE.

Between this wireless bootloader and the Arduboy compatibility covered previously, we’d suggest you get your SMART Response XE now. We wouldn’t be surprised if the prices of these things start going up like they did with the IM-ME.

An Arduino and a data radio can make a great remote sensor node. Often in such situations, the hardware ends up installed somewhere hard to get to – be it in a light fitting, behind a wall, or secreted somewhere outdoors. Not places that you’d want to squeeze a cable repeatedly into while debugging.

[2BitOrNot2Bit] decided this simply wouldn’t do, and decided to program the Arduinos over the air instead.

Using the NRF24L01 chip with the Arduino is a popular choice to add wireless communications to a small project. By installing one of these radios on both the remote hardware and a local Arduino connected to the programming computer, it’s possible to remotely flash the Arduino without any physical contact whatsoever using Optiboot.

The writeup is comprehensive and covers both the required hardware setup for both ends of the operation as well as how to install the relevant bootloaders. If you’re already using the NRF24L01 in your projects, this could be the ideal solution to your programming woes. Perhaps you’re using a different platform though – like an Arduino on WiFi? Don’t worry – you can do OTA updates that way, too.

There was a time, not so long ago, when all the cool kids were dual-booting their computers: one side running Linux for hacking and another running Windows for gaming. We know, we were there. But why the heck would you ever want to dual-boot an Arduino? We’re still scratching our heads about the application, but we know a cool hack when we see one; [Vinod] soldered the tiny surface-mount EEPROM on top of the already small AVR chip! (Check the video below.)

Aside from tiny-soldering skills, [Vinod] wrote his own custom bootloader for the AVR-based Arduino. With just enough memory to back up the AVR’s flash, the bootloader can shuffle the existing program out to the EEPROM while flashing the new program in. For more details, read the source.

While you might think that writing a bootloader is deep juju (it can be), [Vinod]’s simple bootloader application is written in C, using a style that should be familiar to anyone who has done work with an Arduino. It could certainly be optimized for size, but probably not for readability (and tweakability).

Why would you ever want to dual boot an Arduino? Maybe to be able to run testing and stable code on the same device? You could do the same thing over WiFi with an ESP8266. But maybe you don’t have WiFi available? Whatever, we like the hack and ‘because you can’ is a good enough excuse for us. If you do have a use in mind, post up in the comments!

In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!

[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.

Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.

The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.

The modified version of the Optiboot bootloader is available on [Majek]’s Github.  If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.

Thanks [Koepel] for the tip!

While newer Arduinos and Arduino compatibles (including the Hackaday.io Trinket Pro. Superliminal Advertising!) either have a chip capable of USB or rely on a V-USB implementation, the old fogies of the Arduino world, the Uno and Mega, actually have two chips. An ATMega16u2 takes care of the USB connection, while the standard ‘328 or ‘2560 takes care of all ~duino tasks. Wouldn’t it be great is you could also use the ’16u2 on the Uno or Mega for some additional functionality to your Arduino sketch? That’s now a reality. [Nico] has been working on the HoodLoader2 for a while now, and the current version give you the option of reprogramming the ’16u2 with custom sketches, and use seven I/O pins on this previously overlooked chip.

Unlike the previous HoodLoader, this version is a real bootloader for the ’16u2 that replaces the DFU bootloader with a CDC bootloader and USB serial function. This allows for new USB functions like HID keyboard, mouse, media keys, and a gamepad, the addition of extra sensors or LEDs, and anything else you can do with a normal ‘duino.

Setup is simple enough, only requiring a connection between the ‘328 ISP header and the pins on the ’16u2 header. There are already a few samples of what this new firmware for the ’16u2 can do over on [Nico]’s blog, but we’ll expect the number of example projects using this new bootloader to explode over the coming months. If you’re ever in an Arduino Demoscene contest with an Arduino and you’re looking for more pins and code space, now you know where to look.

A lot of people have used ESP8266 to add inexpensive WiFi connectivity to their projects, but [Oscar] decided to take it one step further and program an Arduino over WiFi with the ESP8266. [Oscar] wrote a server script in Python that communicates with firmware running on the Arduino. The Arduino connects to the server on startup and listens for a “reboot” command.

When the command is received, the processor resets and enters the bootloader. The python script begins streaming a hex file over WiFi to the ESP8226, which relays it to the Arduino’s bootloader. Once the hex file is streamed, the microcontroller seamlessly starts executing the firmware. This method can be used with any AVR running a stk500-compatible bootloader.

[Oscar]‘s writeup is in Spanish, but fortunately the comments in his Python and Arduino code are in English. Check out the video (in English) after the break where [Oscar] demonstrates his bootloading setup.