media.ccc.de: MRMCD2026 - FACEB13D exploit: Liberating the A100 beast inside Nvidia’s CMP 170HX e-waste

https://media.ccc.de/v/2026-757-faceb13d-exploit-liberating-the-a100-beast-inside-nvidia-s-cmp-170hx-e-waste

We have been able to unlock the full 200 TFLOPS of compute performance and all 64GB of the usable HBM2e memory of the CMP 170HX, a severely restricted crypto-mining variant of the Nvidia A100 GPU accelerator. The exploit is based on guessing the debug AES key and creating a ROP chain and payload from the decrypted and disassembled booter_load code, a Falcon μcode module with a overflow vulnerability.

The CMP 170HX has both its computing power and addressable memory severely restricted. The end of Ethereum mining has turned it into potential e-waste.

Previous efforts in finding new uses for the CMP 170HX in computing and AI use have focused on replacing restricted operations with unrestricted ones. With its unrestricted FP16 scalar performance of 50 TFLOPS and fast HBM2 memory, the CMP 170HX has turned out to be highly capable of the token generation phase of LLM inference, but is still restricted by its small VRAM capability of 8GB or 10GB.

By flashing and testing different CMP 170HX VBIOS versions on a A100 engineering sample card, we were able to deduce that the limitations on compute power and addressable memory were imposed by the VBIOS firmware and not by any permanent defects or fuses on the GPU die.

By analyzing the firmware files for the GA100 silicon, we noticed that Nvidia ships two versions of every piece of code, one for production and one for testing, encrypted and signed with the production keys and the test or “debug” keys respectively. By comparing 170HX and A100 firmware files, we discovered that the encrypted and RSA-signed Falcon μcode in the VBIOS was encrypted using the weaker ECB variant of AES, not the stronger AES-CBC with Cipher Block Chaining. AES-ECB always decrypts the same 16-byte block of cleartext into the same 16 bytes of ciphertext. This resulted in the zero padding at the end of each Falcon μcode block showing up as a recurring pattern `717D1494 EACA317F`… at the end of each IMEM block in the debug branch. Using this cleartext / ciphertext pair, it was soon discovered that the test AES key is a simple permutation of the overused MD5 initialization vector 0123456789ABCDEF….

Nvidia open-source drivers have moved the resource management part of the driver to the GPU System Processor (GSP), a RISC-V core embedded on the GPU die. The GSP-RM code is validated by a small piece of Falcon μcode running on the SEC2 security processor. This code, called booter_load contains a fatal vulnerability; it does not check the length of the signature it loads from the host. An oversize signature will overwrite most of the 64kB of DMEM, including the stack and the stack guard canary value.

The cracked debug key allows us to decrypt and disassemble the debug version of the booter_load code. As the debug and the production versions of the code are identical, we can also “read” the production code. The booter_load code contains functions for writing and reading registers and fuse values in the BAR0 address space. The most interesting addresses are those of Privilege Level Masks (PLMs). It turned out to be almost trivial to construct a payload containing a ROP chain (Return-Oriented Programming) that sets the PLMs, allowing the user or host to overwrite the registers limiting compute performance and memory size.

With the exploit, we were able to enable 64GB of HBM2e memory and 200 TFLOPS of FP16 tensor compute on the CMP 170HX.

Petri Krohn

https://talks.mrmcd.net/2026/talk/ZDRJLV/

#mrmcd26 #Security

https://creativecommons.org/licenses/by-sa/4.0/