Il developer Mike Heskin (noto come @hexkyz) ha condiviso dettagli importanti sul social X riguardo al linker Mig Switch, cercando di dissipare la confusione riguardante l’utilizzo della flashcard.
Vi è ancora una certavconfusione riguardo alla questione delle flashcard, Questo è comprensibile, dato quanto siano vaghi i produttori riguardo a cosa possono o non possono fare.
I'm seeing a lot of confusion around the flashcart thing which is understandable given how (likely deliberately) vague they are being on what it can or can't do. I'll try to cover here a few facts known about the Gamecard ecosystem in general that may provide some answers. (1/20)
— Mike Heskin (@hexkyz) January 25, 2024
Innanzitutto, non è possibile modificare in alcun modo un’immagine legittima di una Gamecard (XCI). I file XCI utilizzano un sistema di file basato su hash in cui ogni singolo file ha i suoi contenuti hashati e un hash di tutti i loro hash si trova memorizzato nell’intestazione della partizione.
Pertanto, una modifica ai contenuti di un’immagine richiede il ricalcolo degli hash pertinenti, il che sembra abbastanza semplice, eccetto che un hash dell’intestazione della partizione (che contiene un hash di tutti gli hash dei file) è incluso nella regione CardHeader (i primi 0x200 byte).
Questa regione è firmata (RSA-2048) e la sua firma è verificata dal Lotus ASIC. A meno che non si abbia la chiave privata necessaria per rifirmare questa regione CardHeader, lì è game over.
Probabilmente va detto, ma tutte e qualsiasi chiavi private RSA di livello di produzione sono conosciute solo da Nintendo. Non è possibile “calcolarle”, non sono state divulgate in alcun modo e se per qualche motivo la flashcart avesse effettivamente la chiave, non avrebbe affatto bisogno della regione InitialData.
Questo significa che il supporto per contenuti DLC e aggiornamenti (a meno che la cartuccia non li includa legittimamente) o homebrew non è semplicemente possibile.
L’altro grande argomento sembra essere la rilevazione. Come previsto, i revisori hanno già scoperto che è possibile utilizzare lo stesso certificato per qualsiasi immagine XCI, che è chiaramente il principale punto di vendita di questa flashcart nonostante i suoi creatori siano attenti a non affermarlo esplicitamente per evitare reazioni negative.
Da notare che tutte le copie di un singolo gioco condividono le stesse regioni CardHeader e InitialData, ma diverse copie dello stesso gioco hanno regioni CertArea diverse e, come è, sembra che nulla verifichi se un certificato appartiene al gioco per cui è stato emesso.
Per quanto riguarda l’accesso al gioco online, Nintendo ha l’infrastruttura per rilevare se un dato certificato viene utilizzato più di una volta nello stesso momento.
Possono anche rilevare se un certificato appartiene a una cartuccia di gioco fisica dalla versione del firmware 9.0.0 in poi (aggiunta in risposta all’emulazione SX del Lotus ASIC).
Per quanto riguarda l’uso di un certificato che non corrisponde al gioco per cui è stato emesso, le richieste di rete per l’autenticazione del certificato della cartuccia di gioco si assicurano di includere l’ID dell’applicazione in uso, quindi ciò è facilmente visibile a Nintendo.
Ci sono anche alcuni dettagli che non sembrano essere stati ancora discussi. Ad esempio, il sistema operativo tiene traccia di quante volte viene inserita e rimossa una cartuccia di gioco, il che è chiaramente un problema poiché la flashcart ti obbliga ad inserire e rimuovere per passare attraverso i giochi.
Con un Custom Firmware si ha invece un certo controllo sui dati telemetrici, ma da firmware HOS originale non si ha alcun controllo.
Anche se si bloccano i domini per la segnalazione degli errori (che sono i più verbosi), semplicemente non si può fare nulla riguardo alle segnalazioni di sistema (“srepo”) che includono informazioni sulla cartuccia di gioco.
Ciò porta all’ultimo punto riguardante quale tipo di rilevamento e prevenzione esiste offline, che è anche il motivo per cui i creatori della flashcart stanno prestando molta attenzione alle loro parole.
Ad esempio, attualmente solo 16 byte su 208 dalla regione criptata di un certificato di cartuccia di gioco sono utilizzati (per derivare la chiave di comunicazione).
Nessuno sa realmente se i byte rimanenti abbiano correlazione con le regioni InitialData o CardHeader. Se si scopre che effettivamente c’è una correlazione, allora lo scenario attuale di utilizzo dello stesso certificato per immagini XCI diverse diventa correggibile offline.
Ci sono molte altre modalità con cui questo può essere rilevato e bloccato sia a livello di sistema operativo che Lotus.
Ironia della sorte, il caso in cui la flashcart potrebbe non essere in grado di essere corretta o rilevata è se la si utilizza solo per contenere copie di giochi legittimi (certificato corrispondente al gioco e tutto ciò) e non si passa attraverso di essi.
Un altro argomento extra riguarda come questo potrebbe influenzare la retrocompatibilità in una prossima console Switch. Come già detto in precedenza, è sempre esistito un secondo schema di sicurezza in standby proprio perché Nintendo era consapevole dei punti deboli del primo.
Ciò significa che le prossime gamecard potrebbero essere sicure, ma quelle attuali hanno già avuto il loro schema di crittografia hardware violato.
Switch 2, come viene chiamata oggi, verrà lanciata quest’anno, stando almeno ai numerosi rumors, si pensa che la retrocompatibilità con le attuali gamecard della prima Switch sarà garantita (cioè hardware futuro in grado di leggere le gamecard Switch).
Vero anche che ci sono stati alcuni cambiamenti recenti nell’ecosistema Gamecard/Lotus che suggeriscono come lo stesso hardware sarebbe stato utilizzato in una nuova console e sembra improbabile che ciò cambi (specialmente dato l’esistenza di un secondo schema di sicurezza).
Tuttavia, è completamente possibile che l’hardware futuro ora costringa gli utenti a verificare le vecchie gamecard online per assicurarne la legittimità.
Fonte: twitter.com
ottimo articolo