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”→
In their monthly announcement, among all the cool things Pine64, they talked about the open firmware for PinePhone’s LTE modem. The firmware isn’t fully open – a few parts remain closed. And Pine emphasizes that they neither pre-install nor officially endorse this firmware, and PinePhones will keep shipping with the vendor-supplied modem firmware image instead.
That said, the new firmware is way more featureful – it has less bugs, more features, decreased power consumption, and its proprietary parts are few and far between. I’d like to note that, with a special build of this firmware, the PinePhone’s modem can run Doom – because, well, of course.
And with all that, it’s become way easier to install this firmware – there’s fwupd hooks now! You can think of fwupd as the equivalent of Windows Update for firmware, except not abusive, and aimed at Linux. A perfect fit for keeping your open-source devices as functional as they can be, in other words.
[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?
This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.
[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.
It’s amazing to see how much technology is packed into even the “simple” devices that we take for granted in modern life. Case in point, the third party Xbox controller that [wrongbaud] recently decided to tear into. Not knowing what to expect when he cracked open its crimson red case, inside he found an ARM Cortex microcontroller and a perfect excuse to play around with Serial Wire Debug (SWD).
Though even figuring out that much took a bit of work. As is depressingly common, all the interesting components on the controller’s PCB were locked away behind a black epoxy blob. He had no idea what chip was powering the controller, much less that debugging protocols it might support. But after poking around the board with his multimeter, he eventually found a few test points sitting at 3.3 V which he thought was likely some kind of a programming header. After observing that pulling the line labelled “RES” low reset the controller, he was fairly sure he’d stumbled upon a functional JTAG or SWD connection.
The Serial Wire Debug architecture.
As [wrongbaud] explains in his detailed blog post, SWD is something of a JTAG successor that’s commonly used by ARM hardware. Using just two wires (data and clock), SWD provides hardware debugging capabilities on pin constrained platforms. It allows you to step through instructions, read and write to memory, even dump the firmware and flash something new.
For the rest of the post, [wrongbaud] walks the reader through working with an SWD target. From compiling the latest version of OpenOCD and wiring an FTDI adapter to the port, all the way to navigating through the firmware and unlocking the chip so you can upload your own code.
To prove he’s completely conquered the microcontroller, he ends the post by modifying the USB descriptor strings in the firmware to change what it says when the controller is plugged into the computer. From here, it won’t take much more to get some controller macros like rapid fire implemented; a topic we imagine he’ll be covering in the future.
Just a bonus hack in honor of my new toy: a 1GB 1TB buffalo Terastation NAS. These puppies run embedded Linux, and have a decent user base. Mine came with 128MB of ram, four Samsung drives (each with their own IDE bus), RAID support, gigabit ethernet, USB 2.0 and a Motorola Sandpoint cpu. (Putting it on par with my old Powermac 8500) The wiki has instructions for all the the basic hacks. Installing some hacked firmware was pretty easy, and yielded telnet and root access. It has a serial port for UPS control, but there’s a nice clean hack for enabling serial console access instead.
