VBIOS SPI Dumps, Hashing and Silicon Identity: What a Registry Match Proves

Every graphics card carries its own firmware, the VBIOS, on a small flash chip on the board. It is written at the factory, it can be rewritten later, and from the outside a rewritten chip looks exactly like an original one. Phase 2 of an Assurd certification reads that chip and asks one narrow question: are these exactly the bytes of a factory image we hold for this board?

This post explains how that question is asked and answered (SOP-GPU-001 v1.1, Step 2.2, as amended on 2026-11-01). It also spells out what the answer cannot tell you, because a hash lookup is easy to over-read.

Where the VBIOS lives

The VBIOS is stored in an SPI flash chip on the GPU's board, typically a Winbond or Macronix part in an 8-pin SOP8 package. Its location varies by board partner. The firmware it holds includes the card's power limits, clock tables and fan control, and the identity the card reports to the system.

Flash memory keeps its contents without power, and it can be rewritten in place. That is why the chip's contents are worth checking on a used card, and also why checking them takes care.

Reading the chip

With the system powered off, the technician clips an SPI flash programmer onto the chip (at the HQ lab, an EZP2023+), reads the whole raw image with the programmer's software and saves it as vbios_dump.rom.

This reads the bytes as they are stored on the chip. The read does not depend on the graphics driver or on any software running on the card, so what is hashed is what is actually on the flash.

What a SHA-256 hash proves

SHA-256 turns any input, here a dump of $n$ bytes $b_1 \ldots b_n$, into a 256-bit digest:

$$H = \operatorname{SHA\text{-}256}(b_1 b_2 \cdots b_n) .$$

The same bytes always give the same digest. Change anything and the digest changes completely. Take a 1 MiB image of erased flash, 1,048,576 bytes of 0xFF, and clear a single bit in its last byte:

Image	First 16 hex digits of $H$
All 0xFF	f5fb04aa5b882706
Last byte 0xFE	6214862b85485126

One bit changed in over 8 million, and 111 of the 256 digest bits differ. Two images that differ in any way get unrelated digests.

That property cuts both ways, and both edges matter:

• Equal digests mean identical bytes. A match with a reference proves that the dump is that reference image, bit for bit.
• Unequal digests say nothing more than "different". They do not say which bytes differ, how many, or whether the difference matters. A retail BIOS update, a different factory revision and a hand-edited power limit all look the same: a digest that does not match.

The technician can run sha256sum vbios_dump.rom on the bench and gets the same digest as the server.

Hashed by the server

The technician does not report a hash. They upload the dump in Phase 2, and the server computes the SHA-256, archives the dump privately and records both. The certificate's ROM hash and verdict are always taken from that server record. A hash or verdict sent by the client has no effect.

The order is fixed: the GPU-Z dump must be extracted first, because the lookup needs the card's identity (next section). Until the server holds a ROM record for the asset, the job cannot be evaluated, graded or minted.

Silicon identity: the lookup key

Three PCI identifiers say what the card is:

• vendor_id: the chip vendor (10DE is NVIDIA, 1002 AMD, 8086 Intel);
• device_id: the GPU silicon and SKU;
• subsystem_id: the board partner and their specific board.

The server reads all three from its own parse of the archived GPU-Z dump. Technician input is never used. The lookup is keyed by device and board: a reference counts only if it is registered for this vendor_id:device_id and this subsystem_id.

Why the board? Boards built on the same GPU often ship different firmware: different power limits, fan curves and clocks. One board's factory image flashed onto another board (a cross-flash) is a valid image, but it is not this board's factory state. So it does not count as a match.

Three verdicts

VERIFIED_GOLDEN is positive evidence: the firmware is exactly a factory image for this board. It is the only verdict that adds to the health score.

NOT_IN_REGISTRY is shown as "Firmware not in reference registry". It is neutral: no limit, no score penalty, and it does not block any grade. It covers a device with no references yet, a board whose references do not include this image, and another board's image.

UNRECOGNIZED means the device itself is not registered. That is a Soft Limit, but about identification, not about the firmware: the technician identifies the card manually (Step 2.1), and a registry update is proposed. It carries no score penalty either.

The VBIOS verdict does not gate any grade. Certificates minted before the 2026-11-01 amendment may carry the older name VERIFIED_MODIFIED; it meant "hash unknown for a known device", and it is shown as "Firmware not in reference registry".

The registry today

On 2026-11-01 the registry listed 74 devices. 54 of them have references: 2,692 board-level entries holding 2,642 distinct hashes (some boards share an image). The other 20 devices are registered but hold no reference yet, so every card of those models currently reads NOT_IN_REGISTRY.

The registry holds factory images where Assurd has them. It is not complete, and it will never be complete for every board and every retail BIOS revision. That is the reason a missing match is never held against a card.

What a hash cannot detect

A lookup answers "is this a known factory image for this board?" and nothing else. In particular:

• It does not detect modified firmware. A VBIOS with an edited power limit or fan curve reads NOT_IN_REGISTRY, exactly like an unlisted retail image. There is no structural comparison of the image and no power-limit (TGP) check.
• It does not detect mining firmware. No registry of mining or otherwise modified images exists.
• It does not grade the card. No verdict lowers the score or fails a card.

Two other Phase 2 checks are separate and stronger. GPU-Z reporting the card as [FAKE] is a Hard Limit, and so is a critical mismatch between the card's reported configuration and its registry specification (Step 2.3). Both quarantine the card. Neither depends on the VBIOS hash.

Worked examples

These are test vectors with made-up identifiers. A device 10DE:AAAA is registered, with one reference hash $H_1$ for board 1111AAAA; device 10DE:BBBB is not registered.

• 10DE:AAAA, board 1111AAAA, $H_1$: VERIFIED_GOLDEN.
• 10DE:AAAA, board 1111AAAA, $H_2$: NOT_IN_REGISTRY.
• 10DE:AAAA, board 2222AAAA, $H_1$: NOT_IN_REGISTRY.
• 10DE:BBBB, any board, $H_1$: UNRECOGNIZED.

The third case is the cross-flash: the right image for the wrong board. The digest matches a reference, but not one for this board, so it is not a match.

Calibration status

The VBIOS lookup has no numeric threshold. The weight a registry match carries in the health score is an engineering prior pending fleet calibration (n ≈ 300), like every other score weight. We do not describe it as empirical.

See it on a certificate

On a certificate, the Silicon DNA tile shows the VBIOS registry verdict next to the PCI identifiers and the BIOS version. The sample certificate reads "Firmware not in reference registry". It is illustrative: no card was read, its ROM hash is a placeholder that names no board, so no lookup could have matched it. It still scores 100 and grades GOLD: the verdict costs nothing.

The certificate itself is protected by a signature, a different use of SHA-256. That is explained in Certificate Signatures: How to Verify an Assurd Certificate Yourself.

Notation

Symbol	Meaning	Unit
$b_1 \ldots b_n$	Bytes of the SPI flash dump	byte
$n$	Dump size	byte
$H$	SHA-256 digest of the dump	—
$H_1$, $H_2$	Example digests (worked examples)	—