
Exploit PSP per GPU AMD navi31 (RX 7900) che disabilita i controlli delle firme del firmware, consentendo alla scheda di caricare firmware SMU, SDMA, MEC, IMU e RLC non firmato; non persistente dopo un cold boot.
Un exploit PSP (Platform Security Processor) per le schede AMD navi31 (serie RX 7900). Probabilmente adattabile anche ad altre famiglie di prodotti adiacenti.
Disattiva il controllo della firma del firmware del PSP, così la scheda caricherà firmware IP non firmato (SMU, SDMA, MEC, IMU, RLC) che altrimenti rifiuterebbe. Pensate a una gestione personalizzata dell'alimentazione, ai limiti di clock, o a qualsiasi altra cosa che risieda nel firmware firmato dal produttore e non da voi.
Nulla viene flashato. La patch risiede nella memoria del PSP e viene applicata durante un warm boot; un ciclo di alimentazione a freddo la cancella e la scheda torna allo stato originale. Quel warm boot è il "Wake and Break": la scheda si risveglia, la convinciamo a diventare davvero su di giri immediatamente e la costringiamo a neutralizzare i controlli delle firme. :-)
Testato su una RX 7900 XTX. Vedi Status.
python3 wakebreak.py 25=/path/to/firmware.bin
Questo applica la patch, esegue il warm-boot della scheda e invia la tua immagine come firmware di tipo 25. Se stampa accepted, il PSP ha accettato un'immagine che normalmente avrebbe rifiutato.
Ti serve qualcosa con cui provarlo? ipfw_images.py elenca il firmware che il tuo driver carica effettivamente e scrive una coppia di test — un'immagine autentica e una copia con un bit invertito nella sua firma, così il firmware stesso è identico byte per byte:
python3 ipfw_images.py # what does this card load?
python3 ipfw_images.py 25 # -> /tmp/fw_25_{ok,bad}.bin
python3 wakebreak.py 25=/tmp/fw_25_bad.bin
Il firmware di fabbrica rifiuta fw_25_bad.bin. Con la patch applicata, viene accettato.
Questa è l'intera dimostrazione.
python3 -m venv venv
venv/bin/pip install -r requirements.txt
make verify # are the shipped artifacts intact?
make selftest # offline sanity checks, no card touched
Hai bisogno di un host Linux con la scheda raggiungibile tramite il driver AMD di
tinygrad (PCIe o il suo bridge USB).
Consulta requirements.txt per una patch di tinygrad necessaria al tuo host.
Esistono quattro build firmware navi31 note, e la patch deve corrispondere.
Il profilo a è quello predefinito e copre il più comune. Se disponi di un dump
della flash SPI della tua scheda, identify.py te lo dirà:
python3 identify.py FLASH.bin
# -> sos-build c: wakebreak.py --sos-build c
Altrimenti provali e basta. Sbagliare una supposizione è innocuo: la patch controlla ciò che sta per modificare, trova qualcosa che non riconosce, non scrive nulla e la scheda si avvia normalmente.
python3 wakebreak.py --sos-build c 25=/tmp/fw_25_bad.bin
Confermato sulla scheda testata (RX 7900 XTX, profilo a):
| firmware manomesso, scheda stock | rifiutato |
| firmware manomesso, con patch | accettato |
| dopo un ciclo di spegnimento completo | rifiutato di nuovo — la scheda è stock |
NOTA: I profili b, c e d sono compilati e verificati offline ma non sono mai stati eseguiti su hardware. Se disponi di una scheda che corrisponde al profilo b, c o d, segnala se funziona!
La patch stessa è composta da poche centinaia di byte di assembly ARM, in hook/*.S. I
blob compilati sono inclusi nel repository, quindi non serve un cross compiler per usare questo strumento.
Se vuoi comunque ricompilarli:
make rebuild # needs arm-none-eabi binutils
make rebuild CROSS=/path/to/arm-none-eabi-
La build rifiuta di installare qualsiasi cosa il cui hash non corrisponda ai byte testati su una scheda, quindi una toolchain diversa non può modificare silenziosamente ciò che viene scritto sul tuo PSP.
wakebreak.py the exploit
identify.py which --sos-build does this card need?
ipfw_images.py build a signed/tampered firmware pair to test with
selftest.py offline checks
hook/ the patch: ARM sources and built blobs
firmware/ two stock AMD firmware images the exploit needs to get in
firmware/ contiene immagini AMD pubbliche e non modificate. Sono
versioni vecchie, mantenute perché il percorso di accesso passa attraverso di esse.
Non trattato qui di proposito: leggi il codice. wakebreak.py è composto da circa 600
righe commentate e i commenti spiegano il meccanismo, i controlli di sicurezza e perché ogni
passaggio è ordinato in quel modo. TL;DR: vengono caricate due trusted
application AMD originali, a una di esse viene fatto eseguire una catena che può
scrivere nella memoria del PSP, la patch viene inserita nella copia residente del bootloader, e
poi la scheda viene riavviata a caldo su di essa.
MIT, vedi LICENSE. Fanne ciò che vuoi.
È stato fatto ampio ricorso all'assistenza di LLM nella produzione di questo lavoro. Ciò non significa che l'autore non abbia idea di cosa stia realmente accadendo qui. molto lavoro manuale e numerose obiezioni sono stati necessari solo per arrivare a questo punto. Potresti non apprezzare gli artefatti Python generati in modo sciatto o quant'altro, ma non potrai discutere il fatto che la tua scheda Navi31 ora, all'improvviso, carica blob di componenti firmware non firmati. Grazie per l'attenzione.