Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bensimms.moe

Post reply on HN
Print view View original

71–80 of 113 posts

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

#71

Post by callc »

trevithick wrote: post #55

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.

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!

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

#72

Post by hn_submit »

awakeasleep wrote: post #69
hn_submit wrote: post #42

Earlier quoted context omitted.

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…

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.

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

#73

Post by tverbeure »

yonatan8070 wrote: post #50

> 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?

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

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

#74

Post by arbirk »

yonatan8070 wrote: post #51
BrandoElFollito wrote: post #44

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.

I think you are right, but he did also blog about it..

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

#75

Post by plasticeagle »

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.

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

#76

Post by nitros »

plasticeagle wrote: post #75

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.

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.

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

#77

Post by perching_aix »

nearlyepic wrote: post #63
fragmede wrote: post #57

Earlier quoted context omitted.

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.

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.

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

#78

Post by Pannoniae »

plasticeagle wrote: post #75

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 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.

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

#79

Post by oulipo »

zoobab wrote: post #34

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.

At https://infinite-battery.com (disclaimer: I'm a co-founder) our battery is compatible with Bosch systems

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

#80

Post by IshKebab »

surajrmal wrote: post #46
zoobab wrote: post #34

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 manufactu…

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.

Post reply on HN