Badablek
-
Compteur de contenus
12 543 -
Inscription
-
Dernière visite
Type de contenu
Profils
Forums
Calendrier
Tout ce qui a été posté par Badablek
-
salut, l'utilisation de ce genre d'outil nécessite un Custom Firmware pour fonctionner. Autrement dit, en 11.2, tu pars déjà très très mal. Il n'existe, à ce jour, aucune méthode purement software, facile, pour downgrader une console en 11.2. De mémoire, il existe une méthode avec un hack DSi, mais ça nécessite au moins une console hackée et pas mal de paramètres très particuliers, sans compter un transfert de compte de l'une à l'autre. Bref, à oublier.
-
arf, j'avais pas vu ta phrase juste au dessus du log, désolé. je ne comprends pas ce qui coince dans ce cas (encore plus si ça marchait avec une autre Wii U).
-
je vais poser une question bête hein, tu m'excuses par avance le wifi est bien activé sur ta Wii U ? Parce que le "no route to host" m'inquiète un peu et tu tournes en python 3.5 ou 2.7 ?
-
ok, linux, je n'étais pas sûr sous Windows, quand ça ne marche pas, on n'a même pas de log de retour, pour ça que ça m'a induit en erreur (ne ne connais absolument pas le fonctionnement de linux) je ne pige pas un truc par contre, le fichier fw.img boote bien sur le menu ou pas ? tu me parles d'un écran rouge statique (qui ressemble à l'écran de boot de la redNAND, mais avant qu'elle ne soit fonctionnelle) expérience perso : j'ai testé pas mal de combinaisons de cartes SD, du fait que le menu ne redémarrait pas. Testé avec une microSD 32Go Samsung (dans un adaptateur SD et dans une ezcard Wifi), Toshiba 16Go Flashair, et une pauvre SD de 1Go qui traînait, et il n'y a qu'avec la vieille carte SD que le menu boote correctement.
-
clic-droit sur wupclient.py > Edit with IDLE > F5 d'après ton log, tout fonctionne à la perfection, c'est juste que tu ne lances pas le script comme il faut (comme si tu double-cliquais pour exécuter le script, ça referme aussi sec la fenêtre)
-
salut pas de raison de ne pas pouvoir s'en servir, du moment que le logiciel contient bien les chemins d'accès qui t'intéressent (je suppose que FTPiiu everywhere permet d'aller fouiner dans les dossier d'installation des jeux sur la NAND, sinon il ne servirait pas à grand chose). Je n'ai pas encore eu le temps de tester, mais si on peut uploader un fichier vers un dossier de jeu VC DS, tu devrais pouvoir contourner wupclient. par contre je suis étonné que ça ne marche pas, première fois que je vois ça, avec wupclient. Tu as essayé avec wupclient de wuphax ? Il est un peu plus à jour que celuis de iosuhax. la seule fois où ça n'a pas voulu se connecter, pour ma part, c'est quand j'ai tenté d'utiliser deux clients en même temps (wupclient et wupclientgui). La connexion est à priori exclusive, une fois établie avec un client. et pas besoin d'ouvrir de port (ça reste local entre le PC et la Wii U, donc je ne vois pas bien ce qui pourrait l'empêcher d'azutant plus si ça marche en redNAND ?) ps : si ça fonctionne, un petit retour sur la vitesse de connexion serait fort sympathique (pour récupérer un backup de la rom notamment, et pour injecter une bannière si tu comptes le faire)
-
Une nouvelle version spéciale de FTPiiu, par Dimok, nous est proposée aujourd'hui. Contrairement à FTPiiu, qui ne peut accéder qu'à la carte SD de la Wii U, "FTPiiu everywhere" nous donne l'occasion d'aller fouiner dans les entrailles de la console (sysNAND). Ce qui en fait donc à la fois un outil extraordinaire mais aussi une arme à ne pas mettre entre toutes les mains ! En effet, il serait si facile de supprimer un fichier système vital et transformer votre Wii U en une belle brique presse-papier un peu chère. Il faut donc rester extrêmement prudent et agir en toute connaissance de cause. Attention ! L'utilisation de cet utilitaire nécessite un nœud /dev/iosuhax dans le fichier fw.img démarré depuis cfw booter. À cet effet, vous pouvez télécharger les dernières sources de iosuhax (la version de Dimok, pas celle de FIX94), et suivre mon tutorial pour compiler le tout. Dimok précise travailler également sur une nouvelle librairie iosuhax, qui permet aux développeurs d'intégrer de nouvelles possibilités à leurs homebrews. FTPiiu everywhere 0.1 Site officiel (GBAtemp) / source (Github)
-
Dimok ne chôme pas non plus pour améliorer la scène Wii U, mettant à notre disposition un petit utilitaire fort utile capable de dumper certains chemins (pré-définis pour l'instant) de la sysNAND vers la SD. On pourra donc s'amuser à dumper très simplement le contenu des disque de jeu, mises à jour, tickets, données slc/mlc et autres vWii. L'interface est, pour l'heure, encore très austère, type boîte de commande DOS, mais le développeur indique vouloir travailler à une interface graphique (GX2) bien plus "user-friendly", qui nous permettra également de paramétrer les chemins à dumper. Attention ! L'utilisation de cet utilitaire nécessite un nœud /dev/iosuhax dans le fichier fw.img démarré depuis cfw booter. À cet effet, vous pouvez télécharger les dernières sources de iosuhax (la version de Dimok, pas celle de FIX94), et suivre mon tutorial pour compiler le tout. FT2SD 0.1 Site officiel (GBAtemp) / source (Github)
-
pour l'instant, la redNAND fait 8 ou 32Go, impossible de passer ça sur des cartes SD de 8 ou 32Go il est prévu, normalement dans les semaines à venir, la possibilité de réduire la taille de la NAND à sa taille réellement utile, ce qui en arrangera plus d'un et crediar prévoit un gros truc aussi (indice : NEEK)
-
Devant les avancées fulgurantes du hack Wii U ces dernières semaines, Dimok remet la main à la pâte pour améliorer son launcher de homebrews. Celui-ci permet désormais le chargement des binaires compilés au format .RPX depuis la carte SD ou avec wiiload/sendelf. Il en a profité pour corriger un problème de son (clics). Attention, la prise en charge du format .RPX nécessite de nouveaux payloads. Cette nouveauté devrait permettre d'étendre encore plus les possibilités pour les développeurs, l'avenir nous le dira... Modifications / Corrections : support du chargement de binaires au format .RPX depuis la SD ou avec wiiload/sendelf nouveau loader ELF avec fonction kernel memcpy pré-installée et support des .RPX correction des "clics" audio (merci aliaspider) Note : de nouveaux payloads (fichiers MP4 pour exploit navigateur) sont requis pour permettre le chargement des binaires .RPX. Les anciens payloads restent compatibles mais uniquement pour le chargement des binaires .ELF. Homebrew Launcher 1.4 Site officiel (GBAtemp) / source (Github)
-
make est la commande qui permet au compileur, à partir du makefile, de générer les binaires et assembler le tout dans un fichier (fw.img dans le cas présent). La commande est bien make et rien d'autre (elle ouvre d'elle-même le makefile du dossier dans lequel tu te trouves au moment de taper la commande) si la commande n'est pas reconnue (au passage, ç'a n'a rien à voir avec le mode admin ou non, d'ailleurs la commande CMD n'a absolument pas à être lancée en admin ), c'est que devkitpro (plus particulièrement le module msys) n'a pas été installé correctement, il manque le chemin dans PATH ou bien msys est manquant. vérifie que tu as bien le répertoire C:\devkitPro\msys\bin, dans lequel tu dois retrouver la commande make.exe Va ensuite dans Panneau de configuration > Système > Paramètres système avancés > Variables d'environnement et vérifie que : dans la variable PATH, tu as c:\devkitPro\msys\bin qu'il existe une variable DEVKITARM contenant /c/devkitPro/devkitARM qu'il existe une variable DEVKITPRO contenant /c/devkitPro en supposant bien évidemment que tu as choisi le répertoire par défaut pour l'installation ! une variable PATH à peu près ordinaire/classique : c:\devkitPro\msys\bin;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Python on remarque l'occurrence propre à python qui doit être également dans PATH
-
Alors je n'avais pas vu ton "edit 2", mais il n'est pas complètement avéré. L'émulateur Virtual Console Nintendo DS cherche auprès du fichier rom.zip, effectivement. Mais il se fiche du nom à l'intérieur du zip. Je me posais la même question, et par curiosité, j'ai testé sans renommer le fichier .ds (mais en renommant bien évidemment le fichier zip en rom.zip). Résultat : marche nickel j'en ai profité pour tester aussi le remplacement de la bannière, c'est juste génial. Prochaine mise à jour, je développerai la méthode qui consiste à passer par la SD pour écrire de/vers la NAND. En effet, l'injection de gros fichiers (entendre par là, dès que ça dépasse le mega-octet) est très (trop) longue entre le PC et la Wii U ! En mettant les fichiers à injecter sur la SD puis en utilisant la ligne de commande cp/cpdir (copie de fichier/dossier), ça va à priori bien plus vite. Il m'a bien fallu 5 minutes pour injecter la bannière (2.63Mo toute mouillée). Comme le fichier son en fait 3.6, c'est le moment de tester. ps : ajout de haxchi 1.7 et des nouveaux jeux supportés. FIX94 est une machine !
-
FIX94 est décidément plein de ressources et repousse sans cesse les limites du hack sur Wii U. L'exploit haxchi revient donc dans sa version 1.7, ajoutant pas moins de 4 jeux supplémentaires à la liste de compatibilité : Mario Kart DS, New Super Mario Bros., Star Fox Command et Legend of Zelda - Phantom Hourglass. Désormais, les jeux Virtual Console Nintendo DS permettant de profiter de cet exploit sont donc : Brain Training Kirby Mouse Attack Legend of Zelda - Phantom Hourglass Mario Kart DS New Super Mario Bros. Star Fox Command WarioWare: Touched Yoshi's Island DS RAPPEL: s'agissant d'une faille type ContentHax, il faudra passer par le hack IOSU + wupserver pour avoir un accès en écriture à la NAND et ainsi remplacer les fichiers originaux du jeu à l'aide de wupclient. Un tutorial maison est disponible ici si besoin. haxchi 1.7 Site officiel (GBAtemp) / source (Github)
-
dans un souci d'homogénéité et de simplification, j'ai décidé de ne plus séparer les lignes de commande sysNAND/USB qui complexifient et agrandissent le tutorial pour rien. Ainsi, et pour garder une cohérence avec la notion de GAME_TITLE_ID qui représente le nom du jeu cible, l'étiquette STORAGE_ID représentera désormais le périphérique cible ex : w.up("config.txt", "/vol/STORAGE_ID/usr/title/00050000/GAME_TITLE_ID/content/config.txt") STORAGE_ID pouvant être, en fonction de votre situation : storage_mlc01 - sysNAND de votre console storage_usb01 - périphérique de stockage USB j'ai corrigé toutes les bétises qu'IPB a bien pu générer. Si vous voyez des coquilles, n'hésitez pas à faire remonter !
-
FIX94 a décidé d'épuiser les pauvres newseurs avec un rythme de releases tout simplement inhumain La version 1.5 (hier) ajoutait déjà la possibilité d'exécuter différents homebrews en fonction de la touche appuyée (paramétrable)(*), la version 1.6 quant à elle autorise un chemin vers les fichiers .ELF de 250 caractères (contre 80 auparavant) et permet aux homebrews qui le demandent de retourner sur Homebrew Launcher à la place de MiiMaker auparavant (ce qui devrait corriger le souci sur certains homebrews, tel que wupinstaller) (*) Le paramétrage nécessite la création d'un fichier config.txt qui contiendra par exemple les informations suivantes : a=fw.img b=rednand/fw.img x=wiiu/apps/ftpiiu/ftpiiu.elf down=wiiu/apps/snes9x2010_libretro/snes9x2010_libretro.elf default=wiiu/apps/homebrew_launcher/homebrew_launcher.elf Il est intéressant de noter qu'il peut charger directement un fichier fw.img, à priori sans passer par CFW Booter ! Attention, le nom du fichier doit IMPÉRATIVEMENT être fw.img et rien d'autre ! Le fichier devra être uploadé dans le répertoire du jeu contenant haxchi via les lignes de commande wupclient suivantes : si le jeu est sur votre NAND w.up("config.txt", "/vol/storage_mlc01/usr/title/00050000/GAME_TITLE_ID/content/config.txt") w.chmod("/vol/storage_mlc01/usr/title/00050000/GAME_TITLE_ID/content/config.txt", 0x644) si le jeu est sur votre périphérique USB w.up("config.txt", "/vol/storage_usb01/usr/title/00050000/GAME_TITLE_ID/content/config.txt") w.chmod("/vol/storage_usb01/usr/title/00050000/GAME_TITLE_ID/content/config.txt", 0x644) GAME_TITLE_ID étant différent suivant votre jeu : 10179A00 - Brain Age (JAP) 10179B00 - Brain Age (US) 10179C00 - Brain Training (PAL) 10198800 - Yoshi's Island DS (JAP) 10198900 - Yoshi's Island DS (US) 10198A00 - Yoshi's Island DS (PAL) 101A1E00 - WarioWare: Touched (JAP) 101A1F00 - WarioWare: Touched (US) 101A2000 - WarioWare: Touched (PAL) 101A5500 - Kirby Squeak Squad (JAP) 101A5600 - Kirby Squeak Squad (US) 101A5700 - Kirby Mouse Attack (PAL) RAPPEL: s'agissant d'une faille type ContentHax, il faudra passer par un hack IOSU wupserver pour avoir un accès en écriture à la NAND et ainsi remplacer les fichiers originaux du jeu à l'aide de wupclient. Un tutorial maison est disponible ici si besoin. haxchi Brain Training / Kirby Mouse Attack / Wario Ware / Yoshi's Island version 1.6 Site officiel (GBAtemp) / source (Github)
-
@TUK_Pyroman : le hack haxchi est plus ou moins l'équivalent de la faille MSET ou menuHax sur 3DS. Ça ne modifie en rien un quelconque fichier vital de la NAND, uniquement la rom d'un jeu Virtual Console DS. C'est totalement sûr. Mais le but n'est pas forcement de mettre en place une RedNAND (même si, actuellement, c'est le seul moyen d'avoir un accès IOSU). Le but est plutôt d'intégrer un point d'entrée permanent au hack, que ce soit HBL ou CFW Booter (ou autre, l'avenir nous le dira) sans avoir besoin de passer par la faille navigateur (qui rajoute des étapes et peut être un peu moins stable) ce qui est dangereux par contre, c'est le coldboothax, en modifiant le fichier xml du système (toute erreur sur ce fichier, c'est un brick assuré). Ma philosophie personnelle, c'est que moins on touche à un système pour le hacker, mieux c'est, évidemment ! La RedNAND n'est pas une fin en soi, pour ma part. Un simple CFW Booter qui charge un firmware patché (tel que le fait IOSUHAX pour l'instant), mais épuré de toutes ses vilaines protections anti-hack, suffirait largement. On en arriverait quasiment à une équivalence avec A9LH (qui n'a certainement pas besoin d'une emuNAND pour fonctionner merveilleusement bien) @dcx, aucune idée. Mais haxchi pourrait tout à fait être installé dessus, à mon avis. Ta RedNAND n'étant pas liée à ta sysNAND, tu ne peux pas y couper (ou alors il faudrait que l'on puisse injecter des fichiers hackés directement dans la RedNAND). Mise à jour du tutorial : j'avais oublié de préciser que la ligne de commande d'injection de la rom est différente suivant que le jeu est sur la NAND ou un périphérique USB ! J'en ai profité pour inclure les dernières améliorations depuis la version 1.5 de haxchi ! probable prochaine mise à jour du tuto : un petit encart sur la modification de la bannière et du titre du jeu (modification purement esthétique mais sympa) EDIT : IPB me sort par les trous de nez ! cette saloperie a éclaté l'ensemble du formatage de mon tuto. vraiment développé par des incapables ce moteur IPB.
-
ah, si c'est une nouvelle SD, effectivement, c'est bizarre. Le backup NAND garde certainement des traces GW...m'enfin de toute façon, comme je te l'ai dit, garder une emuNAND sous A9LH est vraiment inutile. pour démarrer HBL, c'est via CIA ou faille. Sous A9LH, la meilleure reste la version CIA. Si un homebrew plante, c'est qu'il faut chercher une mise à jour (ou s'en passer )
-
je confirme avoir modifié ton mail pour procéder à la réinitialisation de ton mot de passe. ton second compte a été fusionné et supprimé. Logiquement, tout devrait rentrer dans l'ordre. re-bienvenue parmi nous (ps : j'ai répondu à ton questionnement 3DS)
-
ok, merci de ta confirmation, je modifie en conséquence.
-
merci pour ton retour sur OTP.bin. N'ayant pas accès à ma console, je ne pouvais pas tester. mais comme je l'ai noté dans le tuto, teste à l'extérieur du dossier iosuhax-master. D'après le script, il remonte l'arborescence de deux niveaux (c'est con, mais c'est comme ça, je pense que ça a été fait pour compiler iosuhax-master directement sur la SD qui dumpe l'OTP). effectivement, ça ne mange pas de pain de rajouter que c'est pour 5.5.1
-
salut, je demande au cas où, mais tu as vérifié dans la boîte à spams ? Hotmail a tendance à être un peu bête et filtrer un peu trop fort. si vraiment ça ne passe pas, je peux modifier l'adresse mail directement sur ton compte. Pour être certain que ce soit bien le tien, j'enverrai un message à l'adresse renseignée dans ton profil "D@ve", il te suffira d'y répondre en me précisant ta nouvelle adresse gmail et je m'occuperai du changement dans la foulée EDIT : mail envoyé.
-
FIX94 ne semble jamais se satisfaire de son travail, déjà énorme, sur la scène Wii U et met une fois de plus à jour l'exploit HAXCHI. La compatibilité n'a pas changé, à savoir Brain Training, Kirby Mouse Attack, Wario Ware et Yoshi's Island DS mais des améliorations et corrections ont été apportées, parmi lesquelles : Correction de la corruption d'écran au chargement de Homebrew Launcher Modification du chargement de l'exploit IOSU dans la partie haute de MEM1 pour éviter les plantages Mise à jour du loader de Homebrew Launcher pour être compatible avec le dernier commit de Dimok (chargement des .rpx) RAPPEL: s'agissant d'une faille type ContentHax, il faudra passer par un hack IOSU wupserver pour avoir un accès en écriture à la NAND et ainsi remplacer les fichiers originaux du jeu à l'aide de wupclient. Un tutorial maison est disponible ici si besoin. haxchi Brain Training / Kirby Mouse Attack / Wario Ware / Yoshi's Island version 1.4 Site officiel (GBAtemp) / source (Github)
-
safea9lhinstaller, decrypt9wip, emuNAND9 et en général, tout ce qui contient la particule "9" dans son titre, sont des applications ARM9 nécessitant OBLIGATOIREMENT de passer par la méthode PAYLOAD. pour le reste, il se peut que tel ou tel homebrew ne soit pas compatible avec le payload utilisé sur ta console, soit parce que le homebrew est trop ancien et ne le gère donc pas, soit parce qu'il est buggué. Decrypt9 lit ton emuNAND sur la SD, qui a été générée par GW (la méthode de partitionnement est particulière à GW). La seule façon de tout remettre à plat, c'est de totalement détruire le partionnement de la SD, recréer une partition simple qui contiendra le payload nécessaire pour recréer une emuNAND "propre". Cependant, continuer à utiliser une emuNAND avec A9LH est un non-sens inutile et lourd, tu te compliques la vie pour rien (il n'y a aucune protection supplémentaire en emuNAND, dans ce cas !). Tu peux tout à fait utiliser directement ta sysNAND + la SD pour le stockage.
-
merci pour la précision, je n'avais pas testé, même car curiosité, de faire un make directement (je pensais même qu'il fallait exécuter le script dans sections) je vais alléger le tuto de cette partie inutile EDIT : ajout des chapitres manquants, jusqu'au final (HAXCHI)
-
petite précision sur les hashes MD5 : bien évidemment, ce sont des hashes à un instant t, pour des sources à un instant t également. dès qu'une modification, aussi infime soit-elle, aura été faite, les hashes seront affectés. le hash MD5 de la version de FIX94 correspond au commit du 4 novembre 2016 la vérification permet juste de valider son installation devkitpro + python + pycrypto + armips ps : si je préconise python 2.x sur mon tuto, c'est juste parce que, sur un certain nombre de scripts python (autres que ceux d'IOSUHAX), la branche 3.x pose problème. ça n'a pas un caractère obligatoire (merci Vincenti de l'avoir confirmé sous Python 3.5) mais c'est plus pérenne en 2.x pour les bricoleurs comme moi
