Welcome To The Future, Where Your Microwave Thinks It’s A Steam Oven

It’s fair to say that many of us will have at some time inadvertently bricked a device by applying the wrong firmware by mistake. If we’re lucky then firing up some low-level reflashing tools can save the day and return the item in question to health, but we’re guessing that among you will be plenty of people who’ve had to discard a PCB or replace an inaccessible microcontroller chip as a result.

Spare a thought then for the consumer appliance manufacturer Electrolux, whose AEG subsidiary has bricked combi microwave ovens acrosss a swathe of Western Europe (Dutch, Google Translate link). They managed this improbable feat by distributing an over-the-air update that contains the firmware for a steam oven instead. Worse still, the update has disabled over-the-air updates, meaning that any fix requires physical access to the oven.

We can’t help sympathising with whichever poor AEG engineer has had the ultimate in bad days at work, but at the same time we should perhaps consider the difference between a computer and an appliance, and whether there should be a need for an oven to phone home in the first place. Sure, such devices have been computer-controlled for decades, but should a microcontroller doing a control task need constant updates?

We’re guessing this oven has some kind of cloud aspect to it which allows AEG to slurp customer data the user to control it via their app, but even so it should serve as a warning to anyone tempted by an internet-connected kitchen appliance. If the internet isn’t necessary for the food to be cooked, don’t connect it.

We feel sorry for anyone who might have put a pizza in the oven just before it was bricked, and watched in disappointment as their tasty meal remained uncooked.

ESP32 board with battery and nearby antenna

How To Easily Set Up Secure OTA Firmware Updates On ESP32

After an electronic IoT device has been deployed into the world, it may be necessary to reprogram or update it. But if physical access to the device (or devices) is troublesome or no longer possible, that’s a problem.

OTA updates allow a device to download new firmware, install it, and reboot itself into the new version. Convenient? Yes. Secure? It definitely needs to be.

Fortunately, over-the-air (OTA) firmware updates are a thing, allowing embedded devices to be reprogrammed over their wireless data connection instead of with a physical hardware device. Security is of course a concern, and thankfully [Refik] explains how to set up a basic framework so that ESP32 OTA updates can happen securely, allowing one to deploy devices and still push OTA updates in confidence.

[Refik] begins by setting up a web server using Ubuntu Linux, and sets up HTTPS using a free SSL certificate from Let’s Encrypt, but a self-signed SSL certificate is also an option. Once that is done, the necessary fundamentals are in place to support deploying OTA updates in a secure manner. A bit more configuration, and the rest is up to the IoT devices themselves. [Refik] explains how to set things up using the esp32FOTA library, but we’ve also seen other ways to make OTA simple to use.

You can watch a simple secure OTA firmware update happen in the video, embedded below. There are a lot of different pieces working together, so [Refik] also provides a second video for those viewers who prefer a walkthrough to help make everything clear. Watch them both, after the break.

Continue reading “How To Easily Set Up Secure OTA Firmware Updates On ESP32”

Even More Firmware In Your Firmware

There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.

Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.

The system thirsty for an update

Continue reading “Even More Firmware In Your Firmware”

Putting The Firmware In Your Firmware

Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.

There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.

The system de jour

Continue reading “Putting The Firmware In Your Firmware”

Chris Conlon: Device Security 101

We all wring our hands over the security (or lack thereof!) of our myriad smart devices. If you haven’t had your home network hacked through your toaster, or baby cam, you’re missing out on the zeitgeist. But it doesn’t have to be this way — smart devices can be designed with security in mind, and [Chris Conlon] came to Pasadena to give us a talk on the basics.

He starts off the talk with three broad conceptual realms of data security: data in transit, data at rest on the device, and the firmware and how it’s updated. A common thread underlying all of this is cryptography, and he devotes the last section of his  talk to getting that right. So if you’d like a whirlwind tour of device security, watch on!

Continue reading “Chris Conlon: Device Security 101”

[Sprite_TM]’s Keyboard Plays Snake

Hackaday Prize judge, hacker extraordinaire, and generally awesome dude [Sprite_TM] spends a lot of time at his computer, and that means a lot of time typing on his keyboard. He recently picked up a board with the latest fad in the world of keyboards, a board with individually addressable LEDs. He took this board to work and a colleague jokingly said, ‘You’ve had this keyboard for 24 hours now, and it has a bunch of LEDs and some arrow keys. I’m disappointed you haven’t got Snake running on it yet.” Thus began the quest to put the one game found on all Nokia phones on a keyboard.

The keyboard in question is a Coolermaster Quickfire Rapid-I, a board that’s marketed as having an ARM Cortex CPU. Pulling apart the board, [Sprite] found a bunch of MX Browns, some LEDs, and a 72MHz ARM Cortex-M3 with 127k of Flash and 32k of RAM. That’s an incredible amount of processing power for a keyboard, and after finding the SWD port, [Sprite] attempted to dump the Flash. The security bit was set. There was another way, however.

Coolermaster is actively working on the firmware, killing bugs, adding lighting modes, and putting all these updates on their website. The firmware updater is distributed as an executable with US and EU versions; the EU version has another key. Figuring the only difference between these versions would be the firmware itself, [Sprite] got his hands on both versions, did a binary diff, and found only one 16k block of data at the end of the file was different. There’s the firmware. It was XOR encrypted, but that’s obvious if you know what to look for.

flashdata The firmware wasn’t complete, though; there were jumps to places outside the code [Sprite] had and a large block looked corrupted. There’s another thing you can do with an executable file: run it. With USBPcap running in the background while executing the firmware updater, [Sprite] could read exactly what was happening when the keyboard was updating. With a small executable that gets around the weirdness of the updater, [Sprite] had a backup copy of the keyboard’s firmware. Even if he bricked the keyboard, he could always bring it back to a stock state. It was time to program Snake.

The first part of writing new firmware was finding a place that had some Flash and RAM to store the new code. This wasn’t hard; there was 64k of Flash free and 28K of unused RAM. The calls to the Snake routine were modified from the variables the original firmware had. If, for example, the original keyboard had a call to change the PWM, [Sprite] could change that to the Snake routine.

Snake is fun, but with a huge, powerful ARM in a device that people will just plug into their keyboard, there’s a lot more you can do with a hacked keyboard. Keyloggers and a BadUSB are extremely possible, especially with firmware that can be updated from a computer. To counter that, [Sprite] added the requirement for a physical condition in order to enter Flash mode. Now, the firmware will only update for about 10 seconds after pressing the fn+f key combination.

There’s more to playing Snake on a keyboard; Sprite has also written a new lighting mode, a fluid simulation thingy that will surely annoy anyone who can’t touch type. You can see the videos of that below.

Continue reading “[Sprite_TM]’s Keyboard Plays Snake”

Reverse Engineering A Korg Monotribe

Yesterday, Korg released a firmware update to their ribbon controller synth, the Monotribe. The firmware is just an audio file that needs to be played to the sync input of the box. [gravitronic] thought this was rather interesting, so he decided to decode the monotribe firmware. It’s the first step to custom Monotribe firmware, and on the path towards reverse engineering this neat box.

After converting the firmware update to a .wav, [gravitronic] looked at the file with a hex editor and found that each sample is two bytes, and the left and right channels are the same. That made enough sense, so after getting rid of one channel, he sent it through Python to take a look at the patterns of ones and zeros.

Of course, [gravitronic] arbitrarily chose high = 1, low = 0, and little-endianness. The first result didn’t produce a nice “KORG SYSTEM FILE” in the header, so he tried other combinations until the output file looked reasonable. The result is the actual .bin file that’s going to serve as the basis for a nice homebrew firmware. You can grab [gravitronic]’s Python script here and decode your own firmware.