Free your device from its vendor app
How builders used REA to learn how a vendor's Windows or phone app talks to their hardware, then wrote their own Linux driver or client. Steps, safety notes and prompts.
Updated Oct 29, 2026
A keyboard whose lighting only works from a Windows app. An RFID reader that ships with a Windows-only tool. A TV that you can only control from Google Home. This week four builders hit the same wall and solved it the same way: they used REA to study how the vendor's app talks to the device, then wrote their own client.
- SK75 TMR Linux driver: HID protocol recovered from the Womier Electron app
- SOYO B550M ARGB on Linux: LED control from a Windows-only app
- RU5600 RFID reader: Linux client from the vendor's DLLs
- OpenRemote: Android TV remote protocol from the Google Home APK
Before you start
- Work on a device you own. Making your own hardware work on your own computer is the classic interoperability case.
- Keep the vendor app installed. You will compare your results against it.
- Ask REA to keep notes in a file, so a later session can pick up where this one stopped.
The steps
- Find the code that talks to the device. Vendors usually keep it in one place: a DLL such as SWHidApi.dll, the JavaScript inside an Electron installer, or the networking classes of an Android app.
- Find the transport: USB HID reports, a serial port, Bluetooth, or a network service the app finds with mDNS.
- Decode one command end to end before the rest. Pick one you can see, such as setting an LED colour or pressing a remote key.
- Write a message table: every command, its bytes, and whether you saw it in the code or inferred it.
- Build the smallest tool that sends that one command, test it on the real device, then add the others.
- Publish the protocol notes with the code. The RU5600 build ships a PROTOCOL.md and OpenRemote an EVIDENCE.md, so others can check the work.
Use REA on <vendor app or DLL>, which controls my own <device>. Find the code that sends commands to the device and the transport it uses (USB HID, serial or network). Document the bytes for <feature>, then write a minimal <language> tool that sends the same command. Mark what you saw and what you inferred.Start with commands that only read, such as status or version. Leave firmware updates and settings writes alone until you understand them: a wrong write can brick a device.
More prompts
The prompt library has a version for phone apps that control a device on your network, plus prompts for decoding protocols and file formats.