USB descriptors, VID/PID and what descriptor cloning means
What a USB HID descriptor holds and which fields identify a device, why compatible-mice lists exist, and why a generic descriptor is a weaker identity than a cloned one.
Short answer
A USB HID descriptor is how a device describes itself when plugged in: its vendor ID, product ID, strings and report format. Descriptor cloning means the input device presents the identity of the real mouse attached to it instead of its own generic one.
On this page10
- What is a USB descriptor?
- Which descriptor fields identify a device
- Why changing only the VID and PID is not enough
- Why compatible-mice lists exist
- How descriptor cloning works
- Stock, generic and cloned identities compared
- How to check your own device
- What a cloned descriptor cannot hide
- Common descriptor questions
- Sources
What is a USB descriptor?
When any USB device is plugged in, the host asks it to describe itself, and nothing else happens until it answers. The device replies with a set of descriptors. A device descriptor says who made it and what model it is, and a configuration descriptor says how many interfaces it has. Interface and endpoint descriptors say what each interface does and how often it wants to be polled. Anything that is a keyboard, mouse or gamepad also sends a HID report descriptor, which describes the exact byte layout of the messages it will send. This exchange is called enumeration, and it happens in milliseconds, before any driver is loaded. Everything the operating system later believes about the device comes from those milliseconds. Your input device answers the same questions, and it can answer them well or badly.
Which descriptor fields identify a device
This is not the whole USB specification, but software on the host can read every field listed here without special privileges.
| Field | What it holds | What it reveals |
|---|---|---|
| idVendor (VID) | A 16-bit number assigned to a company by the USB standards body | Who made the device. A known mouse vendor's VID on a machine with that mouse is unremarkable. A development-board vendor's VID is a question |
| idProduct (PID) | A 16-bit number the vendor assigns to a specific model | Which model. VID and PID together are the device's public identity and the pair that driver matching, telemetry and inventory tools key on |
| iManufacturer and iProduct | Indexes into string descriptors, read back as text | The human-readable name shown in Device Manager. The most frequently forgotten field, and the easiest tell when it says something no mouse would say |
| iSerialNumber | An optional index to a serial string | A per-unit identifier. Some mice have one, many do not. Windows uses it when deciding whether a device reconnected on a new port is the same device |
| bcdDevice | A vendor-defined device revision number | Firmware revision. Real products move this between releases. A value that never changes across every unit in the world is itself a pattern |
| bcdUSB | The USB specification version the device claims to implement | Which spec era it is presenting as, and whether full-speed or high-speed behaviour is consistent with the rest of its claims |
| bDeviceClass and bInterfaceClass | Class codes. Class 3 is HID | That this is a human interface device rather than storage, audio or a serial adapter |
| Number of interfaces | How many functions one physical device exposes | Whether this is a mouse, or a composite gadget that is a mouse plus a serial port plus something else. A plain mouse is not usually three things |
| bInterval on the endpoint | The polling interval the device asks the host for | The report rate it claims to want. A device whose descriptor asks for a modest interval while reporting far faster is contradicting itself |
| HID report descriptor | Usage page and usages, axis field sizes, button count, wheel, any vendor-defined collections | The shape of the device. Button count, whether movement axes are 8-bit or 16-bit, whether there is a horizontal wheel, and whether a vendor-specific block is present that this model should have and does not |
None of these fields is secret, and none requires a driver to read. Any process on the host can enumerate the devices attached to it and read every one of these fields.
Warning
Why changing only the VID and PID is not enough
People treat the vendor and product IDs as the whole identity, and they are the first thing anyone checks, but they are only two numbers among many. Imagine a device that carries a well-known mouse vendor's VID and PID while its product string still names a microcontroller board. Its report descriptor declares a different number of buttons than that model has, and its endpoint asks for an interval that model never uses. That looks worse than leaving the device alone, because a half-copied identity does not add up and a mismatch is exactly what a check looks for. If you change the IDs, change everything that goes with them.
Why compatible-mice lists exist
Older passthrough firmware did not parse the attached mouse's descriptor. Instead it carried hard-coded profiles: a table of report layouts for named models, written by hand. If you plugged in a mouse on the list, the firmware knew how to decode its reports and how to copy its identity. If you plugged in something else, you got either nothing or scrambled movement. That is where the compatible-mice question comes from, and on firmware of that generation it is a real constraint that you have to check before buying a mouse. Newer firmware reads the layout from the device during enumeration and adapts, and MAKCM's automatic HID report descriptor parsing is the clearest example. That is why the lists have stopped mattering on current devices, although you should still check which generation your firmware belongs to rather than guess.
How descriptor cloning works
Descriptor cloning works in two steps. The input device enumerates the real mouse on its host side and reads what that mouse said about itself, then presents the same answers to the game PC on its device side. The identity the game PC sees therefore belongs to a mouse that really exists and is really plugged in, one layer further back. Full cloning covers the IDs, the strings, the revision, the interface layout and the report descriptor, so the answers agree with each other because they came from one real device. Partial cloning covers the IDs but leaves the strings or the report descriptor as the passthrough device's own, which brings back the mismatch problem. So the useful question about any firmware is not whether it can spoof a VID, but how much of the descriptor it copies.
Tip
Stock, generic and cloned identities compared
A stock identity is the passthrough board announcing itself as what it is. On a Teensy left alone, that means a development board's vendor ID and product strings on a machine that has no other reason to have one. A generic identity is an invented mouse that looks real enough: a class-compliant HID mouse with neutral strings. It looks unremarkable on its own, but it matches no product anyone sells, and it is the same for everybody running that firmware. A cloned identity is the descriptor of the actual mouse in your hand. It is consistent, it matches a product that exists, and it differs between users because their mice differ. These are three different positions, and they form a ranking. None of them, however, is proof against anything, because the ranking is about how much of an anomaly you present, not about safety.
How to check your own device
Do this from the game PC with a USB device viewer, so that you see your input device the way the game PC sees it. It takes five minutes and tells you more than any forum thread will.
- The product and manufacturer strings read like a mouse, not like a microcontroller or a dev board
- The vendor and product IDs belong together and match a product that actually exists
- The button count and wheel in the report descriptor match the model being claimed
- The device presents one HID mouse interface, not a mouse plus a serial port plus a keyboard you never use
- The requested polling interval is one that the claimed model plausibly uses
- A serial number string is present or absent, just as it is on the claimed model
- Nothing in Device Manager shows a name you would not expect to see on a normal gaming PC
Warning
What a cloned descriptor cannot hide
A perfectly cloned descriptor makes the device unremarkable during enumeration, but it does nothing about the timing and shape of the movement the device injects afterwards. That later layer is where the analysis happens, and it is the one people actually worry about. Movement that snaps is visible no matter what the descriptor said, and so is movement that is too smooth. The same goes for movement with an identical acceleration curve on every flick, or movement that corrects a target's position faster than a hand can. Descriptor work removes one class of easy signal. You need it, but it is not enough on its own, and treating it as enough is how people with excellent setups get caught behaving like software.
Common descriptor questions
Can a game read my mouse's descriptor?
A process on the machine can enumerate attached USB devices and read their descriptors without special privileges, and anti-cheat software running with kernel access can certainly do so. Whether a given title does, and what it does with the result, is not something anyone outside that company can honestly tell you.
If I clone my real mouse's descriptor, will there be two identical devices?
No, because your real mouse is attached to the input device's host side, not to the game PC, so the game PC only ever sees one device with that identity. If you also plug the real mouse directly into the game PC, you create exactly the duplicate you were trying to avoid.
Is cloning a descriptor illegal?
Presenting another company's vendor ID misuses an identifier that was assigned to that company, and it is also a terms-of-service matter with the game. We are not lawyers and this is not legal advice. It is, however, technically possible.
Does changing the descriptor affect performance?
The report descriptor does. If you declare 16-bit relative axes instead of 8-bit, larger movement deltas fit in a single report instead of being clipped and split. That is the difference between smooth and stepped movement on large flicks, while the identity fields have no effect on performance at all.
My cheat has a spoof descriptor toggle. Is turning it on enough?
It is better than leaving it off, but it is not a complete answer on its own. Find out what it actually changes: only the IDs, or the strings and report descriptor too. Then audit the result from the game PC with a device viewer instead of trusting the label on the checkbox.
Should I use a cheap mouse as the donor?
Use the mouse you actually play with. The point of cloning is that the identity matches a device you plausibly own and use, and your real mouse is the most plausible one you have.
Sources
The ranking of stock, generic and cloned identities is our own reading, and so is the audit checklist, which comes from bench testing.
- 01Microsoft Learn, USB device descriptors
the idvendor, idproduct, string and class fields in the table, and how windows matches on them
learn.microsoft.com
- 02Microsoft, Windows debugging tools (WDK)
where the usb device viewer used in the audit checklist comes from
learn.microsoft.com
- 03MAKCM firmware, GPL-3.0
that current makcm firmware parses the attached mouse's hid report descriptor instead of using a model list
github.com
Read next
Still stuck? Open a ticket on Discord
All guides