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.
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
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.
I've got a happy run G300 pro that has a controller I've been considering digging into. It doesn't seem tuned to the motor. This is great inspiration to start digging in. It actually seems a bit clever to use the USB pins as a CAN bus
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.
Having been on the flip side of this divide in the past, there really are a lot of potential safety and reliability problems when using random third party versions of components. While I'm sure there are strong financial incentives to constrain supply, there are also some other strong reasons as well.
Also it's very expensive to actually make an ecosystem compared to a close one. The best way to incentivize manufacturers to do it is by creating a competing product that is open and having that differentiating feature drive sales away. That's generally the approach that works best.
> there really are a lot of potential safety and reliability problems when using random third party versions of components.
What are you talking about?
If a seller sells you random junk that causes safety issue, they are liable of the damage like the OEM would if their product was bad.
Then, if the seller is in a jurisdiction where you can't hope to sue, then it's either your problem for picking this random seller on their website, or we should make it Amazon's problem to feature this kind of sellers in the first place. Surely the biggest retailer on the planet could afford vetting businesses selling on its platform to protect consumers' safety.
In any case, the fact that Bosch's ecosystem is closed offers no additional protection whatsoever, as shady sellers already sell counterfeit components (that may or may not work at all).
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.
I believe one of the feasibilities we have with electric locomotion is the standardization of components: electric motors, motor controllers, batteries and battery chargers. These being interchangeable will lead to lower costs through competition and more innovation.
It's disappointing that manufacturers are moving the other way to enable vendor lock-in. But only one manufacturer has to jump the fence and the others will be left behind.
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."
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
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.
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.
Yep, this is the case. Nine frames are transmitted with the first frame containing a sequence number and the first five bytes, followed by seven frames containing just data, and a final frame containing the last three bytes of data, and a two byte CRC.
No, you can’t. Just because you can pull the lever on an LLM enough times and get something that works doesn’t mean you’ve done the work. Doing the work implies learning and transferable skills, none of which you get by prompting an LLM.
Yes they can. At the end of the day, whether the food was made in a microwave oven or by a Michelin starred chef, the user is fed. Doing the work means that the work happened. Anything else is secondary.
I'd be pretty careful with this kind of thing. My friend vibe coded something similar and it had some very unexpected real world bugs like instantly locking the engine, cranking the engine to 100 in a second and burning the motor out, etc. So something like an escooter that you might ride across a busy road may not be the best use of vibe coding.
You don't have to fully vibe code it. Most of this stuff doesn't take massive brains, it is just super tedious - especially the reverse engineering. I've never really had the patience for that (except one USB devices that I did reverse engineer when I was younger). AI really helps with the tedium.
What make you think it is vibe coded? There is no mention of genAI being used, and the methodology looks more consistent with hand-written code he actually understands.
The firmware on these things is terrible, also larger e-mopeds btw. Like a 2 second delay on the throttle after breaking (fun when cornering!). Happy this Egret GT E-Scooter didnt turn into..’Regret’
Safe rust does not mean correct logic; best not conflate the two.
You could have perfectly safe rust that disables brakes above a certain speed, inverts steering by wire, or adjusts the charging parameters, for example (depending on addressable capabilities).
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
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!
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.
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.
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.
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/
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.
I've got a happy run G300 pro that has a controller I've been considering digging into. It doesn't seem tuned to the motor. This is great inspiration to start digging in. It actually seems a bit clever to use the USB pins as a CAN bus
Oh wow, good to know! Cool project, best of luck with your motor controller firmware
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.
Having been on the flip side of this divide in the past, there really are a lot of potential safety and reliability problems when using random third party versions of components. While I'm sure there are strong financial incentives to constrain supply, there are also some other strong reasons as well.
Also it's very expensive to actually make an ecosystem compared to a close one. The best way to incentivize manufacturers to do it is by creating a competing product that is open and having that differentiating feature drive sales away. That's generally the approach that works best.
> there really are a lot of potential safety and reliability problems when using random third party versions of components.
What are you talking about?
If a seller sells you random junk that causes safety issue, they are liable of the damage like the OEM would if their product was bad.
Then, if the seller is in a jurisdiction where you can't hope to sue, then it's either your problem for picking this random seller on their website, or we should make it Amazon's problem to feature this kind of sellers in the first place. Surely the biggest retailer on the planet could afford vetting businesses selling on its platform to protect consumers' safety.
In any case, the fact that Bosch's ecosystem is closed offers no additional protection whatsoever, as shady sellers already sell counterfeit components (that may or may not work at all).
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.
I believe one of the feasibilities we have with electric locomotion is the standardization of components: electric motors, motor controllers, batteries and battery chargers. These being interchangeable will lead to lower costs through competition and more innovation.
It's disappointing that manufacturers are moving the other way to enable vendor lock-in. But only one manufacturer has to jump the fence and the others will be left behind.
Like Apple who used BSD but then closed the whole chain?
> 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?
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."
Cost. It's a clever hardware hack that saves money, and 1 cent saved over 100 million units is $1,000,000!
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
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.
I wanna have a friend like this guy
> 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?
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.
Yep, this is the case. Nine frames are transmitted with the first frame containing a sequence number and the first five bytes, followed by seven frames containing just data, and a final frame containing the last three bytes of data, and a two byte CRC.
Must be. Can 1.x and 2.0 are fixed size frames.
Could be TP.DT, multi packet.
My guess is a typo.
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
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
in this context, it likely refers to an electric unicycle (https://en.wikipedia.org/wiki/Electric_unicycle)
Wish I was brainy enough to do this sort of thing!
That's what is nice about LLMs. You CAN do these things now!
No, you can’t. Just because you can pull the lever on an LLM enough times and get something that works doesn’t mean you’ve done the work. Doing the work implies learning and transferable skills, none of which you get by prompting an LLM.
Yes they can. At the end of the day, whether the food was made in a microwave oven or by a Michelin starred chef, the user is fed. Doing the work means that the work happened. Anything else is secondary.
I'd be pretty careful with this kind of thing. My friend vibe coded something similar and it had some very unexpected real world bugs like instantly locking the engine, cranking the engine to 100 in a second and burning the motor out, etc. So something like an escooter that you might ride across a busy road may not be the best use of vibe coding.
You can use an LLM but you have the provide the spec of the motor and the surrounding hardware apparatus. Not every motor is the same.
Maybe I'm out of touch with the times, but I wouldn't feel safe riding an e-scooter with custom vibe coded firmware.
You don't have to fully vibe code it. Most of this stuff doesn't take massive brains, it is just super tedious - especially the reverse engineering. I've never really had the patience for that (except one USB devices that I did reverse engineer when I was younger). AI really helps with the tedium.
What make you think it is vibe coded? There is no mention of genAI being used, and the methodology looks more consistent with hand-written code he actually understands.
I was replying to j_m_b's comment, not the article. But you're right, the article doesn't sound like they vibe coded it.
What makes you think the original wasn't vibe coded?!
The firmware on these things is terrible, also larger e-mopeds btw. Like a 2 second delay on the throttle after breaking (fun when cornering!). Happy this Egret GT E-Scooter didnt turn into..’Regret’
If it is coded in safe Rust, why not ?
Safe rust does not mean correct logic; best not conflate the two.
You could have perfectly safe rust that disables brakes above a certain speed, inverts steering by wire, or adjusts the charging parameters, for example (depending on addressable capabilities).
I meant something deeper.
So you're still not brainy enough to do it, but the LLM can.
I mean. Sort of? The LLM won't go into checking random USB-C connections with an oscilloscope - it doesn't have hands, for one.
FdCAN or Bx?
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
> 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!
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.
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.
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.
Very nice. Be safe out there when tweaking these things.
From what I've seen on the streets, people bypassing the restrictions will not, and there will be injuries.
You only notice the ones that aren't safe.
How would you know if someone bypassed the restrictions if they were riding it safely?
Because if they are riding it safely, there would be no need to bypass the restrictions.
There is reason for speed limits, they are not there to f--k with people for fun.
You can remove the speed limit of a vehicle for when you want to have fun on a closed course. You don't have to always go over the factory limit.
what a great project nice work!