Donor profiles and shadow config space
What a donor identity is at the register level: vendor and device IDs, subsystem IDs, BAR sizes and capability lists. And why a plausible donor beats a generic one.
Short answer
A donor profile is the identity of a real PCIe device. Your card writes it into the shadow config space and shows that to the host. It holds the vendor ID, the device ID, the subsystem IDs, the BAR layout and the capability list. A plausible donor reads like normal hardware. A generic one, or one shared by many cards, is a pattern anyone can enumerate.
On this page10
- Configuration space is the first thing anything asks
- Shadow config space, and why it is writable
- The fields, and what each one tells an observer
- Why plausible beats exotic
- What makes a donor plausible
- Why two people on one donor is worse than each having an ordinary one
- What a donor profile does not do
- Questions worth asking before you buy a profile
- Donor questions
- Sources
Configuration space is the first thing anything asks
Every PCIe device carries a small block of registers called configuration space. The host reads it during enumeration to answer three questions. Who are you, what class of device are you, and how much address space do you want. Windows uses the answers to pick a driver. Anything else running on that machine can read the same registers. Your card's firmware supplies those answers. So configuration space is the card's public identity, whether you chose its contents on purpose or not.
Shadow config space, and why it is writable
On a stock FPGA design the PCIe hard block answers configuration reads from values fixed at synthesis. DMA firmware puts a writable 4 KB overlay in block RAM in front of it — the shadow configuration space — and answers from that instead. In the public pcileech-fpga lineage this lives in a coefficient file compiled into the bitstream. So the card's identity is data rather than silicon. That is exactly why firmware can be rebuilt around a different donor without new hardware.
The fields, and what each one tells an observer
Offsets are from the start of the device's configuration space. The last column is the one that matters. It says not what the field is for, but what somebody learns by reading it.
| Offset | Field | What it holds | What it tells an observer |
|---|---|---|---|
| 0x00 | Vendor ID | A 16-bit code assigned to the manufacturer by PCI-SIG | Which company allegedly made this. A value that is unassigned, or a known FPGA vendor on a board claiming to be a NIC, is an immediate contradiction |
| 0x02 | Device ID | A 16-bit code the vendor assigns to a specific product | Exactly which product this claims to be. Paired with the vendor ID it identifies a real part that either does or does not exist |
| 0x08 | Revision ID | Silicon revision of that part | Whether the revision was ever shipped with this device ID. A revision no product used is a mismatch on its own |
| 0x09-0x0B | Class code | Base class, subclass and programming interface | What category of device this is. A class code that disagrees with the device ID is one of the cheapest checks anyone can run |
| 0x10-0x27 | BAR0 to BAR5 | Base address registers: how many regions the device wants, how large, memory or I/O, prefetchable or not | The memory footprint the real part would request. A donor whose BAR0 is 4 KB and firmware that requests something else no longer matches the part it claims to be |
| 0x2C | Subsystem Vendor ID | Who built the board the chip sits on | Whether the card is a reference part or a specific OEM build. Often identical to the vendor ID on first-party hardware |
| 0x2E | Subsystem ID | Which board variant from that integrator | The most under-copied field in bad firmware. A real chip with a blank or nonsensical subsystem pair is a strong signal on its own |
| 0x34 | Capabilities pointer | Offset of the first entry in the capability linked list | That the device has capabilities at all. A pointer into nothing is malformed in a way normal hardware is not |
| 0x40+ | Capability list | Linked list: power management, MSI or MSI-X, the PCI Express capability itself, vendor-specific entries | Which features the part supports. The real device's list has a specific set in a specific order, and a short or reordered list does not match |
| 0x100+ | Extended capabilities | PCIe extended space: advanced error reporting, L1 power substates, device serial number | A second, larger surface most people never populate. Silence where the real part reports entries is itself a difference |
| Ext cap 0x0003 | Device Serial Number | A 64-bit read-only serial that uniquely identifies one physical device | A single value that fingerprints the board. If two cards report the same one, they are provably the same profile |
None of these rows is a detection method by itself. They are the fields an observer can read for free. A profile is only as good as its least consistent one.
Why plausible beats exotic
People shopping for firmware often ask for the rarest possible donor, on the theory that nobody will have seen it. That reasoning is backwards. A device nobody has seen is interesting, and interesting is the opposite of what you want. The goal is a part that would not stand out in your specific machine. A capture card suits a machine that streams. A NIC suits a machine with a second network. Storage suits a machine with a free slot. A donor is plausible when someone reading the device list has no reason to look twice.
What makes a donor plausible
Five things, roughly in order of how often they are got wrong. All five come from the donor being a real part, copied in full.
- Internally consistent
- Vendor, device, revision, class code and subsystem pair all describe the same shipped product
- Complete
- BAR sizes and the capability list match the real part, not a default from a template
- Contextually ordinary
- The kind of card that belongs in a machine of this type, in a slot of this type
- Not shared
- The profile is not also running on a large number of other cards
- Currently shipping
- A part that still exists in the wild rather than one retired years ago
Warning
Why two people on one donor is worse than each having an ordinary one
A donor profile is only a fingerprint if it stands apart. A profile shared across many cards stands apart very easily. Not because any one field looks wrong, but because the exact combination of fields recurs. Once a combination is tied to something, every card carrying it inherits that tie. So do the cards that have done nothing. An ordinary, well-copied, one-of-one profile is a worse target than a rare profile shared by a batch. The first is one of thousands of real devices. The second is a set with known membership.
Warning
What a donor profile does not do
It changes how the card's identity reads at the PCIe layer. The rest of your exposure is untouched. That covers how the software behaves and how the input device moves the cursor. It also covers the display path, the account's own history, and what a human reviewing a report sees. Firmware quality removes one specific way of being noticed. It is not safety. Nobody can offer you safety here, and any seller who says otherwise is telling you what you want to hear.
Questions worth asking before you buy a profile
Answers to these tell you more than any tier name does.
- Is the donor a real shipped part, or a hand-edited set of values?
- How many other cards run this same profile right now?
- Are BAR sizes and the capability list copied from the donor, or left at template defaults?
- Is the subsystem pair populated, or zeroed?
- Does the profile suit the machine it will sit in, or is it just unusual?
- What happens to the profile if it becomes associated with something — is there a rebuild path?
Donor questions
Can I supply my own donor device?
Ask support before assuming either way. Reading a donor's configuration space needs the physical card and a machine to read it in. What is useful is a complete, accurate dump, not three values from a listing.
Does the donor have to match hardware I actually own?
No, and it usually does not. It has to be a part that would be unsurprising in a machine like yours. Owning the real device changes nothing about how the card reads.
Is a rare donor better than a common one?
Not by itself. Rare and shared is the worst combination. Common and well-copied is a reasonable one. One-of-one is what the per-order donor tiers exist to provide.
Can configuration space be changed without reflashing?
No. The shadow space is compiled into the bitstream, so a different profile is a different image and a new flash. That is also why a profile change is a rebuild request, not a settings toggle.
Does a good donor profile mean my setup is safe?
No. It addresses one exposure vector — the card's identity at the PCIe layer. Software behaviour, input, display path and account history are untouched by it.
Sources
What makes a donor plausible is our own judgement. So is the argument that a shared profile is worse than a common one.
- 01PCI configuration space (overview)
the header layout and the offsets of vendor ID, device ID, BARs, subsystem IDs and the capability list
en.wikipedia.org
- 02pcileech-fpga (Ulf Frisk)
the public gateware lineage the page names, where the shadow config space is compiled into the bitstream
github.com
Read next
Still stuck? Open a ticket on Discord
All guides