Homebrew, défier la sécurité de la Nintendo Switch

Si tout le monde a déjà entendu parler de “cracker” sa console de jeux vidéos, le grand public se rend rarement compte de la difficulté technique du développement d’un tel processus et les motivations des individus responsable de leur élaboration. Nous souhaitons dans cet article montrer à une audience possédant quelques notions d’informatique le travail, les communautés et les objectifs derrière les notions de homebrew, de hacks et de “crackage” de consoles via l’étude de cas de la Nintendo Switch.

Homebrew et Nintendo Switch

Le homebrew est le processus de création de logiciels et de jeux vidéos par des passionnés sur des plateformes au hardware propriétaire. Le terme hardware propriétaire signifie que ces plateformes ne sont pas sensé être programmable par l’utilisateur. C’est le cas de la plupart des consoles de jeux vidéos et des iPhones.

Les intérêts d’un système fermé pour Nintendo sont nombreux : lutte contre le piratage, faciliter la maintenance, bonne réputation de l’entreprise, etc.

Ces systèmes ont vu se développer des communautés de “hackers” de “homebrewers” et de “jailbreakers” importantes et talentueuses, en quête de la faille permettant d’exécuter du code “fait maison”.

Pour comprend le travail des hackers, ils est nécessaire de comprendre la structure de la Nintendo Switch. Son système d’exploitation, “Horizon”, est un système custom pour processeurs ARM, développé en interne pour la console portable précédente (la Nintendo 3ds) et retravaillé pour la Switch.

Son matériel est quant à lui construit autour d’un System on a Chip (SoC) Nvidia “TegraX1” custom, composé de :

• Deux CPU armV8 quadcore 64bit (dont un inutilisé et inaccessible)
• Un GPU Maxwell
• Un microprocesseur Nvidia Falcon dédié à la sécurité (TSEC)
• Un Boot and Power Management Processor (BPMP)

Trouver un point d’entrée

La première étape est d’entrer dans le système. Pour cela, les hackers regardent du côté des ouvertures du système sur l’extérieur. Les possibilités sont nombreuses :

• Les ports physiques (USB, jtag, bus uart ou i2c, connectique spécialisée, etc.)
• Les interfaces réseau (ethernet, wifi) et par extension toute la pile protocolaire associée.
• Les interactions logicielles (divers “bug” dans les interfaces du systèmes ou dans certains jeux vidéos)

Dans le cas de la Switch, deux points d’entrée ont été découverts dans les premiers mois suivant la sortie de la console.

Deux scénarios de compromission mentionnés ci-dessous : FuséeGelée et WebKit/PegaSwitch

Le Coldboot

Le point d’entrée le plus connu utilise une fonctionnalité du TegraX1, le centre névralgique de la Switch. Il utilise le coldboot, c’est à dire le démarrage de la console. Le TegraX1 a une fonctionnalité spéciale : le ReCovery Mode. C’est un mode de démarrage dans lequel le chip ne boot pas sur sa BootROM classique, mais attend une bootROM de récupération. Le principe est de délaisser le boot classique pour passer en RCM via une manipulation sur la Switch (le fameux coup du trombone). Il est alors possible de fournir une bootROM custom par le port USB de la Switch.

Ce point d’entrée est découvert en janvier 2018 par plusieurs teams (shofEL2 par fail0verflow, Fusée Gelée par ReSwitched, TeamXecutor). Ce point d’entrée est exceptionnel car cette ROM n’est pas patchable à distance par Nintendo : toutes les consoles en circulation avant avril 2018 sont donc vulnérables à vie.

WebKit et PegaSwitch

Une autre famille de points d’entrée est celle des vulnérabilités du moteur de rendu web utilisé par la Switch : WebKit. Ce moteur de rendu est le même que celui utilisé sur iPhone et une des premières failles exploitées sur la Switch est une faille qui avait été découverte et patchée sur iPhone auparavant. Cette similitude a permis le développement rapide par Re-Switched du toolkit PegaSwitch permettant aux hackers d’explorer WebKit et d’y trouver des failles jusqu’à la version 7.0.0 d’Horizon, bravant les patchs réguliers de Nintendo.

Les escalades de privilèges

Nous avons désormais un accès aux entrailles de la machine, mais ici, rien n’est simple. Le but est désormais d’arriver à exécuter du code arbitraire sur la machine.

Pour aller plus loin, il faut comprendre que la Switch permet trois niveaux de privilèges :

• user-space : c’est l’espace dans lequel sont lancés les jeux ou programmes (e.g. navigateur internet) accessibles à l’utilisateur lambda de la Switch. Le code lancé en user space doit être approuvé par Nintendo, et les accès sont très limités.
• kernel space : c’est là qu’est exécuté le système Horizon (gestion des périphériques, de la mémoire, des processus).
• trustZone : c’est le centre cryptographique de la Switch. Il sert à chiffrer/déchiffrer des programmes, gérer les DRM, vérifier les signatures Nintendo, etc.

Pour défendre la Switch, Nintendo à utilisé plusieurs méthodes :

1. L’opacité du système, qui consiste à faire un système original, non documenté voire volontairement abscons. Dans leur étude, Gauvanify et al. soulignent l’inutilité de cette pratique. Certes, les chercheurs mettent plus de temps à “éclairer” le système, mais l’opacité n’oppose aucune barrière et est dénuée d’intérêt du point de vue de la sécurité : ce n’est qu’une question de temps avant que tout le système ne soit documenté en détail [10]. De plus, le simple fait de cacher un élément peut en dire assez pour savoir dans quelle direction chercher.
2. Les réelles mitigations de hacks, qui sont des systèmes implémentés dans le but d’empêcher l’exécution de code arbitraire. Les principaux moyens employés dans le cas de la Switch sont le chiffrement des mémoires, le cloisonnement des processus, la vérification de la légitimité des programmes, etc. Toutefois, paradoxalement, ces mesures complexifient le code, agrandissant la surface d’attaque pour les hackers (cf B/warmboot ci-dessous).

En théorie, lancer du code arbitraire sur la Switch est impossible, car ledit code doit être signé par une clé privée de Nintendo. Cette légitimité est vérifiée par la trustZone, avant l’exécution du programme.

Coldboot : Root of Trust et Custom Recovery

Dans le cas de Fusée Gelée, les hackers font face à une difficulté majeure : une fois en RCM, si on tente d’envoyer un code de récupération fait maison, il est systématiquement refusé car non légitime, et la Switch ne démarre pas. Une des solutions trouvée consiste en un glitch hardware du tegra X1, qui permet d’accéder au binaire du code de vérification de légitimité de la bootROM. À partir de là, des hackers ont pu rétro-concevoir ce programme, puis trouver comment contourner ses règles d’acceptation de code. Donc de booter avec un code fait maison.

Le boot est la “root of trust”, c’est-à-dire que certaines clés utilisées dans le système cryptographique de la Switch sont générées à ce moment là. En maitrisant cette étape, les hackers peuvent donc exécuter du code arbitraire sur la Switch : victoire !

Webkit : Itérations et Warmboot

A contrario, dans le cadre d’un exploit du moteur web WebKit, le processus de boot n’est pas altéré. Exploiter une vulnérabilité du navigateur permet de lancer du code avec un niveau de privilèges “User Space”. Il faut donc répéter le processus de recherche et d’exploitation d’une vulnérabilité pour élever petit à petit ses privilèges afin de prendre le contrôle total de la console.

A titre d’exemple, la famille de vulnérabilités dite “Warmboot” (redémarrage depuis une veille profonde) permet souvent l’escalade du “kernel space” à la “trust zone”. La première implémentation de cette vulnérabilité est JamaisVu, découverte par SciresM de la team Re-Switched :

Lorsque la Switch se met en veille, les quatre processeurs principaux, le processeur TSEC, leurs registres et surtout la mémoire dédiée au processeur TSEC (la TZRAM) ne sont plus alimentés et perdent leur état. Leur contenu est donc copié par le processeur dédié au power management (le BPMP) dans la mémoire principale de la Switch (la DRAM). Lorque la Switch sort de veille, ces états sauvegardés sont restaurés par le BPMP. C’est par des modifications du programme tournant sur le BPMP qu’il est possible de restaurer non pas la TZRAM sauvegardée mais une TZRAM custom, donnant alors au hacker le contrôle sur la TrustZone, le plus haut niveau de privilège. Cette modification du programme tournant sur le BPMP est faite grâce à l’accès préalable au kernel space.

Cette méthodologie qui ne fonctionnait que sur la version 1.0.0 d’Horizon fut adaptée aux versions 2.0.0 à 4.0.0 sous le nom de DéjàVu (On trouve aussi dans la littérature les termes Nereba et Caffeine qui sont des implémentations de DéjàVu)

Une autre approche à l’éxecution de code sur la Switch sans altérer le processus de boot ni faire de l’escalade de privilèges est le Return Oriented Programming qui consiste à invoquer des fonctions préimplémentées dans la Switch qui, mises bout à bout, permettent au hacker de manipuler la console. Cette méthodologie a notamment servi à des fins d’exploration de la console depuis une faille WebKit et à la création de méthodes d’élévation de privilèges.

Et ensuite ?

La popularité de Fusée Gelée par sa caractéristique rare de faille non patchable et par sa découverte précoce a permis le développement de toute la scène homebrew de la Switch. Les logiciels actuellement développés sont entre autres un portage du noyau Linux et de distributions GNU/Linux et Android, la customisation de l’OS Horizon par la communautée (AtmosphereOS) mais aussi la popularisation de “chipset” illégales facilitant l’utilisation de jeux piratés telle que celle de la Team Xecutor actuellement en procès aux États-Unis.

Les autres exploits reste moins populaires car très dépendants de la version d’Horizon installée sur une console et Nintendo pousse par plusieurs stratagèmes les joueurs à maintenir leurs consoles à jour (notamment en limitant l’accès en ligne). Mise à part la vulnérabilité matérielle du tegra X1 sur les premiers modèles de Switch et les quelques vulnérabilités WebKit la Nintendo Switch reste un fort de sécurité. La séparation des privilèges et le système cryptographique y sont bien mieux implémentées que sur les précédentes consoles de Nintendo et la Switch possède quelques innovations en terme de sécurité telle qu’une “mémoire à fusible” non réinscriptible pour empêcher les changements de versions non autorisés (Downgrading)