Scooter hacking is wonderful – you get to create a better scooter from a pre-made scooter platform, and sometimes you can do that purely through firmware modifications. Typically, hackers have been uploading firmware using Bluetooth OTA methods, and at some point, we’ve seen the always-popular Xiaomi scooters starting to get locked down. Today, we see [Daljeet Nandha] from [RoboCoffee] continue the research of the new Xiaomi scooter realities, where he finds that SWD flashing is way more of a viable avenue that we might’ve expected. Continue reading “Xiaomi Scooter Firmware Hacking Gets Hands-On”→
[Daljeet Nandha] from [RoboCoffee] writes to us, sharing his research on cryptographic signature-based firmware authenticity checks recently added to the Xiaomi Mi scooter firmware. Those scooters use an OTA firmware update mechanism over BLE, so you can update your scooter using nothing but a smartphone app – great because you can easily get all the good new features, but suboptimal because you can easily get all the bad new features. As an owner of a Mi 1S scooter but a hacker first and foremost, [Daljeet] set up a HTTPS proxy and captured the firmware files that the app downloaded from Xiaomi servers, dug into them, and summarized what he found.
Confirming this update will indefinitely lock you out of any third-party OTA updates
Unlike many of the security measures we’ve seen lacking-by-design, this one secures the OTA firmware updates with what we would consider the industry standard – SHA256 hash with elliptic cryptography-backed signing. As soon as the first firmware version implementing signature checks is flashed into your scooter, it won’t accept anything except further firmware binaries that come with Xiaomi’s digital signature. Unless a flaw is found in the signature checking implementation, the “flash a custom firmware with a smartphone app” route no longer seems to be a viable pathway for modding your scooter in ways Xiaomi doesn’t approve of.
Having disassembled the code currently available, [Daljeet] tells us about all of this – and more. In his extensive writeup, he shares scripts he used on his exploration journey, so that any sufficiently motivated hacker can follow in his footsteps, and we highly recommend you take a look at everything he’s shared. He also gives further insights, explaining some constraints of the OTA update process and pointing out a few security-related assumptions made by Xiaomi, worth checking for bypassing the security implemented. Then, he points out the firmware filenames hinting that, in the future, the ESC (Electronic Speed Control, responsible for driving the motors) board firmware might be encrypted with the same kind of elliptic curve cryptography, and finds a few update hooks in the decompiled code that could enable exactly that in future firmware releases.
One could argue that these scooters are typically modified to remove speed limits, installed there because of legal limitations in a variety of countries. However, the legal speed limits are more nuanced than a hard upper boundary, and if the hardware is capable of doing 35km/h, you shouldn’t be at mercy of Xiaomi to be able to use your scooter to its full extent where considerate. It would be fair to assert, however, that Xiaomi did this because they don’t want to have their reputation be anywhere near “maker of scooters that people can modify to break laws with”, and therefore we can’t expect them to be forthcoming.
Creality, makers of the Ender series of 3D printers, have released a product called Wi-Fi Box meant to cheaply add network control to your printer. Naturally I had to order one so we could take a peek, but this is certainly not a product review. If you’re looking to control your 3D printer over the network, get yourself a Raspberry Pi and install Gina Häußge’s phenomenal OctoPrint on it. Despite what Creality might want you to believe, their product is little more than a poor imitation of this incredible open source project.
Even if you manage to get it working with your printer, which judging by early indications is a pretty big if, it won’t give you anywhere near the same experience. At best it’ll save you a few dollars compared to going the DIY route, but at the cost of missing out on the vibrant community of plugin developers that have helped establish OctoPrint as the defacto remote 3D printing solution.
That being said, the hardware itself seems pretty interesting. For just $20 USD you get a palm-sized Linux computer with WiFi, Ethernet, a micro SD slot, and a pair of USB ports; all wrapped up in a fairly rugged enclosure. There’s no video output, but that will hardly scare off the veteran penguin wrangler. Tucked in a corner and sipping down only a few watts, one can imagine plenty of tasks this little gadget would be well suited to. Perhaps it could act as a small MQTT broker for all your smart home devices, or a low-power remote weather station. The possibilities are nearly limitless, assuming we can get into the thing anyway.
So what’s inside the Creality Wi-Fi Box, and how hard will it be to bend it to our will? Let’s take one apart and find out.
You wake up on a Sunday, roll out of bed, and make your way to the centerpiece of your morning, the magical device that helps you start your day: the coffee machine. You open the companion app, because everything has an app in 2020, and select a large latte with extra froth. As you switch open a browser to check Hackaday, the machine beeps. Then the built-in grinder cranks up to 100, the milk frother begins to whir, and the machine starts spraying water. Frantic, you look at the display for an error code and instead see a message instructing you to send $75 to a bitcoin wallet, lest your $300 machine become a doorstop.
Outlandish though it may seem, this has become quite a real possibility, as [Martin Hron] at the Avast Threat Labs demonstrates. In fact, he could probably make your modern macchiato machine do this without setting foot in your house (so long as it comes with a built-in ESP8266, like his did).
Building on others’ work that identified the simple commands that control the machine over it’s WiFi connection (nothing says “brew me a nice cup o’ joe” like 0x37), [Martin] reverse-engineered the Smarter Coffee companion app to extract and reverse engineer its firmware. He was actually able to find the entire firmware image packaged within the app- relatively uncommon in the world of Over-The-Air (OTA) updates, but convenient in this case. Using Interactive Disassembler (IDA) to sift through the firmware’s inner workings, he identified the functions that handle all basic operations, including displaying images on the screen, controlling the heating elements, and of course, beeping. From there, he modified the stock firmware image to include some malicious commands and ran an OTA update.
The mind-boggling part here is that not only was the firmware transmitted as unencrypted plaintext over unsecured WiFi, but the machine didn’t even require a user to confirm the update with a button press. With one quick reboot, the trap was set. The machine operated normally, while waiting for “Order 66,” causing it to turn all the heating elements on, spool up the built-in grinder, and beep. Constantly.
While a broken coffee machine seems relatively innocuous, there are some pretty significant lapses in hardware/firmware security here that, while avoidable, almost seem unnecessary in the first place. It makes us wonder- why does Mr. Coffee need a smartphone in the first place?
Near-field Communication (NFC) has been around a while and is used for example in access control, small data exchange, and of course in mobile payment systems. With such sensitive application areas, security is naturally a crucial element of the protocol, and therefore any lower-level access is usually heavily restricted and guarded.
This hardware is especially well-guarded in phones, and rooting your Android device won’t be of much help here. Well, that was of course only until [Christopher Wade] took a deep look into that subject, which he presented in his NFC firmware hacking talk at for this year’s DEF CON.
To recap: [Christopher] took a rooted Samsung S6 and searched for vulnerabilities in the NFC chip’s safe firmware update process, in hopes to run a custom firmware image on it. Obviously, this wouldn’t be worth mentioning twice if he hadn’t succeeded, and he goes at serious length into describing how he got there. Picking a brain like his by reading up on the process he went through — from reverse engineering the firmware to actually exploiting a weakness that let him run his own code — is always fascinating and downright fun. And if you’re someone who prefers the code to do the talking, the exploits are on GitHub.
Naturally, [Christopher] disclosed his findings to Samsung, but the exploited vulnerability — and therefore the ability to reproduce this — has of course been out there for a long time already. Sure, you can use a Proxmark device to attack NFC, or the hardware we saw a few DEF CONs back, but a regular-looking phone will certainly raise a lot less suspicion at the checkout counter, and might open whole new possibilities for penetration testers. But then again, sometimes a regular app will be enough, as we’ve seen in this NFC vending machine hack.
This deep dive into the Linux-powered Reolink B800 IP camera started because of a broken promise from its manufacturer. When [George Hilliard] purchased a kit that included six of the cameras and a video recorder, the website said they were capable of outputting standard RTSP video. But once he took delivery of the goods, and naturally after his return window had closed, the site was updated to say that the cameras can only function with the included recorder.
Taking that as something of challenge, [George] got to work. His first big break came when he desoldered the camera’s SPI flash chip and replaced it with a socket. That allowed him to easily take the chip out of the device for reading and flashing as he tinkered with modifying the firmware. After adding cross-compiled versions of busybox, gdb, and strace to the extracted firmware, he bundled it back up and flashed it back to the hardware.
If you think that’s the end of the story, it isn’t. In fact, it’s just the beginning. While getting root-level access to the camera’s OS would have potentially allowed for [George] to dump all the proprietary software it was running and replace it with open alternatives, he decided to take a different approach.
Instead of replacing the camera’s original software, he used his newly granted root powers to analyze it and figure out how it worked. This allowed for to sniff out some very suspect “encryption” routines built into the software, and eventually write his own server side in Rust that finally allowed him to use the cameras with his own server…albeit with a bit more work than he bargained for.
Projects like these are a fantastic look at real world reverse engineering, and a reminder that sometimes achieving your ultimate goal means taking the long way around. Even if you’re not in the market for a hacked security camera, there’s no doubt that reading the thorough write-up [George] has prepared will teach you a few things. But of course, we’d expect no less from a guy who runs Linux on his business card.
Retro gaming is huge right now, and like probably millions of other people, [wrongbaud] found himself taking possession of a couple faux-classic gaming gadgets over the holidays. But unlike most people, who are now using said devices to replay games from their youth, he decided to tear into his new toys to see how they work.
The first to get pulled apart is a handheld The Oregon Trail game, which Hackaday readers may recall from a teardown we did back when it was first released. His work continues right where our teardown left off, by pulling the game’s two EEPROM chips out and dumping their contents. As expected, [wrongbaud] found that the I2C connected chip contained the game save information, and the SPI flash chip stored the actual game files.
Next up was an HDMI “stick” from Bandai Namco that allows the user to play a selection of NES games. Here again [wrongbaud] liberates the flash chip and dumps it for examination, this time using an ESP32 tool of his own creation. Inside the firmware image he’s able to identify several elements with the help of binwalk, such as splash screen graphics and text strings.
But perhaps most interestingly, he found that binwalk was able to automatically extract the NES ROMs themselves. After verifying they were standard ROMs with an NES emulator, he theorizes that repacking the firmware with different ROMs should be possible should anyone feel so inclined.
Both of these hacks are fantastic examples of how you can reverse engineer a device’s firmware with low cost hardware, open source tools, and a healthy dose of patience. Even if you aren’t interested in fiddling with The Oregon Trail or swapping out the Mappy ROM for Contra, this write-up is an invaluable resource for anyone looking to do their own firmware analysis.
