Ce guide est là pour votre information sur les avancées de la scène underground Switch 2 ! Il sera alimenté au fur et à mesure des avancées et recherches dédiées à la libération de votre console ! Inutile de se jeter sur une exploitation sans réellement connaitre tous les aspects qu'il faut maitriser pour éviter toutes éventualités sans retour possible !
Ni GamerGen, ni l'auteur de ce topic ne seront tenus pour responsables en cas de dommage ou de mauvaises manipulations de votre part. Vous le faites à vos risques et périls en toute responsabilité.
@pepsipu a annoncé qu'il ne pourra pas publier le jailbreak WebKit pour la Switch 2 jusqu'à nouvel ordre et il ne peut donner aucun détail ni la raison !
| CivSwitch - POUR LE MOMENT ! |
A ce stade, pour l'exploitation de CivSwitch:- [+] CLIQUER POUR AFFICHER
- CivSwitch reste limité à l'accès utilisateur (userland)
- Aucune exploitation complète du kernel
- Aucun custom firmware (CFW)
- Il restera actif même après une mise en veille ou une sortie de veille
- Testé sur Switch 1 (firmware 22.5.0) et sur Switch 2 (firmwares 20.4.0 et 23.0.1)
- Civilization VII (Switch 1) nécessaire
- Cartouche physique version 1.0.0
- Les copies numériques ne sont pas prises en charge
- Raspberry Pi Pico utilisé (Pico 2 recommandé, Pico 1 non testé)
- CivSwitchLDN permet d’exécuter l'exploit de @Gezine sur Switch 2 sans acheter de Raspberry Pi Pico ni aucun matériel supplémentaire. Il utilise LDN (le protocole de multijoueur sans fil local) via votre Wi-Fi habituel afin qu’un PC Linux, sur le même réseau, puisse injecter le payload directement dans le jeu
A ce stade, pour l'exploitation de NS2JB:- [+] CLIQUER POUR AFFICHER
- NS2JB reste limité à l'accès utilisateur (userland)
- Aucune exploitation complète du kernel
- Aucun custom firmware (CFW)
- Un jailbreak tethered qui doit être relancé après un redémarrage.
- Le portage WebKit n'a pas encore été publié
- Le firmware 23.0.1 est utilisé pour NS2JB
- mac2jb indique que les versions antérieures devraient également fonctionner, sans toutefois le confirmer !
- SmileBASIC 4 obtenu et installé légalement sur la mémoire système:
- Le jeu complet (version 4.4.9) ou la démo (version 4.4.6).
- Les forks de kurumuz - NS2JB et BermTheSequel - NS2JB2 sont compatibles avec les deux. Mac2jb l'est également.
- La démo n'est pas compatible avec tous les lanceurs !
- SmileBASIC 4 n’est plus disponible sur l’eShop !
- Un ordinateur connecté au même réseau que la console est nécessaire:
- La version modifiée de @kurumuz documente la compatibilité avec macOS et Linux et Node.js 22+.
- NS2JB2 ajoute la compatibilité avec Windows
- mac2jb nécessite un Mac Apple Silicon sous macOS 14+.
- Une façon de saisir environ 7 800 caractères en une seule fois est indispensable:
- A la main ^^ ou avec un périphérique faisant office de clavier USB.
- Avoir de la patience !
- NS2JB fonctionne, mais pas de manière fiable: l’étape, côté jeu, s’exécute toujours, tandis que l’étape, côté fichiers système, échoue souvent, et cela se termine lorsque vous fermez l’application ou redémarrez.
Désactivez les mises à jour !
Inutile de mettre à jour pour le moment !
Ne pas mettre à jour au delà de 23.0.1 !
Des utilisateurs ont brick leur console en faisant de mauvaises manipulations !
Via l'Exploit CivSwitch
CivSwitch est une chaîne d'outils XSS conçue pour la version Switch de Civilization VII et ne fonctionne qu'avec la cartouche physique (version 1.0.0). Les copies numériques ne sont pas prises en charge ! Il a été testé sur Switch 1 (firmware 22.5.0) et sur Switch 2 (firmwares 20.4.0 et 23.0.1). Il utilise une sauvegarde sur cartouche plutôt qu'un téléchargement numérique ou un transfert en ligne. Il reste utilisable même si Nintendo retire le jeu !
CivSwitchLDN permet d’exécuter l'exploit de @Gezine sur Switch 2 sans acheter de Raspberry Pi Pico ni aucun matériel supplémentaire. Il utilise LDN (le protocole de multijoueur sans fil local) via votre Wi-Fi habituel afin qu’un PC Linux, sur le même réseau, puisse injecter le payload directement dans le jeu.
- [+] CLIQUER POUR AFFICHER
Info 1: Ce qu'il obtient !
Pour exploiter cette chaine d'outils XSS, vous avez besoin de la cartouche physique, de configurer la langue de la console en anglais (États-Unis), puis d'utiliser un Raspberry Pi Pico (Pico 2 recommandé, Pico 1 non testé) pour envoyer un code dans le salon multijoueur. Une fois cette opération effectuée, vous obtenez un chargeur JavaScript distant sur le port TCP 9026, et vous pouvez installer un déclencheur persistant dans les données de sauvegarde pour qu'il se lance à chaque chargement de la partie.
Vous aurez accès à un chargeur JS distant, après un certain délai, pour exécuter le script d'installation depuis un PC et ajouter le déclencheur XSTRIG.Civ7Save à votre sauvegarde. A chaque démarrage, il vous suffira d'aller dans le menu principal et de charger une partie. Le programme s'exécutera depuis vos données de sauvegarde. Il restera actif même après une mise en veille ou une sortie de veille si vous utilisez bien le chargeur que vous avez installé.
Il comprend deux parties principales:
- PicoSwitch, le firmware qui saisit le code XSS dans le chat via une macro USB HID,
- L'installer-creator qui génère le déclencheur de sauvegarde persistante au démarrage.
CivSwitchLDN supprime entièrement l'étape qui nécessite le Pico (ou un ESP32) pour saisir le long payload XSS via USB HID. Vous hébergez le salon multijoueur de Civilization VII sur la Switch puis vous exécutez un script sur le PC, et celui-ci rejoint le salon via LDN et envoie lui-même les messages.
LDN sert de voie d’entrée, le chat du jeu transporte le payload, l’exploit déclenche le chargeur, puis le réseau local permet les échanges.
- run.js coordonne le déroulement général et l’éventuelle proposition d’installation persistante.
- loader.js vérifie le Remote JS Loader et recherche la console sur le réseau local.
- compress.js prépare le payload destinée à être envoyé par le chat du jeu.
- send_payload.js sert à transmettre un fichier JavaScript au chargeur.
- ldn/ contient les composants liés au transport LDN
- bash/ regroupe des scripts Linux.
- payloads/ et installer/ contiennent respectivement des payloads et des éléments d’installation.
Info 2: Les limites !
Ce n’est pas un jailbreak complet avec un firmware personnalisé ni une exploitation du Kernel, il s'agit simplement d'une exécution de code utilisateur capable de charger des payloads supplémentaires via le réseau une fois le loader lancé. La Switch 2 doit être sur le même réseau Wi-Fi que la machine Linux. Vous aurez besoin de votre prod.keys extraits d’une Switch 1, de Node.js 18 ou supérieur, de Python 3.12 avec un environnement virtuel, et de l’outil setcap pour que l’assistant Python puisse gérer la partie réseau. WSL n’est pas pris en charge en raison des limitations réseau.
Seule la cartouche physique (Switch 1) de Civilization WII v1.0.0 est compatible !
Info 3: CivSwitch - Son exploitation !
Déclenchement de XSS depuis le chat
CivSwitch exploite une faille de type XSS (Cross-Site Scripting) dans le chat du jeu. Cette vulnérabilité permet d'injecter du code JavaScript dans un contexte où celui-ci peut être exécuté. Le déclenchement passe par le menu multijoueur de Civilization VII. L'utilisateur doit créer un salon et ouvrir le chat. Un périphérique basé sur un Raspberry Pi Pico envoie ensuite automatiquement le contenu nécessaire dans le champ de discussion. Le script transmis représente environ 87 lignes et nécessite approximativement 15 minutes de saisie automatisée. Une fois l'opération terminée, un Remote JS Loader est lancé sur la console et ouvre un service TCP sur le port 9026. Ce service permet d'envoyer des fichiers JavaScript depuis un ordinateur, sans devoir recommencer toute la procédure d'injection à chaque fois que l'on souhaite transmettre un payload.
PicoSwitch: le firmware chargé de l'injection
PicoSwitch est destiné aux Raspberry Pi Pico équipés d'une puce RP2040 ou RP2350. Il se comporte comme un clavier USB et reproduit automatiquement la saisie du code dans le chat du jeu. Le firmware contient un outil de compression et de transformation du JavaScript afin de produire un payload adapté aux contraintes du champ de discussion. Le processus repose notamment sur la minification du code, la compression Deflate Raw et le découpage du contenu en plusieurs fragments utilisant une structure HTML de type img/onerror.
Installer-creator: l'installation du déclencheur persistant
Son objectif est d'écrire un déclencheur nommé XSTRIG.Civ7Save dans les données de sauvegarde du jeu. Ce mécanisme permet ensuite de relancer le paylaod depuis le menu de chargement des parties. L'installation initiale nécessite un ordinateur connecté au même réseau que la console. Le script prévu à cet effet transfère un modèle de sauvegarde, intègre le payload compressé et écrit le déclencheur dans les données du jeu. Le projet précise que le contenu du dossier save:/saves/Single/ est effacé pendant cette opération. Il est donc important de prendre en compte ce comportement avant d'utiliser l'installateur.
Un déclenchement facilité au démarrage du jeu
Après l'installation du déclencheur, il suffit de démarrer Civilization VII, puis de passer par le menu de chargement des parties pour déclencher l'exécution du code enregistré dans les données de sauvegarde. Si le payload installé correspond au Remote JS Loader, le service TCP sur le port 9026 peut être disponible dès cette étape. Le développeur indique que le service peut rester accessible après une mise en veille puis un réveil de la console. Cette persistance reste toutefois liée au mécanisme mis en place dans les sauvegardes de Civilization VII. Elle ne doit pas être confondue avec un exploit système permanent indépendant du jeu.
Expérimenter avec des payloads JavaScript
CivSwitch ne se limite pas au lancement de son propre chargeur. Le projet prévoit un script Python, send_js.py, capable de transmettre un fichier JavaScript au Remote JS Loader actif. Cela permet aux développeurs de tester différents payloads sans devoir modifier le firmware du Pico à chaque expérimentation. Le code source comprend les éléments nécessaires à la compilation du firmware PicoSwitch, ainsi que les scripts permettant de préparer et d'envoyer les payloads. Le développeur crédite notamment les travaux du projet Netflix-N-Hack pour certaines parties de l'exploit JavaScript, ainsi que le projet Pico-Switch-Controller pour la base du firmware destiné au firmware
Info 4: CivSwitchLDN - Son exploitation !
Préparation du payload
Le programme compresse le composant principal en plusieurs messages de chat. Cette préparation vise à faire passer le contenu par le canal de communication de Civilization VII. Le code est réparti en 19 messages.
Transport par LDN
L’ordinateur rejoint le réseau local sans fil puis établit la communication avec le jeu et transmet les messages. Le mécanisme exploite le traitement de ces données par le jeu: c’est cette étape qui constitue la partie du processus de l'exploit.
Retour au réseau local
Après l’envoi, le programme ferme la connexion LDN et tente de rétablir la connexion réseau habituelle de l’ordinateur. Cette transition est nécessaire pour que la suite puisse chercher la console sur le réseau local.
Détection du Remote JS Loader
Le logiciel attend ensuite une réponse du chargeur JavaScript distant, port 9026. Une fois celui-ci actif, le PC peut lui transmettre d’autres fichiers JavaScript. Le chargeur sert donc d’interface de communication après le passage initial par le jeu.
Installation persistante
Il peut proposer un installateur qui modifie les sauvegardes solo du jeu afin de relancer le chargeur ultérieurement. Cette opération remplace les sauvegardes et ce n’est pas une étape nécessaire au simple déclenchement initial.
En construction...
Via l'Exploit NS2JB
NS2JB est une chaîne d’exploitation logicielle publiée par Sammy Hajhamid,, alias @pepsipu, pour la Switch 2 et testée sous le firmware 23.0.1. Elle ne nécessite pas de modification matérielle, mais reste tethered, il faut la relancer après chaque redémarrage. Ce n’est pas un jailbreak complet avec un firmware personnalisé ni une exploitation du Kernel !
- [+] CLIQUER POUR AFFICHER
Info 1: Ce qu'il obtient !
- Un débordement arithmétique dans la gestion de tableaux de SmileBASIC , une application de programmation conçue pour la Switch d’origine et exécutable sur Switch 2. Cela permet de sortir des limites mémoire prévues.
- Un type de débordement de tampon dans le service système de fichiers, qui donne un accès mémoire plus étendu.
- Une faille dans le chargement des programmes: le chargeur vérifie des signatures et des hachages, mais dépend du service de fichiers pour lui fournir les données correspondantes. La chaîne signalée exploite cette dépendance pour faire accepter un exécutable modifié malgré ces contrôles.
Info 2: Les limites !
Ces capacités permettent d’exécuter du code natif dans un contexte utilisateur et d’accéder à certains services privilégiés. Les usages montrés ou rapportés comprennent le lancement d'homebrew, l’analyse et la modification de jeux, ainsi que la sauvegarde de données.
NS2JB illustre qu’une vérification cryptographique peut perdre son efficacité si un composant de confiance fournit les données vérifiées et peut être compromis. La sécurité dépend donc non seulement des signatures, mais aussi de l’intégrité des services qui alimentent le chargeur et de la façon dont ces composants interagissent.
Info 3: Son exploitation !
Étape 1: Point d’entrée - SmileBASIC
SmileBASIC 4 gère un tableau et effectue un calcul de taille lors de la suppression d’éléments. Un débordement arithmétique peut rendre incorrecte la vérification qui devrait garantir que l’opération reste dans les limites du tableau. Une opération ultérieure utilise alors une taille ou une position incohérente. Le résultat est une corruption mémoire: au lieu de modifier uniquement les éléments prévus, le programme peut lire ou écrire au-delà de la zone associée au tableau. Cette primitive permet d’obtenir l’exécution de code dans le contexte de SmileBASIC. Il s’agit encore du contexte de l’application et non d’un contrôle global de la console.
Ce contexte décrit un débordement d’entier dans l’interpréteur BASIC, lors de la suppression d’éléments d’un tableau. Une vérification de limites peut être faussée par un calcul qui déborde. L’opération de déplacement des éléments qui suit accède alors à une zone mémoire en dehors de celles prévues. Cela permet de transformer une structure de chaîne de caractères en moyen de lire et d’écrire hors limites, puis d’obtenir l’exécution de code dans le contexte de SmileBASIC.
Étape 2: Élévation d’accès dans fs
Un chemin spécialement construit entraîne le dépassement d’un tampon temporaire. En termes généraux, le service reçoit une entrée plus longue ou d’une forme inattendue que ce que sa zone de stockage peut gérer correctement. La corruption de mémoire dans fs est particulièrement importante parce que ce service a davantage de privilèges qu’une application ordinaire. Un accès étendu à la mémoire du processus a pu modifier des données internes du service et accéder à des ressources supplémentaires. C’est ce changement de contexte d’une application vers un service système qui augmente fortement l’impact de la chaîne.
Cette étape repose sur une erreur de traitement des chemins dans le service système de fichiers intégré fs. Un chemin contenant une séquence particulière déclenche une copie dans un tampon temporaire trop petit. Cette exploitation de débordement cible des données internes de cache, ce qui fournit un accès arbitraire en lecture et en écriture dans la mémoire du processus fs. Cet accès permet de modifier des informations de connexion et d’obtenir des permissions étendues sur le système de fichiers.
Étape 3: Exploiter la relation entre fs et ldr
Pour lancer un programme, le chargeur ldr dépend du service fs pour accéder aux fichiers exécutables et aux informations associées à leur validation. Les signatures et hachages peuvent être valides tout en ne garantissant pas l’intégrité du processus si le composant qui fournit les données a été compromis. Cela consiste à agir en amont de la vérification: un service de fichiers contrôlé peut influencer ce que le chargeur lit ou la façon dont les données lui sont présentées. Le point faible n’est pas une falsification mathématique de signature, mais une dépendance de confiance dans le chemin qui conduit les données jusqu’au vérificateur.
Le chargeur ldr demande à fs d’ouvrir le système de fichiers exécutable d’un programme et reçoit aussi des éléments cryptographiques utilisés pour vérifier son intégrité et ses autorisations. Le problème n’est pas que les signatures cryptographiques seraient cassées, c’est que fs, désormais compromis, peut manipuler le système de fichiers présenté au chargeur. Le chargeur reçoit alors les éléments de validation associés au programme d’origine, mais peut se voir présenter un contenu exécutable remplacé. La vulnérabilité se situe dans la confiance accordée au composant qui fournit les données à vérifier et dans l’ordre des opérations, non dans une rupture de la cryptographie elle-même.
Étape 4: Exploiter un point d'entrée WebKit
Une piste vise à remplacer SmileBASIC comme point d’entrée en s’appuyant sur WebKit. @pepsipu indique que sa piste WebKit initiale n’a pas abouti et présente une éventuelle adaptation de la vulnérabilité de fs comme une possibilité de recherche, pas comme une méthode de remplacement déjà établie. Il faut donc distinguer piste explorée et exploit fonctionnel démontré !
Dans cette expérience, Codex a étudié une vulnérabilité WebKit déjà connue, exploitable à travers un portail captif Wi-Fi personnalisé. L'agent a rapporté une forme de détournement du flot d'exécution natif, mais cette approche s'est rapidement heurtée à plusieurs protections avancées.
- XOM (Execute-Only Memory): une protection empêchant la lecture directe de certaines zones mémoire contenant du code exécutable.
- PAC (Pointer Authentication Codes): un mécanisme destiné à renforcer l'intégrité des pointeurs et à compliquer leur falsification.
- CFI (Control-Flow Integrity): une technologie limitant les possibilités de détourner le chemin d'exécution normal d'un programme.
Depuis que Nintendo a retiré SmileBASIC 4 de son eShop, @pepsipu aurait réussi à porter NS2JB vers WebKit et à déclencher l'exploit sur une Switch 2 équipée du firmware 23.0.1. Le navigateur pourrait donc devenir un nouveau point d'entrée pour le jailbreak mais rien n'est publié pour le moment !
Info 4: Comment l'utiliser !
Via ezBasic
Il permet de transformer une Switch, première génération, modifiée en clavier USB virtuel, capable de saisir automatiquement le code nécessaire au lancement de l'exploit sur une Switch 2. L'outil repose sur Plutonium et intègre directement un script BASIC basé sur le fork de @kurumuz. ezBasic s'en charge automatiquement via une connexion USB entre les deux consoles.
Étape 1: Pré-requis !
- L'installation nécessite une Switch 1 capable de lancer des homebrews
- Une Switch 2, firmware 23.0.1, disposant de SmileBASIC 4
- Un câble USB permettant le transfert de données
- L'outil ezBasic.nro
Étape 2: Lancement !
ezBasic n'est pas un exploit, mais un utilitaire destiné à faciliter la saisie du code utilisé par NS2JB. L'outil ne garantit pas que le script a été correctement reçu ou exécuté sur la Switch 2. Il est donc important de vérifier la compatibilité de la configuration et du clavier.
1. Téléchargez ezBasic.nro
2. Copiez le fichier dans /switch/ezBasic/ezBasic.nro sur la carte SD de votre Switch 1
3. Lancez ezBasic depuis le Homebrew Menu de la Switch 1
4. Ouvrez SmileBASIC 4 sur votre Switch 2 et créez un nouveau programme vide
5. Reliez les deux consoles avec un câble USB compatible et attendez que la connexion USB soit prête, puis appuyez sur A sur la Switch 1 pour lancer la saisie automatique du script. L'application affiche la progression de la saisie. Le bouton B permet d'annuler l'opération et le bouton + de quitter.
Via Plume USB
Plume USB est un homebrew pour Switch 1 qui transforme la console en clavier USB. Elle peut envoyer le texte Hello ou saisir le contenu d’un fichier texte sur un appareil hôte compatible avec un clavier USB. Il automatise la saisie de texte dans un champ ouvert sur un appareil connecté. La Switch transmet les caractères comme un clavier HID plutôt que d’envoyer le fichier directement. La connexion USB peut donc être reconnue sans que l’application ou le champ de texte cible accepte nécessairement chaque caractère.
Étape 1: Pré-requis !
- L'installation nécessite une Switch 1 capable de lancer des homebrews
- Une Switch 2, firmware 23.0.1, disposant de SmileBASIC 4
- Un câble USB permettant le transfert de données
- L'outil Plume USB
Étape 2: Lancement !
1. Téléchargez et décompressez l'archive Plume-USB-X.V.X-SD.zip à la racine de la carte SD de la Switch 1.
NB: Pour une mise à jour, il suffit de télécharger le fichier .NRO et de le remplacer dans sdmc:/switch/plume-usb/plume-usb.nro
2. Lancez Plume USB depuis hbmenu sous Atmosphere
NB: Le mode application (maintenez R enfoncé lors du lancement) est recommandé
3. Connectez le port USB-C de la Switch 1 à la station d'accueil de la Switch 2 en utilisant un câble de données USB-A vers USB-C
illustration schématique
4. Lancez SmileBASIC 4 sur votre Switch 2 et créez un nouveau programme vide
5. Faites correspondre la disposition du clavier AZERTY FR ou QWERTY US de l'application pour la configuration du clavier.
6. Attendre USB keyboard connected et sélectionnez Send Hello
7. Appuyez ensuite sur A dans l'aperçu et l'envoi commence après trois secondes puis vérifiez le texte qui s'affiche.
NB: Appuyez sur X pour activer/désactiver le verrouillage majuscule si nécessaire. Appuyez sur - pour les diagnostics USB.
En construction...
L'IA au cœur de l'exploitation mémoire
- [+] CLIQUER POUR AFFICHER
L'une des particularités de cette découverte réside dans l'utilisation de Codex, l'agent de programmation d'OpenAI. Le rôle joué par l'intelligence artificielle dans le développement de ns2jb a été d'une aide utile. Le principe général de l'exploitation repose sur la manipulation d'objets IStorage afin de détourner leurs pointeurs et de contrôler leurs opérations de lecture et d'écriture. La chaîne actuelle s'appuie notamment sur des objets BufferedStorage. La difficulté résidait dans le heap grooming, une technique qui consiste à organiser précisément les allocations mémoire pour placer les objets dans des conditions favorables à l'exploitation.
@Hexkyz indique que l'IA a apporté une contribution importante à cette étape. Le code obtenu reste néanmoins particulièrement complexe, ce qui pourrait compliquer son adaptation à d'autres points d'entrée ou à des environnements différents. Cette approche illustre une évolution intéressante des méthodes employées dans la recherche en sécurité. L'intelligence artificielle peut contribuer à résoudre des problèmes complexes de manipulation mémoire, sans pour autant rendre automatiquement l'exploitation plus simple à comprendre ou à porter.
Le module fs: un accès userland privilégié
- [+] CLIQUER POUR AFFICHER
Une fois les opérations de lecture et d'écriture arbitraires obtenues, ns2jb exploite différentes techniques pour prendre le contrôle du module fs (File System). D'après @hexkyz, fs représente le niveau de privilèges le plus élevé dans l'userland de la Switch 2. Cette capacité ouvre des perspectives pour les développeurs et les chercheurs en sécurité mais ne permet pas, à elle seule, de récupérer les clés de chiffrement ni d'obtenir automatiquement un accès au kernel.
Selon les explications de @hexkyz, la vulnérabilité du module fs était connue depuis longtemps. Elle a été considérée comme difficilement exploitable en raison de l'organisation de la mémoire et du nombre limité de pointeurs intéressants présents. Finalement, la chaîne NS2JB démontre qu'il était possible de contourner ces difficultés.
HBLauncher un premier lanceur de homebrews sur Switch 2
- [+] CLIQUER POUR AFFICHER
@RavensClawX dévoile HBLauncher, un Homebrew Launcher accompagné de son propre SDK. Son installation reste, pour le moment, réservée aux utilisateurs expérimentés ! Sa particularité réside dans son fonctionnement. Il utilise les capacités du CPU et du GPU de la Switch 2 pour exécuter la logique des applications à travers des compute shaders, tandis que l'affichage repose sur des shaders graphiques. Cette approche permet de contourner certaines limitations de l'environnement actuel, mais ne remplace pas l'exécution native de programmes ARM64. Un ordinateur reste également indispensable pour héberger les applications et maintenir la communication avec la console pendant toute la session.
HBLauncher n'est donc ni un custom firmware, ni un lanceur NRO, ni une solution permettant d'installer des applications directement sur la Switch 2 ! Il embarque un véritable kit de développement, baptisé HB SDK et permet aux développeurs de concevoir leurs propres applications compatibles avec l'environnement de HBLauncher. Dans ce contexte, @RavensClawX propose ftpd-sb, un serveur FTP expérimental conçu pour fonctionner avec HBLauncher. Ce petit utilitaire permet d'échanger des fichiers entre un ordinateur et l'environnement SmileBASIC de la Switch 2 à travers un réseau local.
@RavensClawX insiste sur les risques liés à l'utilisation de HBLauncher. Il indique que le projet a été réalisé avec une forte assistance de l'intelligence artificielle et qu'il est fourni sans garantie. Des erreurs pourraient entraîner une corruption des sauvegardes, une perte de données ou des dysfonctionnements. Il est donc vivement recommandé de sauvegarder ses données importantes avant toutes manipulations et de ne pas expérimenter sans comprendre les risques. HBLauncher est avant tout destiné aux développeurs et aux utilisateurs expérimentés.
D'autres jeux pour servir de point d'entrée afin d'exploiter la console ?
- [+] CLIQUER POUR AFFICHER
@Gezine précise que certaines de ces pistes présenteraient un avantage non négligeable par rapport à CivSwitch. Elles ne nécessiteraient pas de transfert de sauvegarde pour fonctionner. D'autres possibilités existent déjà et garder ces nouvelles pistes sous le coude, sans dévoiler les jeux concernés, évitera des conséquences qui rendraient l’obtention, de ces jeux, difficile !
- [+] CLIQUER POUR AFFICHER
par MDProz » 27 Oct 2026, 06:58 
MDProz
Admin
SitemapIndex