ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
74% Positive
Analyzed from 2613 words in the discussion.
Trending Topics
#firmware#reverse#things#more#motor#usb#without#used#product#don
Discussion (90 Comments)Read Original on HackerNews
[1] https://slint.rs/
I liked bullet 2 in the Introduction.
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....
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.
With very little steering from me
eta: passive aggressive winky face
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!
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.
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.
High capacity batteries are incredibly dangerous devices kept safe only by very careful engineering and manufacturing.
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.
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.
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.
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 didn't actually even give it the ability to run this code and it could still reverse engineer everything.
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)
Oh god that's awful. Why would anyone in their right mind do this?
https://www.aliexpress.us/item/3256809341543494.html
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.
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.
Classic CAN uses 8 bytes long frame, so 64 bits. Is it a typo in the post, vor is it using CAN-FD?
My guess is a typo.
How would you know if someone bypassed the restrictions if they were riding it safely?
"Hasn't crashed yet" is different to "safely"
There is reason for speed limits, they are not there to f--k with people for fun.
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.
It sounds like as long as you don't say anything, no one will ever know.