Voltage Glitching Turns a CMP-170HX Mining Card Into an A100-Class Accelerator

Used data center hardware has become the enthusiast's shortcut to a serious local AI box, and the CMP-170HX has been one of the more interesting entries. It's a mining card built on the same GA100 silicon as the A100, but Nvidia shipped it with capabilities fused off. A soft-mod called CMPunlocker already pulled some of those features back into the driver. Now one person has gone past what software can reach, and the result is a card that, on some measures, beats the A100 it came from.

Why the mining card was never really limited

The CMP-170HX is a useful case study because it shows how much of a modern GPU is decided after manufacturing. A GA100 die starts with 128 streaming multiprocessors so that defective units can be disabled and the rest still sold. The A100 ships with 108 active. The silicon for the full memory configuration is also physically present, with HBM2e dies that get disabled at the factory alongside the shader modules.

That's why the memory numbers look strange. The 80GB variant of GA100 carries all of its HBM2e dies, and the cards sold as 8GB and 10GB are trimmed versions of that same silicon. Vendors do this for product segmentation, and it's a sensible business decision when the mining variant doesn't need ECC, NVLink, or full memory. It's a weaker decision when the lockout is only as strong as a fuse.

The fuse box is the real target

Most chips include a fuse controller. In normal operation it's programmed once at the factory, burning physical links to disable parts that tested poorly. On the CMP-170HX, the controller is a 16,384-bit array organized as 512 by 32. Nearly every feature has an associated fuse: VRAM sections, individual shader modules, PCIe 4.0 and NVLink, and even the video codec hardware. The fuse state can be read, which is useful for diagnosis. It can't normally be written by the user.

The trouble is the fuse controller's access control is the thing that's supposed to keep users out. Popping fuses is one-way, and it can enable hardware rather than disable it. That asymmetry is what makes this case interesting. The developer's summary of the design was blunt: the fuse scheme is insecure because writing to it can grant access to more features, not fewer.

The starting point was a research paper describing how to exploit GA100 microcode and the GPU's secure coprocessor. That work pointed toward the protected fuse controller as a target. Getting from there to a write is where the hardware hacking begins.

Glitching the rail, not the chip

Instead of attacking the fuse logic directly, the developer targeted the power path. The voltage regulators on the card speak PWMVID, an Nvidia signaling standard, and the controller takes its instructions from PWM signals. A small board built around an $8 STM32G4 microcontroller tapped into those signals and could inject disruptions that made the VRM controller produce voltage glitches on the line feeding the GPU, right where the fuse controller sits.

The approach is a classic fault-injection technique. Timing the glitches precisely while reading fuse status in a tight loop eventually put the controller into a state where its security flags allowed writes. Once that happened, reconfiguring the card was, in the developer's word, "easy."

There's an important caveat here. Fuses are physical. Disabling a shader module that was marked defective is permanent, and the developer made a point of force-disabling defective units rather than leaving them active. Getting this wrong doesn't give you a retry. Anyone attempting it should expect to lose hardware.

What the results actually show

The developer tested the modification across multiple workloads on a batch of cards. Nine of them reached the full 80GB of VRAM. One was limited to 64GB. Those are the headline numbers, and they're specific to this sample, so they shouldn't be read as a yield guarantee.

The compute result is more interesting. Unlocking all shader modules put FP16 FMA throughput about 20% above a stock A100. The likely explanation is that these chips often have 120 or more working SMs, above the 108 on the spec sheet, which fits with the 128-SM die. That's a plausible read, but it's an inference from the observed behavior, not a measured die map.

It's also worth being clear about what CMPunlocker doesn't do. The soft-mod enables features in the driver, but it leaves the VRAM ceiling at 40 to 64GB depending on variant, keeps many shader modules locked, and holds PCIe at 2.0 speeds. It also leaves out ECC, NVLink, and multi-instance GPU support, which matter a lot in a server build. The volt-mod removes those limits. The best test card ran at PCIe 4.0 with the full feature set. The video encoder was not tested, which is a reasonable omission for most AI workloads.

Cost and what to watch

Prices in the source are the number to track. An 8GB CMP-170HX was listed around $3,000, and the 10GB variant around $2,500. A full PCIe A100 80GB can reach $20,000 or more. The SXM server modules are cheaper, but they need supporting infrastructure that most home labs don't have.

Those prices are unlikely to hold. Once the mod circulates, demand for modified cards should push the used market up, and the margin that makes this attractive will narrow. That's the usual dynamic with hardware hacks: the first buyers capture the spread, and everyone after pays closer to the modified value.

The disclosure timeline is also worth watching. The developer says the research is being published because someone else independently found the same issue, and that Nvidia has been informed. There's little the company can do for cards already in circulation. That's the uncomfortable part of fuse-based segmentation: once the hardware is in the field, the fix is in the next silicon, not a patch. My read is that the next mining-derived parts will tighten the fault-injection defenses, and the cat-and-mouse on older cards will keep going for as long as there's a cheap supply of them to work with.