Badablek

Administrateurs
  • Compteur de contenus

    12 229
  • Inscription

  • Dernière visite

Réputation sur la communauté

0 Neutral

1 abonné

À propos de Badablek

  • Rang
    Vieille Branche
  • Date de naissance 27/06/1980

Information Personnelle

  • Localisation
    Metz

Visiteurs récents du profil

34 542 visualisations du profil
  1. Badablek

    b9s/luma

    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)
  2. Badablek

    b9s/luma

    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.
  3. à 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.
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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)
  9. Badablek

    Mega-Tuto Du Hack Wii

    content que ça marche pour toi
  10. Badablek

    Mega-Tuto Du Hack Wii

    salut zouzzz, tu n'as pas décompressé les fichiers de la v10 beta 53 comme il faut. Il faut le mettre dans le même répertoire que le binaire de l'installeur d2x. l'installeur uniquement : apps\d2x-cios-installer ← contient par défaut boot.dol, meta.xml et icon.png quand tu ajoutes les fichiers de la v10b52/b53 (l'une ou l'autre, au choix), tu auras EN PLUS, dans apps\d2x-cios-installer un sous-dossier d2x-v10-beta52 OU d2x-v10-beta53-alt contenant les fichiers .app et .bat un fichier ciosmaps.xml (très important, c'est lui qui indique à l'installeur les fichiers supplémentaires à utiliser !) Il faut bien sûr utiliser le dernier installeur en date (3.2)
  11. salut zinzin64, avant de penser à upgrader, essaie ceci pour voir : mets-toi en mode avion, éteins complètement la console. Maintiens appuyés Vol(+) + Vol(-) avant d'allumer la console avec Power. Maintiens ces 3 boutons appuyés jusqu'à atterrir sur le menu recovery de la console. NE TOUCHE À AUCUNE OPTION, éteins directement la console en maintenant Power assez longtemps. Redémarre la console à nouveau...la mise à jour en attente est normalement supprimée Bien évidemment, si c'est ok, tu gardes le mode avion (en tout cas pour le WIFI) et tu mets le contrôle parental quant à mettre à jour, pourquoi pas, mais tu t'embêtes bien avec kosmos/hekate (sachant que Kosmos n'est qu'un pack AIO d'Atmosphère). Il n'y a pas non plus de réelle plus-value à insérer hekate dans la boucle de boot de la console. Tu t'en sers principalement pour dumper la NAND, ça s'arrête à ça normalement (bon, ok, avec la version 5 en mode graphique, ça se discute, il fait de bien belles choses). Perso, que tu restes en 5.x ou que tu passes en 8.x, je ne peux que te conseiller Atmosphère (dernier en date : 0.9.2) + Patches ES (dernier en date : compatible 2.00 à 8.1.0). Et...rien besoin de plus ! Et vu que l'emummc est désormais supportée, tu peux même te payer le luxe de garder ta 5.x et faire une emummc mise à jour en 8.1.0 Pour ma part, je garde le payload d'hekate au chaud sur mon dongle rcmloader (en plus de fusée-primary et sxos), prêt à dégainer si besoin (dump sysNAND, réinjection, création d'emummc, etc.). Mais je dirais que dans 99% des cas, un démarrage normal fusée-primary → fusée-secondary → (Sept) → Atmosphère suffit amplement ps : sept, en mode sans prise de tête, c'est : je télécharge Atmosphère 0.9.2, je décompresse l'archive à la racine, fini !
  12. Tu as vérifié ta SD ? ça sent un peu la carte noname bas de gamme qui aurait cramé. Je te conseille de tester avec une autre carte, si tu en as une qui traîne , même petite.
  13. salut, tu utilises une version périmée de Luma3DS, incompatible avec ton firmware (que tu as sûrement mis à jour). Télécharge Luma3DS 10.0, décompresse boot.firm à la racine de ta microSD, et ton problème sera réglé. ps : et vu que la console peut démarrer sans SD, ça veut dire que boot.firm a aussi été copié dans la CTRNAND. Et là il faut passer par godmode9 pour remplacer la version obsolète (8.1.1) par la nouvelle (10.0). Soit manuellement, soit avec le script qui va bien. Plus d'infos ici (section VI)