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
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.
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.
Clearly you are in the past. I have reverse engineered some very difficult undocumented things. I can not go in to details but these were heavily hardened hardware. Custom SoC. of course without datasheets, involved multiple different levels of encryption and architectures of connected devices, broke all of it. All that is left is cryptocell pwn.
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.
That's kinda been the experience I've found in the open source diabetes space; several manufacturers have floated making things harder to hack, and we've found that actually showing them how many people use the reverse engineered API and would definitely go to their competitor is a really useful way of disincentivising that sort of anti-consumer behaviour.
When it comes to ebike batteries I think the alarmism is actually valid considering how often we see explosive fireballs on trains and in apartment buildings coming from cheap no brand ebike batteries.
High capacity batteries are incredibly dangerous devices kept safe only by very careful engineering and manufacturing.
> 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).
> 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.
No, the GP comment is right. I’ve worked on products where a lot of users did mods and used third party accessories.
Customers don’t care who, how, or why their product broke. They want to make noise and try to get a warranty fix for it. Customers would try to mod their devices, break it in the process, and then spend weeks trying to drag us on social media until we relented and shipped them a new one for free.
They’re not going to be pursuing damages against the Aliexpress vendor who sold them a flawed battery pack, nor the Amazon seller called WOBALUBAFY that has already disappeared, nor the YouTuber who hastily showed them how to solder some things together.
They always try to hide the evidence and claim the product failed by itself because the big American company has the deep pockets and the ability to send them free stuff to avoid bad PR.
Right, I see what you mean, but that's merely “saving the company the hassle of bogus support requests” and still has nothing to do with the claimed “improves reliability and consumer safety”. This actually confirms my intuition that the safety argument is BS (as always with this argument).
And even from a “bogus support request” PoV I fail to see how opening up your product degrades things, as the risk of a user having an issue with third party components should be lower, not higher, if the said components don't have to hack around proprietary restrictions.
The closed system doesn’t (only) prevent counterfeit systems, it also prevents someone from maliciously releasing a mod that could make the motor accelerate instead of break at some random time.
It’d be negligent for anyone to release a product like this without locking down the FW.
Many years ago, we did exactly that: our product had FW update support and our biggest concern was a rogue hacker creating a package that would brick the product.
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 definitely think AI is going to change this. Astra is shockingly good at reverse engineering. I was working with a proprietary software library and I just asked it how some (poorly documented) function worked and it just went off and disassembled it without me even prompting. I asked it if there was a way of disabling some error checks and it went and found some undocumented functions (not in the header), disassembled them and figured out how to use them for me.
I didn't actually even give it the ability to run this code and it could still reverse engineer everything.
I've been surprised how much Astra prefers to go off script to "find the answer" than Sol was unprompted.
I've been doing some PCB design lately, and I was working up the firmware with Codex and asked about how to handle a specific part of my SPI setup. The firmware and KiCad hardware are in different folders/repos so none of it was in-context, but Astra just decided to `find` the folder nearby, then read the KiCad net lists by directly invoking the KiCad CLI on the .kicad_sch/.kicad_pcb files it found. Topped it off by reading the Espressif code vendored in my PlatformIO install to make sure everything would work.
For now, but I think eventually the hardware companies will catch on and build everything much more locked down with signed firmwares, keys burned in to the chip, encrypted communications with accessories, etc.
This is what’s done for phones, game consoles, and other devices where hackers have been ripping open in the past, but most other consumer devices haven’t utilised these modern security features yet.
Once we start seeing websites that can brick devices over webusb we might see more security.
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.
I took a look into the batteries for the ebike systems, they have some sort of AES based pairing and the chips are read protected. You probably can dump the firmware from the update packages for the things. (maybe some hw exploitation stuff as well?) I did a thing where I put their battery controller on an after market battery with a divisor and it started and paired, but for some reason blew up afterwards.
I now realize it would be easier to write the whole thing wholesale, but.. uhh, it's no small feat, and I have a job soooo...
Bosch should open their shit, it might save them, because it seems the chinese with Avinox will eat their dinner in a couple of years. They seem to be pretty litigious, they went after a forum that documented initiatives to reverse (well, they also hosted pirated diagnostics sw but.. yeah)
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
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.
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.
This person is my hero, the technical prowess, fearlessness and grit to keep at this for six months is inspiring.
I am wondering why Rust in particular made it simpler to use the code or template into another app. That kinda seems like something most languages can achieve.
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).
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.
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.
A large part of this project was my personal learning. Ultimately I didn't improve the functionality of the device by a large margin; instead I learned a lot about how these devices are built. If I'd let Claude write replacent firmware it would've all been for naught.
Apologies for hijacking this comment, but if you have any interest in doing this sort of work full-time I may have a job for you. This project is awesome.
A microwave just cooks your input ingredients and if you use non microwave safe containers or food that is not suitable for it, you get edible but hazardous food.
Garbage in, Garbage out. There are minimum expectations on user like ability to source proper materials, use them correctly and an ability to verify/check the result for problems. More important if it's something you want to eat or ride!
You wouldn't call someone who puts food in a microwave a chef, would you? And you wouldn't say that putting food in the microwave is the same thing as cooking a Michelin star meal. These are different things.
I have a hunch this is not lost on you though, and you're doing this performatively.
Please stop. It is beyond tiresome, and it is not going to compel anybody. On the contrary, it is a great way to induce animosity.
I assure you that what you're describing is lost on no one either; rather, unlike you, plenty of people simply do not care, and find this distinction trite at best. Especially when presented this way.
> I have a hunch this is not lost on you though, and you're doing this performatively.
Uh, duh? I’m trying to draw a distinction that the person isn’t doing the work, the LLM is.
> On the contrary, it is a great way to induce animosity.
Sorry, what had you under the impression I was trying to make friends? When people who suck show up to your spot, you make them go away by making it clear they’re not welcome.
Or do you really need to be explained the point of civility?
> When people who suck show up to your spot, you make them go away by making it clear they’re not welcome.
Except you were not making things clear. On the contrary, you were pretending that there was ambiguity in their words, which arguably only complicated things. This is a very cowardly and sly way to make any point.
Mind you, for the unwelcome people, the downvote and flag buttons are the way to go. Comments are for conversation.
I’m not interested in being civil with people who actually believe using LLMs give you skills. The same way I’m not interested in being civil with homophobes and flat-earthers.
The Berm Peak YouTube channel did a similar reverse engineering of a retro Tron style e-bike. It didn't require going to new firmware but it is a good video as well about how he could accomplish it, https://www.youtube.com/watch?v=hPrtVGimBYs.
I'm surprised that all original firmwares were not protected at all.
I've tried to fix firmware of some cheap (but with good DAC and analog schematics) Chinese media player based on STM32 and firmware was protected by no-read fuses and only action possible in this case is to wipe flash, but not to read-out firmware.
And this scooter looks much more professionally-made and expensive product.
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.
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.
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.
Scooters just don't have the geometry to ride fast safely, they are incredibly prone to flicking the front wheel out and chucking the rider on the ground. The only way they can be ridden safely is riding relatively slowly.
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.
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!
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
[dead]
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.
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....
LLMs are fun until you have to break up a devices that use encrypted firmware files and non-documented interfaces.. that you are back in the past ;-)
But for the rest: Yes. They will be eaten alive by the latest generation of LLMs. I use DS-Flash 4.1 a lot for this. A big helper.
Make a custom harness, literally give the AI access to as much data as possible in terms of the device and it will crack it wide open like an egg.
AI is driving digital ownership again and its formidable
Clearly you are in the past. I have reverse engineered some very difficult undocumented things. I can not go in to details but these were heavily hardened hardware. Custom SoC. of course without datasheets, involved multiple different levels of encryption and architectures of connected devices, broke all of it. All that is left is cryptocell pwn.
With very little steering from me
eta: passive aggressive winky face
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!
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.
That's kinda been the experience I've found in the open source diabetes space; several manufacturers have floated making things harder to hack, and we've found that actually showing them how many people use the reverse engineered API and would definitely go to their competitor is a really useful way of disincentivising that sort of anti-consumer behaviour.
Safety is just an excuse for control, let's be real.
Also your "best way" doesn't always work - often there are monopolies or oligopolies (e.g. in smartphones).
Though I think for e-bikes that isn't the case, so yeah I would just say don't buy a Bosch ebike - there are plenty of better alternatives out there.
When it comes to ebike batteries I think the alarmism is actually valid considering how often we see explosive fireballs on trains and in apartment buildings coming from cheap no brand ebike batteries.
High capacity batteries are incredibly dangerous devices kept safe only by very careful engineering and manufacturing.
> 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).
> 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.
No, the GP comment is right. I’ve worked on products where a lot of users did mods and used third party accessories.
Customers don’t care who, how, or why their product broke. They want to make noise and try to get a warranty fix for it. Customers would try to mod their devices, break it in the process, and then spend weeks trying to drag us on social media until we relented and shipped them a new one for free.
They’re not going to be pursuing damages against the Aliexpress vendor who sold them a flawed battery pack, nor the Amazon seller called WOBALUBAFY that has already disappeared, nor the YouTuber who hastily showed them how to solder some things together.
They always try to hide the evidence and claim the product failed by itself because the big American company has the deep pockets and the ability to send them free stuff to avoid bad PR.
Right, I see what you mean, but that's merely “saving the company the hassle of bogus support requests” and still has nothing to do with the claimed “improves reliability and consumer safety”. This actually confirms my intuition that the safety argument is BS (as always with this argument).
And even from a “bogus support request” PoV I fail to see how opening up your product degrades things, as the risk of a user having an issue with third party components should be lower, not higher, if the said components don't have to hack around proprietary restrictions.
Just call hem out on social media, show the evidence and then just ignore them.
The closed system doesn’t (only) prevent counterfeit systems, it also prevents someone from maliciously releasing a mod that could make the motor accelerate instead of break at some random time.
It’d be negligent for anyone to release a product like this without locking down the FW.
Many years ago, we did exactly that: our product had FW update support and our biggest concern was a rogue hacker creating a package that would brick the product.
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 definitely think AI is going to change this. Astra is shockingly good at reverse engineering. I was working with a proprietary software library and I just asked it how some (poorly documented) function worked and it just went off and disassembled it without me even prompting. I asked it if there was a way of disabling some error checks and it went and found some undocumented functions (not in the header), disassembled them and figured out how to use them for me.
I didn't actually even give it the ability to run this code and it could still reverse engineer everything.
I've been surprised how much Astra prefers to go off script to "find the answer" than Sol was unprompted.
I've been doing some PCB design lately, and I was working up the firmware with Codex and asked about how to handle a specific part of my SPI setup. The firmware and KiCad hardware are in different folders/repos so none of it was in-context, but Astra just decided to `find` the folder nearby, then read the KiCad net lists by directly invoking the KiCad CLI on the .kicad_sch/.kicad_pcb files it found. Topped it off by reading the Espressif code vendored in my PlatformIO install to make sure everything would work.
For now, but I think eventually the hardware companies will catch on and build everything much more locked down with signed firmwares, keys burned in to the chip, encrypted communications with accessories, etc.
Why haven't then done this things so far?
This is what’s done for phones, game consoles, and other devices where hackers have been ripping open in the past, but most other consumer devices haven’t utilised these modern security features yet.
Once we start seeing websites that can brick devices over webusb we might see more security.
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.
I’m suspicious of this vision because for example, with battery packs, cells with compatible voltage and size have vastly different characteristics.
Those characteristics, like safe discharge rate, capacity, projected cycle count, are all things that manufactures exaggerate or get wrong.
I don’t think there’s any way that consumers can ever be informed enough to have an efficient market in products such as those
I can imagine a future where batteries and chargers communicate using an open-source protocol just as they are doing now over USB.
If the batteries are a full pack which contain their own internal charge controller, etc. Raw cells can't communicate anything.
The problem is the consumer can't tell the difference between a well engineered pack and one that will explode in their apartment overnight.
I took a look into the batteries for the ebike systems, they have some sort of AES based pairing and the chips are read protected. You probably can dump the firmware from the update packages for the things. (maybe some hw exploitation stuff as well?) I did a thing where I put their battery controller on an after market battery with a divisor and it started and paired, but for some reason blew up afterwards.
I now realize it would be easier to write the whole thing wholesale, but.. uhh, it's no small feat, and I have a job soooo...
Bosch should open their shit, it might save them, because it seems the chinese with Avinox will eat their dinner in a couple of years. They seem to be pretty litigious, they went after a forum that documented initiatives to reverse (well, they also hosted pirated diagnostics sw but.. yeah)
At https://infinite-battery.com (disclaimer: I'm a co-founder) our battery is compatible with Bosch systems
Like Apple who used BSD but then closed the whole chain?
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
> 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!
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
4G/5G Telco equipment (ab)use HDMI connectors/cables in a similar way.
As long as it's not intended for user to plug in, it's fine. Many other vendors also do that.
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.
This person is my hero, the technical prowess, fearlessness and grit to keep at this for six months is inspiring.
I am wondering why Rust in particular made it simpler to use the code or template into another app. That kinda seems like something most languages can achieve.
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)
Thanks, are these popular besides Huaqiangbei (Shenzhen) delivery guys?
I see them fairly often in Seattle
I have an inmotion V10 - soon rusty
I wanna have a friend like this guy
Wish I was brainy enough to do this sort of thing!
That's what is nice about LLMs. You CAN do these things now!
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.
[dead]
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.
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.
A large part of this project was my personal learning. Ultimately I didn't improve the functionality of the device by a large margin; instead I learned a lot about how these devices are built. If I'd let Claude write replacent firmware it would've all been for naught.
Apologies for hijacking this comment, but if you have any interest in doing this sort of work full-time I may have a job for you. This project is awesome.
A microwave just cooks your input ingredients and if you use non microwave safe containers or food that is not suitable for it, you get edible but hazardous food.
Garbage in, Garbage out. There are minimum expectations on user like ability to source proper materials, use them correctly and an ability to verify/check the result for problems. More important if it's something you want to eat or ride!
You wouldn't call someone who puts food in a microwave a chef, would you? And you wouldn't say that putting food in the microwave is the same thing as cooking a Michelin star meal. These are different things.
How they meant "you": https://en.wikipedia.org/wiki/Generic_you
How you meant "you": https://en.wikipedia.org/wiki/Deixis#Personal
I have a hunch this is not lost on you though, and you're doing this performatively.
Please stop. It is beyond tiresome, and it is not going to compel anybody. On the contrary, it is a great way to induce animosity.
I assure you that what you're describing is lost on no one either; rather, unlike you, plenty of people simply do not care, and find this distinction trite at best. Especially when presented this way.
> I have a hunch this is not lost on you though, and you're doing this performatively.
Uh, duh? I’m trying to draw a distinction that the person isn’t doing the work, the LLM is.
> On the contrary, it is a great way to induce animosity.
Sorry, what had you under the impression I was trying to make friends? When people who suck show up to your spot, you make them go away by making it clear they’re not welcome.
> Sorry, what had you under the impression I was trying to make friends?
Why, are you here to make enemies instead? If not, and heaven forbid there's a space between the two, this should apply:
https://en.wikipedia.org/wiki/Cooperative_principle
Or do you really need to be explained the point of civility?
> When people who suck show up to your spot, you make them go away by making it clear they’re not welcome.
Except you were not making things clear. On the contrary, you were pretending that there was ambiguity in their words, which arguably only complicated things. This is a very cowardly and sly way to make any point.
Mind you, for the unwelcome people, the downvote and flag buttons are the way to go. Comments are for conversation.
I’m not interested in being civil with people who actually believe using LLMs give you skills. The same way I’m not interested in being civil with homophobes and flat-earthers.
[dead]
What if you're the one that sucks?
Then we can agree to disagree :)
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.
You could give it some robot hands if you felt so much inclined
FdCAN or Bx?
The Berm Peak YouTube channel did a similar reverse engineering of a retro Tron style e-bike. It didn't require going to new firmware but it is a good video as well about how he could accomplish it, https://www.youtube.com/watch?v=hPrtVGimBYs.
I'm surprised that all original firmwares were not protected at all.
I've tried to fix firmware of some cheap (but with good DAC and analog schematics) Chinese media player based on STM32 and firmware was protected by no-read fuses and only action possible in this case is to wipe flash, but not to read-out firmware.
And this scooter looks much more professionally-made and expensive product.
[dead]
> 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.
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.
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.
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?
Scooters just don't have the geometry to ride fast safely, they are incredibly prone to flicking the front wheel out and chucking the rider on the ground. The only way they can be ridden safely is riding relatively slowly.
"Hasn't crashed yet" is different to "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.
That implies that speed itself is unsafe. Which it is not. Airplanes go some 500 mph and mostly don't kill people.
This is genuinely very cool. Amazing work and article
This is taking the "rewrite it in Rust" meme a little too far. I love it!
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.
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.
I think you are right, but he did also blog about it..
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!
Rewriting things in rust is like running doom on things
what a great project nice work!
[dead]
[flagged]
[dead]