The community often asks about the progress on hacks for the Ninebot Max. Since we recently made some good progress, I think it’s a good idea to centralize everything here to answer all of your concerns
We started working on the Ninebot Max as early as June, but a few obstacles were starting to show up. The first one being: we needed to acquire a copy of the original firmware to use as a base for custom firmware and for reverse-engineering research. My first approach was the same as for ESx scooters: I simply used an ESx dashboard spoofed as a Max, connected it to an ESx ESC that was spoofed to DRV001 and tried to fetch updates from the Ninebot app, which I would sniff using a proxy – since Ninebot had for habit to include firmware’s content in their JSON response. Surprisingly, that failed. The main reason being that there was no file pushed to their servers, so there was nothing to update. Recently, I also noticed that they changed the way their API works and that we can’t proceed like that anymore. The request might no longer be HTTP, and it wasn’t worth it to try and figure out their new protocol. So, I got to work on a new method to dump updates (which I won’t reveal here for obvious reasons), but that very method seems to do the job just fine, although it requires soldering to the dashboard. We’re still waiting on them to update the ESC to dump the firmware because that’s the only way we can get it – obviously. Even my new method requires them to push files.
When the Ninebot Max started rolling out worldwide, we had the hardware to work with. Unsurprisingly, it’s a mix of Xiaomi M365 and Ninebot hardware. The fact that the Ninebot Max was here in front of us gave us multiple opportunities to continue our research while the ESC firmware was dumped. We managed to dump the firmware of the dashboard (nRF51 chip, no read-out protection) which you can find on our files server. We disassembled the firmware (named BLE110) and it’s basically, as expected, more or less the same as the ESx one – with an annoying difference, but we’ll come back to that later. A couple of weeks after that, someone volunteered to dump their Max ESC, at the cost of bricking it. Since that ESC has an STM32F103 chip with ROP level 2, there was no way to dump it using conventional tools, so we had to write a very short “dump to UART” program that we would load as a Ninebot update and that iterates through each byte in ROM and print it to the Serial interface. The downside of that method is that you corrupt the first pages of the firmware part of the chip, which becomes unusable. The intact parts we got were: bootloader, app_config , upd_config. The only missing part is the firmware itself, which will be acquired with the method I described above. When the firmware is available, we will have a valid full dump file that can be used to flash the ESC using an ST-Link – useful in case of brick.
Ninebot attempts encryption
Since Ninebot was pretty much known to suck at securing their devices, they tried to fix that with their new scooter. Regrettable, because customization was a big aspect of the ESx series. I guess rental companies didn’t like the fact that their scooters could be flashed back to original firmware. That’s not something that should affect consumer units. We should have the right to repair and modify our own products
Back to the topic, we quickly realized that the communications between the scooter and the Ninebot app were encrypted, possibly using RSA-256. And that sucks, because it prevents all third-party apps from being used, essentially locking the scooter into the Ninebot ecosystem. But remember, firmwares are similar between ESx and Max! So similar that the whole command protocol remained unchanged, and that the communication between each part of the scooter itself isn’t encrypted. So similar that plugging an ESx dashboard into a Max works perfectly, and bypasses encryption. While this is a pretty ghetto solution, we were happy with it for the time being, but we needed to find something more long-term. Things were quiet for a time because we didn’t really know where to start. Recently though, I asked the developer of ES DownG and of M365 DownG, CamiAlfa, if there was a way to adapt the BLE firmware of the M365 pro – which uses the same dashboard at the exception of the newly added pedestrian mode indicator – to use the Ninebot protocol. Coincidentally, he had already done that for the ESx, which surely would work on the Max. And guess what? It works! Flashing his newly created firmware onto the Max dashboard makes it behave like the encryption isn’t even there, and all the functionalities of the dashboard are preserved (even the pedestrian indicator). All previous third-party apps designed to work on ESx scooters will work on the Max so, I guess that’s solved. Sorry, Ninebot! That very firmware will soon be available, so keep an eye out.
EDIT 9/11 : You can now download that BLE firmware named BLE555 here
For now, with the currently available resources, you can only unlock the top speed of your KickScooter Max if it was capped below 30km/h. It’s as simple as changing the serial number, which you can find out how to do that here.
As soon as ESC firmware is extracted, we will start the process of making a custom firmware toolkit similar to the one that already exists for the ESx.
We’ve made good progress on the Max and we made quicker progress than we ever did on any other scooter, even with the increased level of difficulty. I am worried about the next generation of scooters because they are making the repair and modification of our products more and more difficult – or at least they’re trying to, for now. We already have a lot of useful data and files about the Max, and we hope that everything will go to plan. We know that public expectations are high because this is a pretty popular scooter, but we can’t go faster than Ninebot (please push an update!!).
If you like our work and would like to help us keep going, please consider supporting us by donating here.