Switch 2 e ns2jb: il BASIC è la porta, il filesystem è il problema

Puoi firmare un programma, verificarne i metadati e progettare una catena di avvio che sulla carta sembra inattaccabile. Poi scopri che uno dei servizi incaricati di consegnare i file al componente che li verifica può essere manipolato. La crittografia continua a fare il suo lavoro; è il contesto attorno alla verifica a non essere più affidabile. È questa, molto più della parola “jailbreak”, la parte interessante di ns2jb, la ricerca pubblicata nell’ottobre 2026 sulla Nintendo Switch 2.

La storia è stata raccontata anche come un exploit realizzato dall’intelligenza artificiale, oppure come la prova che basti un vecchio interprete BASIC per aprire una console moderna. Sono entrambe scorciatoie comode. Il caso reale è più istruttivo: una catena di problemi in componenti diversi, un ricercatore che ne costruisce il percorso e un assistente AI che accelera alcune esplorazioni senza sostituire le decisioni architetturali.

Una porta piccola può aprire un perimetro grande

Il ricercatore Sammy Hajhamid, noto come pepsipu, descrive ns2jb nella propria analisi tecnica come un jailbreak esclusivamente software, tethered, dimostrato su firmware 23.0.1. Il punto di partenza è SmileBASIC 4, un ambiente di programmazione nato per la prima Switch ed eseguibile sulla seconda grazie alla compatibilità. Non serve aprire la console né installare un modchip per la dimostrazione descritta, ma il risultato non è permanente.

La vulnerabilità iniziale riguarda un errore aritmetico a 32 bit nella gestione degli array dell’interprete. In termini generali, un calcolo che supera l’intervallo rappresentabile può produrre un valore incoerente con quello atteso dal controllo di validità. Da lì il ricercatore ottiene una primitiva di lettura e scrittura fuori dai limiti previsti. Non è il BASIC come linguaggio a essere “insicuro” per definizione: è una specifica implementazione, con una specifica gestione della memoria, ad avere un difetto sfruttabile.

Questo dettaglio cambia la lettura dell’incidente. Un’applicazione che dovrebbe essere confinata nel proprio spazio diventa un punto d’appoggio per interagire con servizi di sistema. Il salto di privilegio non è automatico: richiede altri problemi, altre assunzioni sbagliate e un lavoro di concatenazione. Ma la superficie di attacco non coincide più con la funzione per cui l’applicazione era stata progettata.

Il confine non cede dove si vede il bug

Dopo l’accesso iniziale, la ricerca si concentra sul servizio filesystem della console, indicato come fs. Qui l’autore documenta un ulteriore problema di gestione della memoria legato alla normalizzazione dei percorsi. Il risultato, nella catena descritta, è la possibilità di intervenire sul comportamento di un servizio con privilegi maggiori rispetto a un gioco ordinario. È il passaggio che rende l’episodio interessante per chi progetta sistemi, anche se non ha mai modificato una console.

Un sistema complesso vive di deleghe: il processo A chiede al servizio B di aprire un contenuto; B restituisce dati e informazioni che A utilizza per decidere se procedere. Se B viene compromesso, non basta che A controlli correttamente una firma su informazioni che B gli presenta. Bisogna sapere quale parte del dato verificato è davvero vincolata al contenuto che verrà eseguito, e chi può cambiare quella relazione lungo il percorso.

Nella descrizione di pepsipu, il caricatore dei programmi esegue controlli sulle firme e sui metadati degli archivi software. Ma il servizio filesystem è anche responsabile di servire il contenuto eseguibile. La ricerca mostra che, alterando il comportamento di quel servizio, è possibile separare ciò che il caricatore ritiene di avere verificato da ciò che finisce effettivamente per caricare. La firma non viene “rotta” matematicamente: viene meno l’assunzione di integrità sulla catena che collega la verifica ai byte utilizzati.

Una verifica crittografica non mette al sicuro un sistema se il componente che consegna i dati può cambiare ciò che viene verificato dopo, o fuori, dal perimetro della verifica.

Il problema, in altre parole, è una frattura nel confine di fiducia. È lo stesso tipo di domanda che conta in una piattaforma web, in una pipeline di build o in un’infrastruttura di agenti: quale componente produce l’evidenza, quale la controlla e chi può intervenire tra le due operazioni? Ne avevo già esplorato la logica parlando dei confini di fiducia nelle applicazioni Django. Cambiano i componenti; non cambia la necessità di capire dove termina una garanzia e dove inizia un’ipotesi.

Un jailbreak non è un interruttore acceso o spento

Una parte dei titoli su ns2jb usa “console violata” come se esistesse un unico livello di controllo. In realtà, la ricerca distingue accesso in userland, capacità di operare con i permessi di moduli di sistema ordinari e interventi sul modulo fs. Sono risultati significativi, ma non equivalgono a un compromesso generale del kernel, a un custom firmware persistente o al controllo indistinto di ogni protezione hardware.

La dimostrazione consente, secondo l’autore, di eseguire codice nativo con i privilegi di determinati moduli, sperimentare con software homebrew, analizzare e modificare giochi e lavorare sui salvataggi. È stata mostrata anche una modifica a Mario Kart World. La ricostruzione di Ars Technica del 22 ottobre sottolinea proprio il limite rispetto al controllo completo della console.

Inoltre tethered significa che il meccanismo deve essere riattivato dopo un riavvio. Il firmware citato è 23.0.1: non c’è motivo di estendere automaticamente il risultato a versioni successive o a ogni configurazione possibile. Anche il termine “primo” va letto come rivendicazione dell’autore rispetto alle dimostrazioni pubbliche note, non come prova che nessuno avesse mai trovato un percorso simile in privato.

Per chi lavora in sicurezza questa distinzione non è pignoleria lessicale. Serve a valutare la gravità reale di una vulnerabilità, le mitigazioni che restano attive e l’impatto che può avere un aggiornamento. Un problema in software aggiornabile ha una traiettoria di correzione diversa da un difetto in una ROM non modificabile. Ma prevedere tempi e modalità delle contromisure senza un annuncio ufficiale sarebbe soltanto una scommessa.

Codex ha aiutato. Non ha progettato da solo la catena

C’è poi la seconda storia, quella che si presta meglio ai titoli facili: l’AI avrebbe hackerato Switch 2. Hajhamid racconta di aver costruito un banco di prova in cui gli agenti potevano inviare input alle console, osservarne l’uscita video e persino gestire il riavvio fisico dopo un crash. È un esempio concreto di hardware-in-the-loop: l’agente non si limita a generare testo o codice, ma interagisce con un sistema reale attraverso strumenti predisposti da qualcuno.

Codex ha individuato il problema aritmetico in SmileBASIC e ha contribuito a esperimenti, analisi e dimostrazioni. L’autore, però, chiarisce che il tentativo iniziale di far trovare all’agente autonomamente un jailbreak non è riuscito. La catena finale ha richiesto circa due settimane di lavoro sostanziale e decisioni umane, compresa la scelta di studiare il servizio filesystem. Il modding dimostrativo di Mario Kart World, realizzato più rapidamente, è un risultato diverso dalla scoperta della catena di vulnerabilità.

La differenza è enorme: automatizzare gli esperimenti non significa delegare la strategia di ricerca. Bisogna decidere che cosa misurare, come riprodurre un crash, come recuperare un dispositivo, quali ipotesi scartare e quando un segnale è abbastanza affidabile da cambiare direzione. Senza questo impianto, anche un agente molto capace può produrre migliaia di tentativi e pochissima conoscenza verificabile.

È un tema che riguarda direttamente l’ingegneria del software. Quando un sistema autonomo attraversa strumenti e servizi, il valore non è soltanto nel modello che genera il prossimo comando, ma nei confini e nelle verifiche che rendono il risultato osservabile. La stessa distinzione emerge nel caso della sandbox e del perimetro DNS degli agenti: dare accesso a uno strumento non significa aver definito correttamente il perimetro di fiducia.

La lezione utile non riguarda soltanto Nintendo

Chi costruisce piattaforme tende a ragionare per componenti: questo servizio autentica, quell’altro verifica, un terzo carica e un quarto esegue. Il diagramma può essere impeccabile e ogni componente può perfino rispettare la propria interfaccia. Il problema nasce quando il contratto tra due componenti contiene un’assunzione che nessuno ha verificato fino in fondo.

Nel caso ns2jb, l’errore iniziale in un interprete compatibile con una generazione precedente ha aperto una strada. La parte decisiva, però, è stata l’interazione con il servizio che collega contenuti, metadati e caricamento del codice. È lì che un difetto locale è diventato una questione di architettura. E non c’è alcun bisogno di trasformare il caso in una guida pratica all’exploit per capire la lezione.

Tre domande restano valide in qualunque sistema: il dato che verifico è esattamente quello che utilizzerò? Il servizio che me lo consegna può essere compromesso senza che io me ne accorga? E quando automatizzo la ricerca o l’operatività con un agente, chi controlla che la conclusione sia sostenuta da evidenze riproducibili? Se non sai rispondere, non hai un perimetro di fiducia: hai una serie di componenti che sperano di potersi fidare l’uno dell’altro.

ns2jb è una ricerca notevole per ciò che documenta, non per la caricatura secondo cui un modello AI avrebbe “aperto” da solo una console. Il risultato più interessante è un promemoria molto meno spettacolare e molto più utile: la sicurezza non si misura contando quante firme o quante sandbox hai messo nel diagramma. Si misura seguendo il dato fino al punto in cui viene davvero usato.