blasty/wake-and-breakPSP-Exploit für AMD-navi31-GPUs (RX 7900), der die Firmware-Signaturprüfungen deaktiviert, sodass die Karte unsignierte SMU-, SDMA-, MEC-, IMU- und RLC-Firmware lädt; nicht persistent über einen Kaltstart hinweg.
Ein PSP-Exploit (Platform Security Processor) für AMD-navi31-Karten (RX 7900-Serie). Wahrscheinlich auch auf andere benachbarte Produktfamilien übertragbar.
Er schaltet die Firmware-Signaturprüfung des PSP ab, sodass die Karte unsignierte IP-Firmware (SMU, SDMA, MEC, IMU, RLC) lädt, die sie sonst verweigern würde. Denken Sie an benutzerdefiniertes Power-Management, Taktlimits oder alles andere, was in der vom Hersteller signierten Firmware steckt und nicht in Ihrer.
Es wird nichts geflasht. Der Patch lebt im PSP-Speicher und wird während eines Warmstarts angewendet; ein Kaltstart löscht ihn und die Karte ist wieder im Auslieferungszustand. Dieser Warmstart ist der „Wake and Break": Die Karte wacht auf, wir überzeugen sie, sofort richtig high zu werden, und zwingen sie dazu, ihre Signaturprüfungen zu deaktivieren. :-)
Auf einer RX 7900 XTX getestet. Siehe Status.
python3 wakebreak.py 25=/path/to/firmware.bin
Damit wird der Patch eingespielt, die Karte warm gebootet und dein Image als Firmware-Typ 25 übergeben. Wenn accepted ausgegeben wird, hat die PSP ein Image angenommen, das sie normalerweise abgelehnt hätte.
Brauchst du etwas zum Ausprobieren? ipfw_images.py listet die Firmware auf, die dein Treiber tatsächlich lädt, und schreibt ein Testpaar — ein echtes Image und eine Kopie mit einem gekippten Bit in ihrer Signatur, sodass die Firmware selbst byte-für-byte identisch ist:
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
Die Stock-Firmware lehnt fw_25_bad.bin ab. Mit dem angebrachten Patch wird es akzeptiert.
Das ist die gesamte Demonstration.
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
Du benötigst einen Linux-Host, auf dem die Karte über den AMD-Treiber von
tinygrad erreichbar ist (PCIe oder dessen USB-Bridge). Siehe requirements.txt für einen tinygrad-Patch, den dein Host benötigt.
Es gibt vier bekannte navi31-Firmware-Builds, und der Patch muss dazu passen.
Profil a ist der Standard und deckt den häufigsten ab. Wenn du einen Dump
des SPI-Flash deiner Karte hast, sagt dir identify.py:
python3 identify.py FLASH.bin
# -> sos-build c: wakebreak.py --sos-build c
Andernfalls probieren Sie sie einfach aus. Falsch zu raten ist harmlos: Der Patch prüft, was er ändern will, findet etwas, das er nicht erkennt, schreibt nichts und die Karte startet normal.
python3 wakebreak.py --sos-build c 25=/tmp/fw_25_bad.bin
Bestätigt auf der getesteten Karte (RX 7900 XTX, Profil a):
| manipulierte Firmware, Original-Karte | abgelehnt |
| manipulierte Firmware, gepatcht | akzeptiert |
| nach Kaltstart-Stromzyklus | erneut abgelehnt — Karte ist im Originalzustand |
HINWEIS: Die Profile b, c und d sind gebaut und offline geprüft, wurden aber noch nie auf Hardware ausgeführt. Wenn du eine Karte hast, die zu Profil b, c oder d passt, melde bitte zurück, ob es funktioniert!
Der Patch selbst besteht aus einigen hundert Bytes ARM-Assembler, in hook/*.S. Die
fertig gebauten Blobs werden mit dem Repo ausgeliefert, du brauchst also keinen Cross-Compiler, um das zu nutzen.
Wenn du sie trotzdem neu bauen willst:
make rebuild # needs arm-none-eabi binutils
make rebuild CROSS=/path/to/arm-none-eabi-
Der Build weigert sich, irgendetwas zu installieren, dessen Hash nicht mit den Bytes übereinstimmt, die auf einer Karte getestet wurden, sodass eine andere Toolchain nicht stillschweigend ändern kann, was auf deine PSP geschrieben wird.
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/ enthält unveränderte, öffentlich ausgelieferte AMD-Images. Es sind alte
Versionen, die behalten wurden, weil der Weg hinein durch sie führt.
Hier absichtlich nicht behandelt: Lies den Code. wakebreak.py hat ~600 kommentierte
Zeilen, und die Kommentare erklären den Mechanismus, die Sicherheitsprüfungen und warum jeder
Schritt in dieser Reihenfolge abläuft. TL;DR: Zwei unveränderte AMD-Trusted-
Applications werden geladen, eine davon wird dazu gebracht, eine Kette auszuführen, die PSP-Speicher
schreiben kann, der Patch wird in die residente Kopie des Bootloaders platziert, und
dann wird die Karte warm in diese Kopie gebootet.
MIT, siehe LICENSE. Mach damit, was du willst.
Bei der Erstellung dieser Arbeit wurde stark auf LLM-Unterstützung zurückgegriffen. Das bedeutet nicht, dass der Autor keine Ahnung davon hat, was hier tatsächlich vor sich geht. Es war viel Gegenwind und manuelle Arbeit nötig, um überhaupt an diesen Punkt zu gelangen. Dir mögen die hingeschluderten Python-Artefakte oder was auch immer nicht gefallen, aber du wirst nicht das Argument entkräften können, dass deine Navi31-Karte jetzt plötzlich unsignierte Firmware-Komponenten-Blobs lädt. Danke für deine Aufmerksamkeit.