Le développeur Mike Heskin connu de la scène 3DS, Wii et Switch sous le pseudonyme Hexkyz a écrit de longs billets sur le Mig Switch, informant ou donnant son avis sur ce nouveau linker.
La première des choses qu'il dit autour de ce linker est qu'il subsiste beaucoup de confusions autour de lui, " ce qui est compréhensible étant donné à quel point (probablement délibérément) ils sont vagues sur ce qu'il peut ou ne peut pas faire. Ainsi il a essayé de couvrir ici quelques faits connus sur la Gamecard, l’écosystème en général qui peut apporter des réponses.
Tout d’abord, il n’est pas possible de modifier de quelque manière que ce soit une image Gamecard (XCI) légitime. Les XCI utilisent un système de fichiers basés sur le hachage dans lequel le contenu de chaque fichier est haché et un hachage de tous leurs hachages est stocké dans l'en-tête de la partition.
Par conséquent, une modification du contenu d'une image nécessite le recalcul des hachages pertinents, ce qui semble assez simple, sauf qu'un hachage de l'en-tête de la partition (qui contient un hachage des hachages de tous les fichiers) est inclus dans la région CardHeader (les 0x200 premiers octets).
Cette région est signée (RSA-2048) et sa signature est vérifiée par Lotus ASIC. À moins que vous ne disposiez de la clé privée nécessaire pour re-signer cette région CardHeader, la partie est terminée ici.
Cela va probablement sans dire, mais toutes les clés privées RSA de niveau production ne sont connues que par Nintendo. Vous ne pouvez pas les "calculer", ils n'ont pas été divulgués à quelque titre que ce soit et si, d'une manière ou d'une autre, le linker avait réellement la clé, il n'aurait pas du tout besoin de la région InitialData.
Cela signifie que la prise en charge du contenu DLC et des mises à jour (sauf si le jeu est légitime) ou des homebrews n'est tout simplement pas possible.
L’autre grand sujet semble être la détection. Comme prévu, les testeurs ont déjà compris que vous pouvez utiliser le même certificat pour n'importe quelle image XCI, ce qui est clairement le principal argument de vente de ce linker, même si ses créateurs ont pris soin de ne pas le déclarer ouvertement pour éviter les réactions négatives.
Notez que toutes les copies d'un même jeu partagent les mêmes régions CardHeader et InitialData, mais différentes copies du même jeu ont des régions CertArea différentes et, dans l'état actuel des choses, rien ne semble vérifier si un certificat appartient au jeu pour lequel il a été émis.
En ligne, Nintendo dispose de l'infrastructure nécessaire pour détecter si un certificat donné est utilisé plusieurs fois en même temps. Ils peuvent également détecter si un certificat appartient à une carte de jeu physique à partir du firmware 9.0.0 (ajouté en réponse à l'émulation SX du Lotus ASIC).
Quant à l'utilisation d'un certificat qui ne correspond pas au jeu pour lequel il a été émis, le réseau demande d'authentifier le certificat de la carte de jeu en s'assurant d'inclure l'ID de l'application en cours de lecture afin qu'il soit facilement visible par Nintendo.
Il y a aussi quelques détails supplémentaires dont je n'ai pas encore vu parler. Par exemple, le système d'exploitation enregistre le nombre de fois que vous insérez et retirez une carte de jeu, ce qui pose clairement un problème, car le flashcart vous oblige à l'insérer et à la retirer pour parcourir les jeux.
Avec un CFW, vous avez un certain contrôle sur les données de télémétrie, mais avec un OFW, vous n'en avez aucun. Même si vous bloquez les domaines pour les rapports d'erreurs (qui sont les plus détaillés), vous ne pouvez tout simplement rien faire concernant les rapports système ("srepo") qui incluent des informations sur les cartes de jeu.
Cela nous amène au dernier point qui concerne le type de détection et de prévention existant *hors ligne*, ce qui est également la raison pour laquelle les créateurs du flashcart sont si prudents avec leur formulation.
Par exemple, seuls 16 des 208 octets de la région cryptée d'un certificat de carte de jeu sont actuellement utilisés (pour dériver la clé de communication). Personne ne sait vraiment si les octets restants ont une corrélation avec les régions InitialData ou CardHeader.
S'il s'avère qu'il existe effectivement une corrélation, alors le scénario actuel consistant à utiliser le même certificat pour différentes images XCI devient patchable hors ligne. Il existe de nombreuses autres façons de détecter et de bloquer ce problème, soit au niveau du système d'exploitation, soit au niveau de Lotus.
Ironiquement, le seul cas où le flashcart pourrait ne pas pouvoir être corrigé ou détecté est si vous l'utilisez uniquement pour conserver des copies de jeux légitimes (certificat correspondant au jeu et tout ça) et ne les parcourez pas.
Un sujet supplémentaire que j'ai observé concerne la façon dont cela pourrait affecter la rétrocompatibilité dans une future console. Comme je l'ai mentionné précédemment, il y a toujours eu un deuxième système de sécurité en attente, précisément parce que Nintendo était conscient des faiblesses de la partie gamecart du jeu.
Cela signifie que les *futures* cartes de jeu seraient sûres, mais que celles actuelles auront toujours leur système de cryptage matériel brisé. Personnellement, je pense que la rétrocompatibilité sera assurée même au niveau des cartes de jeu (c'est-à-dire le futur matériel capable de lire les cartes de jeu Switch).
Il y a quelques changements récents dans l'écosystème Gamecard/Lotus qui suggèrent que le même matériel allait être utilisé dans une nouvelle console et il semble peu probable que cela change (surtout compte tenu de l'existence d'un deuxième système de sécurité) .
Cependant, il est tout à fait possible que le futur matériel vous oblige désormais à vérifier les anciennes cartes de jeu en ligne pour affirmer sa légitimité, par exemple. "
Comme vous pouvez le lire c'est un très long billet, presque un writeup sur ce qu'est le Mig Switch à ses yeux, et les notions de sécurité abordées sont intéressantes à plusieurs titres. A suivre.
C'est mieux 
