blasty/wake-and-breakExploit PSP pour les GPU AMD navi31 (RX 7900) qui désactive les vérifications de signature du firmware afin que la carte charge des firmwares SMU, SDMA, MEC, IMU et RLC non signés ; non persistant après un démarrage à froid.
Un exploit PSP (Platform Security Processor) pour les cartes AMD navi31 (série RX 7900). Probablement adaptable à d'autres familles de produits adjacentes également.
Il désactive la vérification de signature du firmware du PSP, de sorte que la carte chargera un firmware IP non signé (SMU, SDMA, MEC, IMU, RLC) qu'elle refuserait autrement. Pensez gestion personnalisée de l'alimentation, limites d'horloge, ou tout ce qui réside dans un firmware signé par le vendeur et que vous ne contrôlez pas.
Rien n'est flashé. Le patch réside dans la mémoire du PSP et est appliqué lors d'un warm boot ; un cycle d'alimentation à froid l'efface et la carte redevient d'origine. Ce warm boot est le « Wake and Break » : la carte se réveille, nous la convainquons de monter très haut immédiatement et la contraignons à neutraliser les vérifications de signature. :-)
Testé sur une carte RX 7900 XTX. Voir Status.
python3 wakebreak.py 25=/path/to/firmware.bin
Cela applique le patch, effectue un warm-boot de la carte et soumet votre image en tant que firmware de type 25. S'il affiche accepted, le PSP a accepté une image qu'il aurait normalement rejetée.
Besoin de quelque chose pour l'essayer ? ipfw_images.py liste le firmware que votre pilote charge réellement et écrit une paire de test — une image authentique et une copie avec un bit inversé dans sa signature, de sorte que le firmware lui-même soit identique octet pour octet :
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
Le firmware d'origine rejette fw_25_bad.bin. Avec le correctif en place, il est accepté.
C'est toute la démonstration.
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
Vous avez besoin d'un hôte Linux avec la carte accessible via le pilote AMD de
tinygrad (PCIe ou son pont USB).
Consultez requirements.txt pour un correctif tinygrad dont votre hôte a besoin.
Il existe quatre versions connues du firmware navi31, et le correctif doit correspondre.
Le profil a est celui par défaut et couvre le plus courant. Si vous disposez d'un dump
de la mémoire flash SPI de votre carte, identify.py vous indiquera :
python3 identify.py FLASH.bin
# -> sos-build c: wakebreak.py --sos-build c
Sinon, essayez-les simplement. Se tromper n'est pas dangereux : le patch vérifie ce qu'il est sur le point de modifier, découvre quelque chose qu'il ne reconnaît pas, n'écrit rien, et la carte démarre normalement.
python3 wakebreak.py --sos-build c 25=/tmp/fw_25_bad.bin
Confirmé sur la carte testée (RX 7900 XTX, profil a) :
| firmware altéré, carte d'origine | rejeté |
| firmware altéré, patché | accepté |
| après un cycle d'alimentation à froid | rejeté à nouveau — la carte est d'origine |
REMARQUE : Les profils b, c et d sont compilés et vérifiés hors ligne mais n'ont jamais été exécutés sur du matériel. Si vous possédez une carte correspondant au profil b, c ou d, merci de signaler si cela fonctionne !
Le patch lui-même représente quelques centaines d'octets d'assembleur ARM, dans hook/*.S. Les blobs compilés sont fournis avec le dépôt, vous n'avez donc pas besoin d'un compilateur croisé pour l'utiliser. Si vous souhaitez tout de même les recompiler :
make rebuild # needs arm-none-eabi binutils
make rebuild CROSS=/path/to/arm-none-eabi-
Le build refuse d'installer tout ce dont le hash ne correspond pas aux octets qui ont été testés sur une carte, ainsi une chaîne d'outils différente ne peut pas modifier discrètement ce qui est écrit sur votre 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/ contient des images AMD publiques non modifiées. Ce sont d'anciennes versions, conservées parce que le chemin d'accès passe par elles.
Volontairement non couvert ici : lisez le code. wakebreak.py fait environ 600 lignes commentées et les commentaires expliquent le mécanisme, les contrôles de sécurité et pourquoi chaque étape est ordonnée comme elle l'est. TL;DR: deux applications de confiance AMD d'origine sont chargées, l'une d'elles est amenée à exécuter une chaîne capable d'écrire dans la mémoire du PSP, le patch est placé dans la copie résidente du bootloader, puis la carte est réamorcée à chaud dessus.
MIT, voir LICENSE. Faites-en ce que vous voulez.
Une assistance intensive de LLM a été utilisée pour produire ce travail. Cela ne signifie pas que l'auteur n'a aucune idée de ce qui se passe réellement ici. beaucoup de résistance et de travail manuel ont été nécessaires pour arriver ne serait-ce qu'à ce stade. Vous n'aimerez peut-être pas les artefacts Python bâclés ou quoi que ce soit d'autre, mais vous ne pourrez pas contester le fait que votre carte Navi31 charge désormais soudainement des blobs de composants de firmware non signés. Merci de votre attention.