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

This is an unbelievably impressive project and a killer write up, very satisfying. I wonder if the author looked into using Slint [1] for the UI, given the codegen bloat issues they had with buoyant (which also looks very cool). I haven't used either, but I've done a few projects with Embassy and am always looking for an excuse to try embedded GUI tools

[1] https://slint.rs/

Reverse engineering like this is black magic to me. The writeup is good. It's detailed and I could follow along with what the author was doing even though I'm too stupid to ever attempt something like this. Nice job author.

I liked bullet 2 in the Introduction.

We need to free up Bosch systems. They use lots of open source libs, but they close the whole chain (like spare batteries) so that you cannot plug external batteries from other suppliers.

Thank you for posting! I got a e-scooter this spring and wrote my own app for it after reverse engineering the official app + BLE logs. I am not brave enough to do anything with the firmware on it though. Maybe not yet at least

rewriting scooter firmware in rust is the kind of unnecessary excellence i come here for. how did you debug without bricking it, swd probe or pure faith

> To my surprise, two of the USB-C pins were being used as a CAN bus (which smells horribly noncompliant).

Oh god that's awful. Why would anyone in their right mind do this?

I am also rusting my hw. Last week my mouse, this week my EUC (wish me luck). I would rather risk a crash than memory corruption

Very nice article, but I have a question about the rust bloat issues you encounter. Why do the size of the type names grow the size of the binary? Does rust look them up at runtime, and if not, why can they not be stripped like you would in C++?

I like how they used the USB C connector for whatever the hell they felt like. USB C is cheap and reliable, so it makes alot of sense.

I wanna have a friend like this guy

Wish I was brainy enough to do this sort of thing!

This is genuinely very cool. Amazing work and article

> The updater device then sends 64 byte chunks spread over 9 CAN 0x384 frames

Classic CAN uses 8 bytes long frame, so 64 bits. Is it a typo in the post, vor is it using CAN-FD?

This is taking the "rewrite it in Rust" meme a little too far. I love it!

Very nice. Be safe out there when tweaking these things.

Rewriting things in rust is like running doom on things

My general piece of advice to anyone looking to do this is not to even bother. Just strip the hardware package and replace it with an arduino/bb or an equivalent sbc figure out what the motors are and wire it up yourself. Way faster and less tedious

what a great project nice work!

First of all, this is impressive.

I do not know how what the legal context is in your country, but you may need to have a device that uses public roads licensed to do so. In case of any legal issues (accidents, mostly) not only you would not be covered by your insurance, but your situation may worsen for having operated it. Something to keep in mind.

[flagged]

[dead]