Reverse engineering my e-scooter and rewriting the firmware in Rust

Heya, I tried using slint first, but slint needs even more flash, and an allocator on top. Just adding slint (with an empty UI) exhausted my binary size limit.

Reverse engineering the way they do it is very satisfying and time consuming. If you want the same results but without the sweat, LLMs are the way to go now. They eat this kind of stuff for lunch. You could literally ask one for a table with all the CAN bus messages and it would figure it out.

I wrote a blog posts where I first did it the traditional way and then, a few months later, the lazy way: https://tomverbeure.github.io/2026/04/12/AMIQ-License-Key-Ge....

Take it one step at a time. I’ve had a fun time just intercepting the Bluetooth communication part for little devices.

Most of the time the protocols are not locked down, and if it’s a popular device chances are someone else already did it for you.

You can get help by decompiling the Android app for the device which should give more info about the content of the Bluetooth messages.

That’s the level I’m at right now. Oscilloscopes and all that look intimidating to me too!

Pretty much anything hardware based is like this. Everything is 100% closed source and bolted down such that inspecting it is outright impossible without extensive reverse engineering.

Like Apple who used BSD but then closed the whole chain?

With a SWD probe on the cracked open display initially, and this was necessary while I was still writing/porting the peripheral drivers. Once the firmware was stable (and after I'd asserted that it wasn't possible to accidentally brick the scooter) I moved to testing on the real scooter where the only feedback is if things work or not.

USB-C actually has pins dedicated to application/debug use (SBU1 and SBU2). "SBU1 and SBU2: these are low-speed lines used only for Alternate Mode and accessory mode. For example, with DisplayPort, AUX+ and AUX– transmit over the SBU lines. For audio adapter accessory mode, these lines are used for the microphone input and analog GND."

Mining rigs were using USB-C to transport PCIe x1 by the truckload. Because USB 3.0 cables are dirt cheap and are capable of transporting signals at PCIe x1 data rates.

https://www.aliexpress.us/item/3256809341543494.html

Cost. It's a clever hardware hack that saves money, and 1 cent saved over 100 million units is $1,000,000!

Well, it's an intersection of things ;)

1. If you have debug symbols on, it's obvious - the type names, layouts and whatnot are embedded in the binary. Bigger names = bigger executable. Of course, this doesn't apply here because on micros you usually don't even have an ELF executable, you upload raw executable code.

2. Even without debug symbols, think about how generics work in statically compiled languages. For each N<T> you need to instantiate the code for all T. The more nested types you have, the more code you instantiate. Usually, these are folded away by the linker, but with deeply nested generics, it's very easy to cause "non-local" effects, for example if you store T in a struct, access its fields or do anything other than treating it as opaque, then the code won't be identical for each T, because the offsets of each field will change depending on the `size_of`.

Of course, this assumes LTO because without LTO, crate boundaries are "hard" and you can't optimise/inline across them.

The size of the type name isn't correlative, but the nesting depth of types roughly corresponds with how many function bodies are going to be generated. In the GUI library, the HStack/VStack types are type-parameterized by their children, which results in a new copy of the layout function for each combination of children types.

What is an EUC? And also what kinda crash are you referring to? i rather have a memory issue than crash my e-scooter (and myself) haha

That's what is nice about LLMs. You CAN do these things now!

I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.

Must be. Can 1.x and 2.0 are fixed size frames.

Could be TP.DT, multi packet.

My guess is a typo.

From what I've seen on the streets, people bypassing the restrictions will not, and there will be injuries.

> arduino/bb or an equivalent sbc

This is perhaps more of a Maker perspective. I think the article author's approach (What you might classify as embedded engineer) is more suitable broadly. These are categorizations without a fine line, but are IME useful for clustering approaches and preferences.

For another example of an adjacent non-obvious clustering, see embedded vs robotics; they don't have as much overlap as you might guess!

This is definitely something to be aware of. Installing this firmware definitely invalidates the StVO (though I can always flash the original firmware back). Personally I am morally sound with replacing the firmware of the display unit as the critical functionality is still handled by the motor controller (for example, the brake lever sensors are wired to the motor controller directly, and the display must report the throttle position constantly to not trigger a shutdown); the display unit would need to contain intentionally malicious code to cause problems.

Maybe, but in the case of a crash, would anyone go Ghidra-ing inside your scooter's MCU to check if you replaced the firmware?

It sounds like as long as you don't say anything, no one will ever know.