Hacker News Reader

Comment by gh123man | Hacker News Reader

Ive been building something very similar to this for Razer devices

Similar to other reverse engineering threads ive seen recently, AI is empowering us to replace crappy vendor software with something better.

Also - OpenSnek documents a mostly complete bluetooth spec for the Razer vendor protocol which as far as I know, hasn't been done anywhere else yet!

View on HN

> AI is empowering us to replace crappy vendor software with something better

Really hope this to be true, but I think companies will go for crappy vendor software than one-man, unvetted, vibe coded software.

I dunno, lots of companies seem pretty happy to build large portions of their business on top of unvetted single-maintainer open source projects. Don't see why they'd stop doing so now.

(Anyway, I don't care so much about what companies go for, as opposed to what I can do on my own devices.)

Exactly my thoughts. My point was targeted more towards consumers who usually don't have a voice in the software/hardware they buy. Reverse engineering, de-vendor locking, and open sourcing the protocol gives us freedom to use the device we purchased however we want, for as long as we want.

Doesn't have to be, you can just clone the repo and have Claude do a security analysis and then host it on an internal company git instance and then send the developer a $200 donation as a thank you. About an hour of work with modern AI tools

It depends on company policies but even so this is a boon for personal computing.

> AI is empowering us to replace crappy vendor software with something better.

Speaking of, this probably can't be against any ToS, right? Since the devs using the LLMs don't look at any proprietary code, specs, docs, whatever.

Yes. You can't patent an ABI and rebuilding against a specification has always been OK. Reimplementing the same logic has not.

However, AI may also help logitech and others improve their obfuscation of signals through more vibe coding.

The hard part with these protocols is usually state, not packet formats. Does the spec cover initialization and feature negotiation across different firmware versions, or is that still inferred from one device’s traces?

Everything is inferred from device traces, and compared against known protocol implementations (ex USB - thanks to the openrazer project) - which AFAIK have remained pretty stable over the years.

So far, it's survived a few device firmware updates with no visible breaking changes, but I can't guarantee it always will.

https://github.com/openrazer/openrazer

Reply on news.ycombinator.com