Jailbreak Switch 2 : la faille FS de ns2jb expliquée
Par Tgames · · 4 min de lecture
Comment ns2jb passe de SmileBASIC au système de fichiers de la Switch 2 : un dépassement d’entier, un débordement de tampon, une signature contournée.
Trois étapes, d’un jeu Switch 1 au module fs
Dans son billet du 18 octobre 2026, publié avec le jailbreak le 22, pepsipu (Sammy Hajhamid) décrit toute la chaîne de ns2jb. L’auteur a fait chercher les failles à Codex, l’agent de programmation d’OpenAI, et précise que le jailbreak lui a demandé deux semaines de travail. En résumé :
1. SmileBASIC : un calcul qui déborde
pepsipu a écarté le navigateur de la Switch 2 : WebKit y est protégé par de la mémoire en exécution seule, des pointeurs signés (PAC) et un contrôle des appels (CFI). Un jeu Switch 1 est plus vulnérable, car la Switch 1 ne connaît pas PAC, et son code se déchiffre puisque la console est entièrement piratée. SmileBASIC avait déjà été exploité sur 3DS (smilehax).
La faille est dans la commande REMOVE, qui retire des éléments d’un tableau. Elle vérifie que « position + nombre » ne dépasse pas la taille du tableau, mais ce calcul se fait sur 32 bits et peut déborder en nombre négatif. Avec REMOVE R,&H60000000,&H3FFFFFFF, le contrôle passe, et la copie qui suit tire dans le tableau les 8 octets placés juste avant lui en mémoire. Or ces 8 octets contiennent un pointeur vers le tableau lui-même : le premier élément devient une chaîne de caractères d’une longueur gigantesque, qui permet de lire et d’écrire hors du tableau. C’est le « Out of memory » qu’on voit pendant le lancement de ns2jb : l’erreur arrive après la copie.
2. Le module fs : un tampon de 0x301 octets
fs gère tous les accès aux fichiers, et c’est lui qui sert le code déchiffré des programmes au chargeur. Sa faille est dans la normalisation des chemins. Quand un chemin contient un retour au dossier parent écrit avec une barre oblique inverse, comme « /..\ », une fonction réserve un tampon temporaire de 0x301 octets (769) et y copie le chemin, sans vérifier sa longueur. pepsipu résume : « lol ».
Le débordement atteint une structure voisine : le cache d’un fichier ouvert (BufferedStorage). En réécrivant le pointeur de ce cache, les lectures et écritures du fichier vont où l’on veut : c’est un accès en lecture et en écriture à toute la mémoire de fs. pepsipu cherche alors la connexion de SmileBASIC dans cette mémoire et change son identifiant de processus en 1. fs le traite dès lors avec la « FullPermission » : tout le système de fichiers est accessible. C’est ce qui lui a permis de copier le stockage interne, et ce qui permet aujourd’hui les premiers dumps de jeux.
3. La signature contournée par une substitution
Pour lancer un programme, le chargeur (ldr) demande à fs d’ouvrir son système de fichiers « ExeFS », qui contient l’exécutable et ses permissions (main.npdm). Il vérifie deux signatures : celle de Nintendo sur les permissions, et celle du développeur sur l’en-tête du paquet. La chaîne est solide, à une condition : que fs serve bien les fichiers correspondant à cet en-tête.
Or fs est sous contrôle. ns2jb laisse fs envoyer l’en-tête et la signature d’un vrai programme, puis, au bon moment, remplace le système de fichiers servi au chargeur par le sien : le vrai main.npdm, mais un exécutable de son choix. Pour que l’échange tombe entre les deux demandes du chargeur, il remplace aussi l’événement qu’attend fs par un événement que SmileBASIC déclenche lui-même.
pepsipu emprunte enfin les permissions de ro, le seul module ordinaire autorisé à créer du code exécutable. Son programme ouvre alors une vue modifiable du code de fs et le corrige à chaud.
Ce qui manque encore
Sources : Billet de pepsipu · ns2jb (GitLab)
Trois étapes, d’un jeu Switch 1 au module fs
Dans son billet du 18 octobre 2026, publié avec le jailbreak le 22, pepsipu (Sammy Hajhamid) décrit toute la chaîne de ns2jb. L’auteur a fait chercher les failles à Codex, l’agent de programmation d’OpenAI, et précise que le jailbreak lui a demandé deux semaines de travail. En résumé :
- exécuter du code dans SmileBASIC 4, un logiciel Switch 1 qui tourne aussi sur Switch 2 ;
- corrompre la mémoire du module système fs, qui gère les fichiers de la console ;
- s’en servir pour faire lancer son propre code avec les droits d’un module système.
1. SmileBASIC : un calcul qui déborde
pepsipu a écarté le navigateur de la Switch 2 : WebKit y est protégé par de la mémoire en exécution seule, des pointeurs signés (PAC) et un contrôle des appels (CFI). Un jeu Switch 1 est plus vulnérable, car la Switch 1 ne connaît pas PAC, et son code se déchiffre puisque la console est entièrement piratée. SmileBASIC avait déjà été exploité sur 3DS (smilehax).
La faille est dans la commande REMOVE, qui retire des éléments d’un tableau. Elle vérifie que « position + nombre » ne dépasse pas la taille du tableau, mais ce calcul se fait sur 32 bits et peut déborder en nombre négatif. Avec REMOVE R,&H60000000,&H3FFFFFFF, le contrôle passe, et la copie qui suit tire dans le tableau les 8 octets placés juste avant lui en mémoire. Or ces 8 octets contiennent un pointeur vers le tableau lui-même : le premier élément devient une chaîne de caractères d’une longueur gigantesque, qui permet de lire et d’écrire hors du tableau. C’est le « Out of memory » qu’on voit pendant le lancement de ns2jb : l’erreur arrive après la copie.
2. Le module fs : un tampon de 0x301 octets
fs gère tous les accès aux fichiers, et c’est lui qui sert le code déchiffré des programmes au chargeur. Sa faille est dans la normalisation des chemins. Quand un chemin contient un retour au dossier parent écrit avec une barre oblique inverse, comme « /..\ », une fonction réserve un tampon temporaire de 0x301 octets (769) et y copie le chemin, sans vérifier sa longueur. pepsipu résume : « lol ».
Le débordement atteint une structure voisine : le cache d’un fichier ouvert (BufferedStorage). En réécrivant le pointeur de ce cache, les lectures et écritures du fichier vont où l’on veut : c’est un accès en lecture et en écriture à toute la mémoire de fs. pepsipu cherche alors la connexion de SmileBASIC dans cette mémoire et change son identifiant de processus en 1. fs le traite dès lors avec la « FullPermission » : tout le système de fichiers est accessible. C’est ce qui lui a permis de copier le stockage interne, et ce qui permet aujourd’hui les premiers dumps de jeux.
3. La signature contournée par une substitution
Pour lancer un programme, le chargeur (ldr) demande à fs d’ouvrir son système de fichiers « ExeFS », qui contient l’exécutable et ses permissions (main.npdm). Il vérifie deux signatures : celle de Nintendo sur les permissions, et celle du développeur sur l’en-tête du paquet. La chaîne est solide, à une condition : que fs serve bien les fichiers correspondant à cet en-tête.
Or fs est sous contrôle. ns2jb laisse fs envoyer l’en-tête et la signature d’un vrai programme, puis, au bon moment, remplace le système de fichiers servi au chargeur par le sien : le vrai main.npdm, mais un exécutable de son choix. Pour que l’échange tombe entre les deux demandes du chargeur, il remplace aussi l’événement qu’attend fs par un événement que SmileBASIC déclenche lui-même.
pepsipu emprunte enfin les permissions de ro, le seul module ordinaire autorisé à créer du code exécutable. Son programme ouvre alors une vue modifiable du code de fs et le corrige à chaud.
Ce qui manque encore
- le jailbreak est tethered : il faut tout refaire à chaque démarrage, depuis SmileBASIC et un ordinateur ;
- seul fs est compromis parmi les modules intégrés au système : il n’y a pas de custom firmware ;
- la faille de fs, elle, ne dépend pas de SmileBASIC. pepsipu suggère de l’exploiter depuis le navigateur, que Nintendo ne peut pas retirer comme un jeu de l’eShop ;
- la chaîne fonctionne aussi sur la Switch 1, sans matériel ajouté, mais l’auteur ne l’a pas encore publiée pour elle.
Sources : Billet de pepsipu · ns2jb (GitLab)
Aucun commentaire