Armoury Crate for Linux


ASUS Armoury Crate is an incredible piece of engineering. I mean that sincerely. It’s a bloated Electron app that somehow manages to control RGB lighting, fan curves, and power profiles across hundreds of different motherboards, GPUs, AIOs, and RAM kits. The UI is entirely componentised, built to serve what must be 600 different product teams shipping their own panels into a shared shell. It is also, and I cannot stress this enough, an absolute piece of shit.

It also auto-installs itself via WPBT (Windows Platform Binary Table) baked into your BIOS — basically a vendor rootkit that can be deployed through a firmware update. And it doesn’t work on Linux. Building on the AIO firmware I had it build (more on that in an earlier post), I built the rest of the toolbox. I called it Ammobox. One tool, no Electron, no daemon (mostly). One command run at startup — ammobox set 000000 — to turn off all the LEDs I wish I’d never bought.

I’ve done hard reverse engineering before. I’ve lost a lot of my life to it. I would actively welcome AI doing it for me, and now it can. Rather than guessing at USB packets with usbpcap, I had Claude reverse engineer the protocols directly from the ASUS binaries — VGA_Extra.dll, Vendor.dll, the HAL layers — using Ghidra. That’s how we found things like the GPU’s ENE controller using byte-swapped register addressing on the wire, or that the colour order is R, B, G instead of R, G, B. Details you’d never guess from packet captures alone.

Along the way we found a bug in the Kingston RAM indexing that exists in the upstream tools too. I didn’t file it. I just fixed it in mine and moved on. The economics of scratching your own itch have changed — you don’t have to lose months of your life or negotiate your findings into someone else’s project any more.

OpenRGB and liquidctl are impressive feats of engineering, and I owe them a debt for proving this stuff is possible on Linux. But they’re written in C, in this day and age, which makes them developer-hostile to anyone who isn’t already steeped in the ecosystem. (Yes, I’m aware I had it build custom firmware in C for the AIO. The irony is not lost on me.)