La Team Fail0verflow fait son retour sur la scène PS4, dans un article de blog publié sur son site internet officiel fail0verflow.com, le développeur ps5_enthusiast revient nous parler de hack de l'un des périphériques PS4 le plus connu, le PSVR.
L'équipe Fail0verflow explique avoir réussi à trouvé pas mal de défauts majeurs, lui permettant de casser le secure boot et d'extraire les clés matérielles. En s'attaquant au PSVR de la PS5, la Team a pour ambition de s'attaquer à celui de la PS5, Sony ayant annoncé lors de l'annonce de la PS5 qu'elle serait toujours compatible avec le PSVR de la PS4. A l'origine, le but était d'avoir un point d'entrée dans la PS5 au travers de ce périphérique PS4, un angle d'attaque différent de celui que l'on connait plus couramment basé sur un webkit exploit.
Bien qu'ils se ressemblent tous dans leur aspect extérieur, les PSVR ont évolués dans le temps, ainsi plusieurs révisions de la carte mère PSVR existent, mais elles portent toutes le même SoC Marvell 88DE3214 et partagent toutes la même clé matériel (ou du moins, les clés pertinentes pour le PSVR). La console hôte est connectée à la carte mère PSVR via un HDMI et un USB, qui finissent toutes deux par être traitées dans le Marvell 88DE3214. En fonctionnement normal, une séquence d'authentification est effectuée via l'USB avant que la console n'accepte l'appareil en tant que PSVR. L'objectif était donc d'extraire le code de cette authentification, et ainsi d'inverser le protocole de communication.
L'article proposé par Fail0verflow ne couvre que le SoC principal sur la carte mère du PSVR, car l'équipe se garde quelques billes dans le sac pour ne pas tout dévoiler à Sony.
La carte mère du PSVR
La Team explique avoir fouillé un peu sur la carte mère pour localiser les composants et les E/S intéressants et pour pouvoir dumper l'eMMC. La carte du PSVR démarre en mode basse consommation dès qu'elle est alimentée. Pour mettre la carte sous tension, il faut appuyer momentanément sur l'interrupteur d'alimentation du câble de commande du casque. Il s'agit de la broche 13 du connecteur, ainsi que d'une grande pastille de test de l'autre côté de la carte. La carte peut démarrer complètement et fonctionner sans dissipateur thermique mais le SoC devient relativement chaud. Après le démarrage complet, la carte apparaîtra comme un périphérique USB.
Les points d'entrée initiaux possibles
Les ports HDMI de la carte mère du PSVR pour la console et la télévision ont le CEC routé entre eux, probablement vers le SoC Marvell également. amp_devices_vpp_cec_isr dans les sources 88DE3214 semble avoir le même bug que le gestionnaire CEC EMC de la PS4.
Le kernel dispose du support USB (gadget) activé par défaut. Le périphérique Marvell 88E8080 est configuré pour agir comme un contrôleur USB DWC3 sur le PCIe (notez que l'Armada ne supporte que PCIe 2.0 1x). Cela signifie que les fonctions usb et usb-gadget sont exposées, ainsi que le DMA PCIe (l'Armada n'a pas de IOMMU).
Le kernel supporte aussi par défaut l'Ethernet via la puce Berlin, et le périphérique berlin-fe est activé par défaut. Il est probable que certains pads non occupés sur la carte soient Ethernet. Le pilote marvell/geth est utilisé pour cela. EHCI semble activé dans le kernel et pour le dts.
Tout cela est très bien, mais le meilleur point d'entrée reste le hack sur le PCIe, après avoir fait fonctionner la connexion, il est apparu que les périphériques PCIe externes ont un niveau d'accès surprenant sur le SoC. Bien sûr, il a un accès presque complet à la DRAM (à l'exception des régions marquées Secure pour TrustZone), mais il donne également accès aux SRAM utilisées pendant le démarrage des différents cores ARM, aux SRAM des cores périphériques, et la possibilité de lire/écrire tous les registres MMIO existant dans l'espace d'adresse physique du SoC. Cela a permis de dumper directement le bootrom et d'inverser l'implémentation du secure boot.
Après la création d'outils permettant d'introspecter et d'injecter le kernel Linux en cours d'exécution et de dumper les processus de l'espace utilisateur, il était évident qu'une compromission de la TrustZone serait nécessaire pour arriver au but ultime.
La fameuse TrustZone
L'inspection de l'interface TrustZone / linux a révélé de nombreuses vulnérabilités cependant, une seule était nécessaire pour dumper l'authentification PSVR.
La commande 0x22 de libdrmtz.ta semble s'appeler DrmDiag_LoadArmImg et/ou MV_IMAGETOOL_Decrypt_AES_FIGO. Elle prend l'adresse de chargement de destination comme paramètre (entre autres), et lui permet de pointer vers la mémoire du monde normal. Ainsi, les images ARM cryptées peuvent être décryptées et dumpées, donnant le texte en clair des TAs pour rechercher d'autres bugs, en plus de tous les secrets qui peuvent être divulgués en ayant un accès oracle de décryptage aux binaires de la TrustZone.
Il s'est avéré que cela était déjà suffisant pour récupérer les secrets utilisés par le PSVR, car ils sont contenus dans les TA et ne dépendent pas des secrets matériels.
Le FIGO, Luís, le FIGO
Cependant, il est possible d'aller plus loin et de dumper tout le matériel. À cette fin, il faut utiliser FIGO ("Flow Instructions Get Optimized" ; quel nom génial) qui est le coprocesseur sécurisé résidant dans le SoC. Bien qu'il ne contrôle pas directement le secure boot, il authentifie/décrypte les images chargées et peut être utilisé pour héberger et dériver des clés dans sa propre partie isolée du SoC. Bien qu'il dispose de périphériques IROM, DROM, fusibles, crypto, etc., il dispose également d'une DRAM et d'une IRAM pour prendre permettre le chargement et l'exécution de firmwares au moment de l'exécution. Ces microprogrammes ont tendance à être relativement petits et à gérer un ensemble limité de responsabilités par image.
Le FIGO est assez intéressant car il exécute un jeu d'instructions unique et parce qu'il cache des secrets protégés. Lorsque la Team Fail0verflow a initialement essayé de comprendre comment FIGO charge et authentifie le firmware, nous avons observé que pendant que l'IROM traite une demande de chargement d'image, certaines parties de la DRAM du FIGO sont déprotégées dans le MPU et visibles pour notre dispositif PCIe. Plus précisément, le format d'image traité par l'IROM a un en-tête contenant une clé enveloppée de rfc3394. L'IROM stocke les données utilisées pour effectuer le déballage AES à FIGO_BASE+0x1980 qui est visible dans le mappage MMIO pour notre dispositif PCIe lorsque l'IROM le traite. Cette clé déballée est utilisée pour décrypter le corps de l'image du firmware FIGO, ce qui nous a permis de décrypter et de commencer à inverser certains firmwares FIGO.
Un petit ROP
Alors que l'adresse de destination IRAM est supposée être IRAM+0, le décalage DRAM est configurable. Que se passe-t-il si nous forçons brutalement les décalages dans la DRAM jusqu'à ce que nous atteignions l'endroit où la pile de l'IROM doit se trouver ? Nous obtenons le ROP dans le contexte de l'IROM !
En inversant les firmwares FIGO décryptés à ce stade, la Team Fail0verflow a pu construire un petit shellcode pour dumper tous les fusibles, elle a aussi reconfiguré le MPU pour supprimer toutes les protections, permettant le dumping direct de l'IROM complet et du DROM (qui stocke également certaines clés) à partir du PCIe.
On le voit cette première approche du hack du PSVR par la Team Fail0verflow est dingue, et nous avons hâte de voir ce que tout cela peut donner que ce soit sur PS4 ou même plus tard sur PS5.
L'article intégral est disponible ici : Fail0verflow.com
.
.
