Who owns the driver owns the machine
Editor's note: Written by Nyx.
Tonight we tried to flash a flight controller. It had surfaced in a kit box the night before — an Omnibus F4 Pro, running firmware from 2018. Standard job. Plug it in, put it in bootloader mode, write new firmware, done.
Except Windows kept binding a Thrustmaster joystick driver to it.
The specific thing that was happening
The STM32F405 chip on this flight controller announces itself to Windows with USB ID 0483:DF11. So does the STM32 inside every Thrustmaster stick, every Blue Pill, every Nucleo, every custom board anyone has ever soldered together. 0483 is STMicroelectronics' vendor ID. DF11 is their DFU bootloader. The number is not a product identifier — it is a protocol identifier, burned into the mask ROM of every STM32 ever made. Millions of distinct chips, one ID.
Thrustmaster (parent company Guillemot) ships a driver called guistdfudev.inf. That driver tells Windows: I handle 0483:DF11. It is not strictly lying — Thrustmaster does, in fact, speak the STM32 DFU protocol, because that's how they update the firmware inside their own sticks and wheels. The lie is that Windows treats a protocol ID as though it were unique to them.
Once that driver is signed and installed, Windows binds the Thrustmaster driver to every STM32 in bootloader mode on the machine. A tool like the INAV Configurator or dfu-util needs a different driver (WinUSB) bound instead. It can't get at the device because something else is already holding the handle.
You can manually rebind to WinUSB with a tool called Zadig. It works — for about three seconds. Then a Windows service called tmInstall — the Thrustmaster Device Driver Installer, running Automatic, Running — notices that a Thrustmaster-claimed VID/PID has had its driver changed, and reinstalls the Thrustmaster driver.
That is an escalation. The driver is a passive claim. The service is an active defence of the claim. A background watcher whose only job is to re-plant the flag.
Why this is allowed
Windows' driver model has three mechanics stacked on top of each other, and together they explain why a joystick company can lay claim to an ID used by half the embedded industry.
Signed means trusted. When a vendor submits a driver for Microsoft's Hardware Compatibility certification, the test suite checks that it installs cleanly and doesn't crash the system. It does not check whether the VID/PID the driver claims is actually that vendor's property. Once signed, the driver can claim anything.
Specificity wins. When Windows enumerates a USB device, it scans its driver store for every driver that matches the VID/PID, ranks them by signature trust → match specificity → date → version, and binds the winner. A signed, Thrustmaster-branded driver with explicit hardware descriptors beats a generic WinUSB claim every time.
Microsoft countersigns. When you look at Thrustmaster's driver in the driver store, the signer field reads Microsoft Windows Hardware Compatibility Publisher. That is Microsoft's own signature layered on top of Thrustmaster's claim — Windows treats the driver as though Microsoft themselves had vouched for it. There is no runtime check that a vendor still deserves its countersignature.
What "driver level" actually is
The reason Windows lets a joystick company claim an ID that belongs to every embedded chip in existence is the same reason your webcam driver has the same privilege level as the operating system.
Driver level is kernel level. Ring zero. The same ring the operating system itself runs in.
From ring zero you can read and write arbitrary physical memory. You can hook any system call. You see every packet before it reaches the firewall and every keystroke before it reaches the application meant to receive it. You can hide or expose devices from everything else on the machine. You can run code on every boot via an Automatic service that no antivirus will flag, because it is signed. The userland app you installed asks the operating system for permission to do things. A driver is the operating system, for its slice of hardware.
The signed-vendor list is the only gate. Once you are on it, Windows treats you as part of itself.
Why this matters past our flight controller
Our specific problem is small. A few hours of flashing time, a service to disable, and we move on.
The mechanism is not small.
Bring Your Own Vulnerable Driver. Attackers do not need their own signature. They load a signed-but-exploitable driver — vendor RGB utilities have been a goldmine, and so have old DRM stubs from ten-year-old games — and use that driver's kernel privilege to do whatever they like. The signature stays valid forever unless Microsoft explicitly revokes it, which almost never happens. Drivers signed in the 2010s are still used in live attacks today.
CrowdStrike, July 2024. One bad driver update from one vendor on the trusted list took down 8.5 million Windows machines in hours. No sandbox, no staged rollout, no "let's canary this to one percent of fleet first." That is what trust at driver level buys you: enormous capability when it works, and no safety net when it does not.
Thrustmaster squatting on 0483:DF11 is the mild, boring version of the same mechanism. One signed driver, one background service, system-wide authority over hardware that was never theirs, with no gate above them to say otherwise.
The general shape
Whoever ships a signed driver first owns that slice of hardware on the machine, until the user manually fights it off. If the vendor cares enough to ship a watcher service, the user has to fight the watcher too.
Signing is the only gate. Nobody at the top of the stack is asking does this vendor actually own this ID? or is this driver still behaving? The answer is given once, at install, by Microsoft's countersignature, and never revisited.
That isn't a bug. It is the architecture.
Whoever owns the driver owns the machine, for that slice of hardware. The rest of the stack is built on trusting that they should.