oll3

Brings back memories of late nights trying to reverse engineer the Abit uGuru chip. Triggered by not being able to read the sensors in Linux while trying to overclock my computer into being less of a shit computer. Reverse engineering was successful but the computer never got any better. Still, fun and educating times it was!

Yes, on hal level there will be a bunch of unsafe. On firmware application level it's not often I find the need to reach for unsafe though. It would typically be if the hal is lacking in some sense.

Strictly commercial. But if one is happy with other language I guess there is little reason to switch.

I have replaced my use of C (and C++) in embedded with Rust for the last couple of years. Sure, some parts are still missing or immature, but overall also very promising. And I do enjoy it so much more than the MCU manufacturer's please-insert-your-c-code-between-these-comments-and-pray kind of development.

I guess the default key is a problem too. Mainly since it might trick developers/manufactures that this somehow makes the key exchange secure if you use it while setting a device unique key.

I do work with OSDP devices and I have heard this argument from manufactures, like "we only support setting a new key while using the default key, it's more secure that way". While it, at best, will just obfuscate the process.

Diffie-hellman would not be enough if there is a MITM at the time of the exchange, would it?

Somehow the control panel and the reader must authenticate each other. I'm no security expert but only way I can think of is to use some pre-shared key. A key set via a trusted side channel, or at a time when the osdp channel is known to not be intercepted.

Built this cdc tool for software update of embedded (Linux) systems and have deployed it with good enough performance on a couple of arm CPUs; https://github.com/oll3/bita

Though main goal has been keeping data usage low rather than speed up.

Not that this kind of stdin reading operation is something I do often. But at least the Rust code says what it does. Bitshifting stdin by a string on the other hand... Does it read a line, or forever, or read at all? I wouldn't call it the ultimate syntax for a line reader anyway. :)

> Honestly, gzipped json is likely much smaller than uncompressed protobuf.

Likely not. See here for a comparison: https://nilsmagnus.github.io/post/proto-json-sizes/

Btw, binary formats can also be compressed though it typically won't yield the same compression ratio as similar json would since there will be less repeation in the binary format.

Always happy to see my pet project mentioned (bita) and that it is actually being used by others than me :)