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.
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!
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.
Oh god that's awful. Why would anyone in their right mind do this?
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.
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.
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.
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.
How would you know if someone bypassed the restrictions if they were riding it safely?
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.
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!
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.
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).
I didn't actually even give it the ability to run this code and it could still reverse engineer everything.
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 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)
AI is driving digital ownership again and its formidable
With very little steering from me
eta: passive aggressive winky face
High capacity batteries are incredibly dangerous devices kept safe only by very careful engineering and manufacturing.
"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.
> 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.
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.
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.
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
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'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.
Once we start seeing websites that can brick devices over webusb we might see more security.
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!
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.
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).
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.
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.