[Switch 1/ Switch2] Un nouvelle exploit userland trouvé par Gezine mais...

Le développeur Gezine, auteur des principaux hack sur PS4/5 nous dévoile une information importante par le biais de sont compter Twitter concernant la Nintendo Switch 1 / Switch 2

I created switch 1/2 userland exploit that is not webkit or save exploit

"But we already have userland exploit from day 1"
The difference is existing userland exploit is based on save exploit which can't be used without save transfer using Nintendo Online Service

Which forces… pic.twitter.com/7gNuaYXiIS

— Gezine (@gezine_dev) July 8, 2026

Il nous dévoile donc qu'il a trouvé un exploit userland qui fonctionne sur Nintendo Switch et Nintendo Switch 2, si on a déjà eu un exploit userland avec une chaîne d'éxecution ROP a la sorti de la console, cette dernière nécessitais la récupération de donnée de sauvegarde altéré qui permettais sont éxecution, ce qui par conséquent nécessitais toujours la dernière version du firmware pour être transféré.

L'exploit de Gezine n'a ni besoin d'un Exploit Webkit ni d'un exploit de donnée de sauvegarde nécessitant le Nintendo Switch Online.
Mais du coup quand est-il du point d'entrée et pourquoi Gezine ne veux pas d'un Exploit Webkit, ce qui est principalement utilisé sur PS4/5

Pour comprendre il faut s'intéressé plus amplement a comment fonctionne la Nintendo Switch 2 en terme de sécurité, Nintendo n'a pas lésiner sur les moyens de protection.
Prenons en exemple un code en c

void A() {
    B();
}

void B() {
    printf("Hello");
}

En mémoire, ça ressemble à quelque chose comme :

0x1000 -> Fonction A
0x2000 -> Fonction B
0x3000 -> printf

Quand A() appelle B(), le CPU fait essentiellement :
PC = 0x2000
Le Program Counter (PC) contient donc l'adresse de la prochaine instruction à exécuter.

C'est la qu'entre en jeu le Pointer Authentication (PAC)

PAC protège les pointeurs.

Fonction B
Adresse :
0x2000

Avec PAC, ce n'est plus seulement :

0x2000

mais quelque chose comme :

0x2000 + Signature

Cette signature est calculée par le CPU avec une clé secrète stockée dans les registres matériels.
Le CPU fait en interne quelque chose du genre :

Signature = f(Adresse, Clé secrète)

Donc le pointeur devient :

0x2000 | PAC

Quand le programme veut appeler cette fonction : BLR x0

Adresse ? => 0x2000 => Signature valide ? => Oui => Exécution.

Ce que PAC empêche

- une adresse de retour
- un pointeur de fonction
- une vtable C++
- certains pointeurs internes : sans posséder la bonne signature.

Mais Nintendo ne c'est pas arrêter la, ils ont intégré également le Control Flow Integrity (CFI)

PAC vérifie que le pointeur est authentique.
CFI vérifie que l'appel est autorisé.
Prenons 

void Login()
{
    CheckPassword();
}


void DeleteAllFiles()
{
}

Le compilateur sait que : 

Login() =>CheckPassword()

Mais cela est impossible : 

Login() => DeleteAllFiles()

Avec CFI, le compilateur ajoute des vérifications.
Même si un attaquant arrive à modifier un pointeur...

...le programme regarde :

"Cette fonction fait-elle partie des destinations possibles ?"

Si la réponse est non :
Crash.

Mais Nintendo a été encore plus loin

Execute Only Memory, c'est la sécurité implémenté sur le firmware 21.x

Normalement, une page mémoire contenant du code est :

RX

Read
Execute

Donc un exploit peut faire :

memcpy(buffer, fonction, 100);

et copier le code.

Avec XOM :

--X

Execute seulement

Le CPU accepte :

PC = 0x5000

Mais refuse :

LDR x0, [0x5000]

Lire .text => Chercher des gadgets => Construire un ROP