Badablek

certains points sont un peu "chauds" si la panne du fer à souder est trop grosse. Avec un Weller 15w (pas forcément adapté à du matos RoHS) et une panne un poil trop large, le point Vol+ a été le plus embêtant (présence de connecteurs et nappes très proches, étroitesse du point d'origine, etc.) Mais en y allant gentiment, sans se presser, ça passe tranquille. Pour la configuration, le tuto est extrêmement pauvre en détails. Notamment : une fois la puce correctement flashée, elle n'apparaîtra plus jamais dans l'explorateur ! J'ai flippé avec ma première trinket, pensant l'avoir cramée. En flashant ma seconde puce (toujours avoir une pièce de rechange ), même topo une fois flashée (ç'a ma laissé penser qu'en fait les puces étaient OK, mais j'ai soudé à l'aveugle quand même pas un mot (du moins, c'est abordé très très vaguement) sur la façon de mettre les payloads, de faire cohabiter Atmosphère et SXOS (par exemple), d'utiliser Hekate (ne pas oublier l'interface Nyx pour un truc plus sympa à utiliser) rien sur la découpe obligatoire du carter métallique qui protège la CM pas plus que sur certaines options (USB Disconnect, et options en rose sur la photo de la CM) Je pense que son auteur a trop l'habitude des trinket et de la bidouille, et en oublie les bases : un tuto est fait pour expliquer de bout en bout les processus mis en œuvre. j'ai fait quelques remarques ici, à ce sujet :

bon le sujet date un peu, mais j'ai enfin sauté le pas. Me suis installé un Trinket m0 en mode perma-CFW. Ça fonctionne très bien !

salut, si tu soudes les straps Vol+ et Joy-con, et que tu utilises le fichier PERMA-CFW, ta console démarrera par défaut en mode Custom Firmware (avec ou sans emuNAND, suivant ta configuration...emuNAND plus que recommandée, comme tu l'as bien compris). Voir extrait de notice ci-dessous, venant du sujet très documenté sur GBAtemp : Vu la façon dont tu veux exploiter ta console, je suppose que le gros avertissement en rouge ne te concerne pas. Si tu laisses ta console en 4.1.0, et que tu paramètres une emuNAND à jour pour le CFW, à aucun moment, en appuyant sur Reset de la puce, tu ne pourras cramer le moindre efuse (puisque tu restes en 4.1.0 officiellement). Pour moi, cet avertissement concerne ceux qui voudraient booter en CFW sans emuNAND...mais ça ne reste que mon interprétation de la chose. Enfin, concernant le mode AutoRCM, c'est logiquement parfaitement géré par la puce depuis la version 1.5.3beta : Sachant qu'il faut à priori plusieurs mois pour que la batterie se vide complètement, console éteinte, avec le trinket m0 qui consomme (peu). Donc pas sûr que ce soit réellement un problème. ça me fait penser que ma Trinket m0 dort depuis des mois dans un tiroir...je vais me motiver pour la poser tiens EDIT : je viens de finir le montage...je n'avais pas conscience que c'était aussi chaud patate, ça m'a rappelé de bons souvenirs (puçage PS2 notamment). le tuto sur GBAtemp est, à mon humble avis, très mal foutu. impossible de trouver à quoi servait l'option USB disconnect (marron) ni quel(s pin(s) correspondent à quelle(s) fonction(s) en rose aucune ligne sur la façon de passer le trinket m0 en mode UF2 au tout premier flash rien sur le fait qu'une fois correctement programmée, la puce n'est plus flashable depuis le PC ! Je pensais avoir flingué mon trinket qui n'apparaissait plus du tout (en mode normal comme en mode UF2), j'ai donc programmé dans la foulée le deuxième que j'avais sous la main > même résultat. J'ai donc fait le montage à l'aveugle, sans savoir si la puce était encore vivante. pas un mot sur le payload à mettre à la racine. C'est bien évidemment fusee-primary.bin pour Atmosphère, à renommer payload.bin pas un mot sur le fait que la puce ne permet plus de remettre la coque alu correctement (à découper) y'a un boulot de dingue qui a été fait sur les fonctions de la puce, mais au détriment d'explications CLAIRES et précises sur son fonctionnement ou ses options. Dans le doute, j'ai tout connecté SAUF les options en rose. Étonnement, l'USB disconnect n'est pas détecté par Hekate. ps : j'ai flashé : Part_1_TRINKET_PERMA_CFW_Latest.uf2 puis Part_2_TRINKET_SWITCHBOOT_PART2_LATEST.UF2, ça donne : Appui simple sur Power : boot sur le payload (Atmosphère) Maintenir Vol- et et appui simple sur Power : boot sur hekate Dans Hekate, Reboot (normal) permet de démarrer sur la sysNAND (pas trouvé de raccourci pour le faire sans Hekate

ravi de pouvoir aider un des (rares) amateurs de cette console (sortie trop vite, oubliée trop rapidement) mine de rien, on peut encore faire de bien belles choses avec, même si la Switch l'a totalement éclipsée de la scène (et surtout...des programmeurs de homebrews).

tu peux également ajouter sigpatchtosystem à un raccourci manette sur haxchii (via config.txt) Ainsi, admettons que tu le paramètres sur le bouton A, il te suffira de maintenir A au chargement de haxchii pour lancer automatiquement sigpatchtosystem. exemple : a=wiiu/apps/sig_patcher/sign_c2w_patcher.elf default=sysmenu perso me suis fait un config.txt ultra complet (Mocha, WUP Installer, SwapDRC, etc.), avec une image de chargement de haxchii modifiée pour me rappeler à quoi chaque touche correspond C'est très pratique.

salut, Haxchii n'est que la faille de lancement qui ouvre les portes. Mais elle ne suffit pas pour activer les patches signature. Si tu essaies de lancer un contenu (chaîne) non signé, tu auras forcément une erreur de ce type. Il te faut lancer Mocha CFW (depuis haxchii) AVANT de pouvoir profiter de contenus non signés (que ce soit aussi bien pour les installer ou les lancer). Le mieux étant de profiter de la fonction de semi-loader de haxchii (grâce au fichier config.txt qui permet de définir des raccourcis manette pour lancer telle ou telle application) Seule exception : les jeux eshop mixés avec les "tickets" des mêmes jeux, mais au format DVD, puisque dans ce cas, tout est correctement signé (les tickets DVD sont signés avec une clé générique pour que n'importe quelle console puisse démarrer les jeux). Par contre HBL peut démarrer sans aucun patch signature, directement depuis haxchii. Tu es sûr de bien lancer le bon exécutable (fichier elf sur la SD) ? Si tu as installé la version chaîne comme le propose le tuto, obligatoirement, Mocha CFW doit avoir été lancé AVANT (et à chaque démarrage de la console, rappelons-le). En résumé, une console sous haxchii, sans les patches signatures supplémentaires de mocha CFW (ou équivalent), ne peut lancer que : homebrew launcher (format .ELF UNIQUEMENT) depuis lequel on peut exécuter les fichiers .RPX des homebrews bien sûr jeux Wii U eshop mixés avec leurs tickets DVD Wii U correspondants Tout le reste nécessite les patches signatures : jeux Wii U eshop ne disposant pas de ticket DVD (il en existe quelques uns, la version physique ne partageant pas le même titleID que la version dématérialisée) ou de type Wiiware (pas de version physique du tout) chaînes non signées (ce qui inclut TOUS les homebrews sous forme de chaîne)

non, c'est juste GodMode9.firm que tu prends (en gros, considère les .firm comme des exécutables) par défaut, les développeurs de homebrews proposent un peu tous les formats (.3dsx, .bin, .firm, etc.) pour contenter tout le monde (il n'y a pas qu'un seul hack possible sur 3DS). c'est un peu expliqué ici, dans le tuto 3dsguide (le dossier gm9 n'est pas obligatoire, il contient quelques scripts pas forcément utiles) ps : si ce n'est pas déjà fait, ne laisse rien dans ton port cartouche, en tout cas le temps de booter tranquillement sur Luma, de le configurer et de constater que la console démarre correctement. Il ne faudrait pas y laisser un linker programmé NTRBOOT par exemple (qui risque de bootlooper sur l'installation de b9s)

salut, le souci dans son cas, si j'ai bien tout suivi, c'est que la console ne démarre plus...donc mise à jour impossible, KGB64 @mitch8 supprime tous les fichiers à la racine (arm9.bin à soundhax.m4a) ainsi que le dossier boot9strap (au pire, renomme-le autrement), télécharge Luma 10.0.1 et extrais boot.firm à la racine. Là, on n'est pas certain que le boot.firm corresponde bien à Luma, sur ta capture d'écran. et comme tu as gardé arm9.bin et boot9strap (qui correspond à safeb9sinstaller), il se peut que l'exploit b9s démarre en boucle sur safeb9sinstaller (arm9.bin) plutôt que Luma3DS (boot.firm) dans le pire du pire des cas, tu mets le payload de godmode9 dans Luma (ça doit aller dans Luma\Payloads il me semble), tu démarres en maintenant START. Une fois sur Godmode9, tu vas sur ta carte SD (SDCARD), tu te mets sur boot.firm et tu appuies sur le bouton Y (copier), tu vas ensuite dans ta sysNAND (SYSNAND CTRNAND) et tu colles boot.firm en appuyant sur Y. Il va te demander si tu veux copier le fichier ou le chemin du fichier (raccourci), tu valides bien évidemment la copie entière du fichier. Pour écrire dans la sysNAND, il va t'inviter à faire une séquence de boutons pour confirmer, tu te plies à sa demande. Quand c'est fait (tu as donc boot.firm à la racine à la fois de la SD et de la sysNAND. Tu éteins la console, tu retires la SD, tu démarres et tu vois ce qui se passe. Si la console démarre bien (configuration de Luma puis boot complet), elle sera en mode Custom Firmware "de secours", ce qui confirmera que ta configuration est OK, auquel cas ça peut venir de ta microSD (carte bas de gamme, copie, etc.) ou qu'un fichier du hack n'est pas là où il devrait être. et si ça marche bien sans SD, ne restera plus qu'à formater proprement la carte, remettre UNIQUEMENT Luma3DS (donc boot.firm) et retenter ta chance. Et si ça fonctionne, tu pourras commencer à t'amuser un peu plus.

à mon avis, le risque de brick étant à mon maximum sur les unités iPatched, la team Xecuter a trop peur d'un retour de bâton contre-productif pour ses petites affaires très lucratives. un SXOS brickeur de Switch, ça ferait mauvais genre (d'autant qu'ils ne sont pas débutants en la matière, avec le brickeur volontairement intégré à leurs premières versions de SXOS) Il y a déjà bien assez de Switch non patchées dans la nature pour ne pas trop se soucier des iPatched / Mariko. Peut-être qu'une fois le filon épuisé, ils y repenseront (mais vu les millions d'unités non patchées, ça n'arrivera pas avant longtemps). à moins d'une faille béante à la sauce RCM, je doute qu'ils (Xecuter) mettent ls mains dans le cambouis avant un bon bout de temps.

salut, si la team Xecuter y travaillait, ça se saurait...Ils attendent tranquillement, le bec grand ouvert, que les vrais hackers (SciresM et compagnie) fassent tout le boulot à leur place. Sauf que, pour l'instant, malheureusement pour les désirs capitalistes de Xecuter, seules les consoles nouvelle génération en 3.x et 4.x peuvent être bootées sous Atmosphère. Ça repose sur deux failles purement software, utilisées conjointement, et qui ne seront jamais compatibles avec la dernière version du firmware (branche 8.x), qui corrige tout ça. Et comme les modèles Mariko sont de plus en plus vendues en 8.x, c'est mort d'avance. Bref, pas demain la veille que Xecuter sortira quelque chose de concret, non repompé des petits copains hackers bénévoles Il ne faut rien attendre d'eux, c'est ce qu'il y a de plus sage à faire.

le seul intérêt de rester sur un firmware ancien, c'est une potentielle faille "gold". Mais dans l'absolu (et j'en suis de plus en plus convaincu moi-même), c'est beaucoup d'ennuis pour un "peut-être". Perso j'ai passé ma quest en autoRCM + firmware 8.1 (pas folle la guêpe, je garde quand même un nombre de efuses bas au cas où) et je ne le regrette pas. Le firmware 8.1 permet de ne plus se soucier de savoir si tel ou tel fichier sera ou non compatible, et je n'ai, jusqu'à présent, trouvé aucun homebrew incompatible (ma plus grande peur à chaque mise à jour majeure de firmware) mes trinquet sont encore soigneusement emballés, un jour viendra, peut-être pour le moment, le génial dongle rcmloader me suffit amplement (la minuscule plus-value du trinket me fait même dire que ça n'en vaut pas la peine par rapport aux modifications que cela implique).

perso je ferais le contraire : réinjection de la NAND propre dans le sysNAND création d'une emuMMC en mode "incognito" de base, tu aurais une console saine, avec bootloader original, nombre d'efuses qui correspondent à la version du firmware, NSP 100% officiels et quand tu veux passer du côté obscur : RCM > emuMMC anonyme mais n'étant pas expert dans ce type de cohabitation, je me trompe peut-être.

le souci du online avec le hack switch, c'est que si tu as lancé le moindre NSP "frelaté", entendre par là avec un ticket non valide (ce qui inclut les homebrews), ça se voit comme le nez au milieu de la figure. Et personne ne sait si les efuses sont vérifiés à la connexion. Perso je ne conseille pas le online sur console hackée, pas même avec des XCI sous SXOS. ps: une console anonymisée ne peut pas se connecter au "live" Nintendo.

nickel les efuses ne concernent que la sysNAND, de toute façon le bootloader officiel ne sait même pas ce qu'est une emuMMC/emuNAND . Quand tu bootes une emuMMC, tu passes par un bootloader custom, qui ne touchera jamais à tes efuses. Donc aucun souci de ce côté, pas de corrélation entre le nombre de efuses cramés dans le CPU et l'emuNAND. Les efuses permettent juste au bootloader de savoir ce qu'il a le droit de lancer (protection anti-downgrade). Par contre, bien évidemment, les MAJ, c'est via choidujourNX. Il vaut mieux éviter toute communication online (risque fort de ban), à moins d'avoir anonymisé l'emuMMC avec incognito (un patch a été créé pour atmosphère dans ce but)