Badablek

48 heures dehors pour lire la charte.

dans tous les cas, les clés ne correspondraient jamais au cryptage de la NAND. Tu aurais soit les bonnes clés pour la mauvaise NAND, soit la bonne NAND mais les mauvaises clés. Tu peux retourner le problème dans tous les sens, ça sera toujours comme ça. quant bien même (imaginons) on pourrait swapper à chaud le GPU pour essayer de dumper les clés, on n'obtiendrait rien. Déjà parce que ça voudrait dire risquer de flinguer 2 wii pour en réparer une (mathématiquement c'est du suicide), ensuite parce que c'est physiquement impossible (jusqu'à preuve du contraire, retirer à chaud un GPU, ça risque de faire de la fumée et un joli écran noir...et rebiller à chaud est tout aussi impossible). la seule chose que je verrais comme "attaque", ça serait un dump de la ram GDDR3 à la recherche des clés, en supposant que même brickée, une wii arrive au moins à stocker ces clés en ram, et qu'elle y stocke bien les clés HMAC et NAND (la common-key y est, ça c'est sûr...mais on la connait déjà et en l'occurence, elle ne sert à rien pour crypter/décrypter la NAND). Bref, cette wii te servira plus en tant que presse papier, plutôt que de chercher l'impossible (réparation). Tu vas te faire des noeuds au cerveau pour une chimère, ça ne vaut pas vraiment le coup

à priori, aucune chance. après, on dit toujours qu'il ne faut "jamais dire jamais"...mais dans ce cas bien précis, ça semble bel et bien grillé. A moins de trouver un moyen de dumper les clés de manière hardware (les plus "grands" s'y sont déjà cassés les dents) ou de pouvoir générer les bonnes clés, ce qui est tout simplement impossible vu le nombre de possibilités pour une clé de 16 octets, sans compter qu'il faut en plus de la clé NAND, la clé HMAC (20 octets) correspondante !

salut, si le module bluetooth était cramé, la console ne démarrerait même pas. après, est ce qu'il peut être juste légérement endommagé pour ne pas empêcherl a console de booter, c'est une bonne question. au pire, un module BT, tu en as pour quelques euros...et sachant que deux wiimotes ont le même symptome, il y a vraiment une infime chance que ça vienne des wiimotes, ou alors ça serait une sacrée coïncidence que ça soit pile poil au même moment qu'elles tombent en panne...et de a même panne...)

ce que tu cherches à faire est tout simplement impossible. Pour t'en convaincre, je t'invite à lire ceci : http://marcansoft.com/uploads/25c3_console_hacking/# tu as déjà eu les réponses dans ton précédent sujet, ça n'a donc pas changé d'un iota depuis, et ça ne changera très certainement jamais. Pour résumer la situation : le boot0 est contenu dans une ROM à l'intérieur du GPU Hollywood, inaccessible de l'extérieur (de manière hardware par puce par exemple). Il détient les clés de la console (clés servant entre autre au cryptage/décryptage de la NAND) ainsi que le hash du boot1. La seule façon de dumper ses fameuses clés est de manière logicielle, autrement dit la console doit fonctionner et pouvoir lancer des homebrews ! le boot1 est contenu dans les premiers blocs de la NAND. Il contient le hash du boot2. le boot2 est contigü au boot1 dans la NAND. C'est lui qui se charge de démarrer le system menu de la console. Boot1 et boot2 ne sont pas cryptés dans la NAND, ce qui permet de swapper ces fichiers, via une puce infectus notamment, avec les dumps d'un autre boot1/boot2 par exemple (mais la console ne démarrera que si les hash sont identiques à celui que détient le boot0 !). C'est pourquoi il est aussi possible d'injecter un boot2 contenant bootmii d'une console "a" à une console "b", pourvu que la faille bootmii soit présente; ce qui n'est pas le cas de ta wii en boot1c. Le processus de boot, schématiquement, c'est : boot0 démarre, il vérifie que le hash du boot1 est correct. Si tout est ok, il poursuit en lançant boot1, sinon le processus s'arrête, la console ne démarre pas. si tu t'amuses à remplacer un boot1c par un boot1b, son hash (contenu dans boot0) ne correspondra pas, la console ne démarre pas ! boot1 démarre, il vérifie que le hash du boot2 est correct. Si tout est ok, il poursuit en lançant boot2, sinon le processus s'arrête, la console ne démarre pas. si tu t'amuses à remplacer un boot2 original par un boot2 bootmii alors que c'est un boot1c (plus de faille bootmii !), la console ne démarre pas ! boot2 démarre, il se charge de lancer le system menu, tout le monde est content, la console est enfin démarrée et le system menu chargé. si tu swappes la NAND de la console malade par la NAND d'une autre wii (et inversement), les clés ne pourront pas décrypter les données (system menu+IOS+chaînes, etc.), la console ne démarre pas ! la faille utilisée par bootmii (corrigée depuis pas mal de temps maintenant) repose sur le fait, si ma mémoire est bonne et que j'ai bien tout saisi, que le fichier boot2 est en fait divisé en 2 copies identiques. Si la première moitié se retrouve corrompue pour une raison x ou y (mise à jour foireuse du boot2 ?), la seconde partie prend le relais...et celle-ci n'est pas vérifiée au niveau du hash contenu dans le boot1 ! Et c'est là que bootmii prend donc place pour dévier le processus de boot vers le bootloader de bootmii, au chaud sur la SD. Bref, tu vois très bien que dans tous les cas, il est impossible de démarrer bootmii sur une console "boot1c", par quelque moyen que ce soit. Et sachant que les clés ne sont contenues QUE DANS LE GPU HOLLYWOOD, "émuler" la NAND est d'une part impossible vu que la NAND est cryptée, et d'autre part totalement inutile (car ne contenant aucune donnée succeptible de pouvoir décrypter son contenu). C'est le serpent qui se mord la queue : pour pouvoir décrypter la NAND (et accessoirement pouvoir la swapper via un recryptage par le logiciel betwiin), il te faut les clés; pour avoir les clés il te faut pouvoir démarrer la console et exécuter le logiciel pour dumper ces clés. Si une wii boot1c ou supérieur tombe malade (au niveau de la NAND) sans avoir récupéré les clés au préalable, tu auras beau faire ce que tu veux, tu ne pourras JAMAIS échanger ou réparer quoi que ce soit

si tu es en kernel 9199 et que tu appliques la MAJ 9199+avatar, ça ne fera PAS une mise à jour complète. la résistance R6T3 n'a donc aucun rapport avec le schmilblick dans ton cas précis. Qu'elle soit là ou non, seuls les fichiers manquants seront installés, et le JTAG ne sera pas écrasé. Quitte à répéter ce qui a été dit plus haut, si la MAJ correspond exactement à la version du kernel JTAG, alors pas de souci.

je ne pense pas trop me tromper en disant que si ta console est à jour et ne supporte pas un quelconque moyen de récupérer la clé CPU et DVD (hack JTAG), tu peux déjà la mettre à la poubelle. tu n'as fait aucun backup de ton firmware DVD original ? EDIT : grilled d'une minute.

il est aussi prévu que le kernel intègre un emulateur natif snes attention, les premiers tests en mode GBA révèlent que la batterie se prend une sacrée claque derrière les oreilles. C'était à prévoir, avec un CPU supplémentaire à nourrir http://gbatemp.net/t225251-supercard-dstwo-hands-on-preview

ou simplement les récupérer sur GX...hebergés depuis le 6 mai http://gx-mod.com/xbox/modules/news/article.php?storyid=5140

qu'est ce qui est étrange...tu n'as jamais vu une console marcher en composite (YUV) et pas en composite (RCA) ? et sachant que la wii détecte automatiquement le type d'affichage, aller dans les options ne risque pas d'aider en quoi que ce soit. si câble composante > sortie en 480p si câble composite > sortie 480i max ça sent la carte mère frelatée cette histoire. Tu es sûr de ton câble composite ?

ce n'est pas tant la gratuité de la chose, mais surtout la facilité déconcertante pour y parvenir. Le piratage sur Nintendo DS, comme sur Wii, est surtout dû à un manque évident de moyens injectés pour sécuriser leurs consoles. Ils ne peuvent pas venir se plaindre du piratage alors qu'ils ont investi dans des sécurités au rabais pour faire baisser au maximum les coûtés de R&D et de production. La wii reposait sur la gamecube, déjà piratée > première erreur grossière les premiers chipsets DVD avaient encore la partie "debug" > deuxième erreur enorme une faille mathématique dans le calcul du hash (faille trucha) > troisième erreur (et la meilleure pour ceux qui adorent les homebrews) Linkers GBA fonctionnels sur DS > première erreur Bug au niveau du slot1 pour la DS > la protection RSA ne sert plus à rien > passme, linkers GBA en mode DS Sortie des linkers slot1 > aucune contre-mesure pour la Lite on se reveille un peu avec la DSi, mais pas de bol, on fait les choses à moitié, la brèche est à nouveau ouverte sortie de la XL, et du system menu 1.4, idem, contournée en quelques jours. Ils ne peuvent s'en prendre qu'à eux-mêmes sur le coup. Maintenant, encore heureux qu'ils ont cherché de nouvelles protections, le contraire aurait été indigne de leur part ! Mais y'a toujours plus malins que les meilleurs ingénieurs...l'avenir nous le dira.

je confirme qu'avec wood, certains clones sont aussi bien, sinon meilleurs, que certains linkers plus chers et plus "in". clone ne rime pas forcement avec daube. faut arrêter de tout mettre dans le même panier. Surtout de la part de personnes qui n'en utilisent pas et n'en ont peut être même jamais vu ! Alors oui, avec le kernel original 1.18 qui a plus de 2 ans, un R4 n'a que peu d'avenir...mais sous Wood R4, ça transforme la grenouille en princesse, et le rend aussi compatible et bien plus rapide que la plupart de la concurrence. Les fakes sont merdiques, ça, ce n'est un secret pour personne...mais certainement pas les clones ! maintenant, si les anti-R4 ne sont pas capables d'argumenter au lieu de sortir un vague "R4 c'est de la daube", dites le de suite, autant locker le sujet dès à présent ! parce que les joutes verbales dignes d'une cour de primaire, ça va bien 5 minutes.

bonne nouvelle, et merci de ton feedback sur cette méthode. il semble donc bien que certains jeux permettent le hotswap...par contre ça nécessite obligatoirement un IOS36 avec faille trucha (ce qui était ton cas).

il serait préférable d'utiliser un jeu que tu n'aurais jamais lancé auparavant. ou de vraiment remplir la NAND (0 bloc restant) , et là, la console t'emmenera directement dans la gestion de la mémoire.

exact j'ai fait un petit mélange des fonctionnalités des puces nappe sur D3-2/D4 ^___^

d'un autre côté, pourquoi dépenser du temps (et donc de l'argent) à créer de nouvelles générations de puce, quand les puces solderless marchent très bien, même avec les derniers modèles (y compris ce petit nouveau) ? Certes elles sont bridées en 3X, mais ça ne semble gêner personne...du moment que ça marche. ce n'est pas vraiment Nintendo qui est en avance, juste les teams qui n'ont aucun interêt financier à chercher de nouvelles méthodes d'attaque de ces chipsets. quand on voit le temps qu'il a fallu à Big N pour contrer une simple Yaosm, ou encore le hack TP, ça fait peur tant qu'ils ne prendront pas le taureau par les cornes pour stopper net (et définitivement) les puces nappe solderless, je pense que ça restera en l'état niveau puces.

le hotswap ne marchera certainement pas (sauf à priori cas extrêmement rares, voir méthode Castlevania tout en bas). Légende urbaine. si c'est qu'un bannerbrick, plusieurs solutions s'ouvrent à toi : Méthode "je blinde la mémoire de ma wii (2137 blocs): il faut des jeux qui nécessitent enormement de place pour les sauvegardes. Tu crées des profils, sauvegardes, etc avec ces jeux, de manière à bourrer à craquer la mémoire de la wii. Quand il n'y aura plus de place, le jeu va automatiquement t'envoyer sur l'interface de gestion des chaînes. Tu supprimes la chaîne fautive, et le tour est joué. L'interêt des jeux gourmands en sauvegarde prend tout son sens pour gaver la mémoire rapidement : Save game Block Usage: GAMES: SSBB : 128 blocks ( can do USA and PAL save separate for 256 blocks) Drawn to life: next chapter : 77 Blocks Mario Kart : 23 blocks Guitar Hero world tour : 25 blocks Pikmin : 31 blocks Endless Ocean : 34 Blocks Petz Crazy Monkey : 21 blocks Quantom of Solace: 97 Blocks Harvest Moon Tree of Tranquil : 25 blocks Animal Crossing : City Folk : 36 blocks MySims Kingdom : 121 blocks MySims: 97 Blocks Elebits: 109 Pokemon Battle Revolution: 29 blocks Call of duty WAW: 63 blocks Need for speed Nitro: 121 blocks Wii Ski = 81 blocks Simcity creator = 127 blocks Ultimate Alliance 2 =20 blocks Pro Evolution Soccer 2010 : 120+ blocks CHANNELS: Rabbids Channel : 77 blocks ( can be installed once then again to cause low space data management workaround) Mario Kart Channel: 78 Blocks Internet Channel : 222 Blocks Wii Fit channel: 120 blocks http://forum.wiibrew.org/read.php?22,43230 Quand il ne reste plus qu'une centaine de blocs libres, il suffit de lancer un de ces jeux : Rabbids Go home (need around less than 77 blocks) MySims Agent (96 blocks or less) Mysims Kingdom (200 blocks or less) Mysims racing (i think 3 blocks or less) etc mysims games pour pouvoir accéder aux options de la console et formater. ps : si tu n'as plus un seul bloc de libre, la console va elle-même t'envoyer dans les options de gestion des sauvegardes. Méthode Wiifit au premier lancement du jeu, il te demande si la date et l'heure sont correctes...avec la possibilité d'aller directement dans les paramètres de la console, ce qui te donne un accès à l'option de formatage (je ne sais pas si tu peux aller dnas la gestion des chaînes pour ne supprimer que la chaîne fautive). Autre méthode ? Method- Castlevania Judgment How to load HB apps from disk, without a patched system ios. Requires ios36 to be patched, from TBR or dop-mii or other method. If you where silly (stupid) and did not install priiloader, and did not patch your system ios, and for some reason managed to brick your wii in a banner like way- you are basically screwed. But perhaps not yet. Fixing these type a bricks is a pain, and there are very few options to try. So here is another one- What does this do- Loads wadmanager 1.4 from autoboot disk, when ios36 is patched but the system ios is not. Requirements- Functional RM via savmii/savmiifrii (gc-controller) Ios36 must have the fakesign bug, aka trucha bug. You will need a modchip, preconfigured to autoboot, region free enabled Castlevania Judgment, unscrubbed iso (tested with ntsc-u version) Download: iso-tools.zip WM_1.4.dol.zip Extract to the location of Castlevania Judgment iso. -Burn Castlevania Judgment iso, burn it good and proper -Run MakeKeyBin.exe, type 42, click generate -Run WIIScrubber.exe Click load ISO, select Castlevania Judgment iso Double click Partition 1- data Right click on main.dol, Click replace Select WM_1.4.dol main.dol name will not change Exit -Burn the patched Castlevania Judgment iso, burn it good and proper -Boot the wii and load the Recovery Menu via savemii/savemiifrii. You should see a black screen with your system menu version # -Insert your Castlevania Judgment disk, it should boot Let the game load to the intro movie, eject the disk you will see "error please instert Castlevania Judgment disk" -Insert you patched Castlevania Judgment disk The intro movie plays again, goto the main game menu Push "Home" on the wiimote and click "restart" -Wadmanager 1.4 will load, push A to install/uninstall wads, or push B to exit to HBC -Now fix your wii, you will have to have some idea of what you need to do. If wadmanager fails to load and you are booted to your brick error- you do not have a patched ios36 If the patched game boots to a black screen, there is an issue with your main.dol, tray again or try another useful dol. Games that I know use ios36- Mario Kart, SSBB, Castlevania Judgment- if you know of others, let me know Mario Kart- fails with this method (at least the ntsc version) SSBB- ntsc does not work, pal version may work This method can be duplicated with other games running on other ios, as long as the ios is patched. If you think you have other patched ios, you can try other games. Ios36 is the most common patched ios loaded by games. That is why it was chosen here.

embed : un seul mot : magnifique !

en voila une nouvelle qu'elle est bonne ^___^

salut, les jeux Gamecube n'utilisent pas le même processus pour démarrer. Là où un jeu Wii utilise un IOS, un jeu Gamecube communique directement par le mIOS spécifiquement crée à cet effet. je doute donc que l'on puisse lancer les jeux GC de cette façon.

on n'est pas madame Irma. Je ne vois pas comment on pourrait le savoir à moins d'être le développeur... ps : pas la bonne section, donc poubelle.

non, de l'aveu même de Bushing : Nintendo a (enfin) bien fait ses devoirs en colmatant correctement la faille qui permettait l'installation de bootmii en boot2. n'y compte même pas sur les nouveaux boot1/2. Et vu que chaque boot est vérifié (correctement désormais) par le boot précédent lors de la phase de démarrage, et que le premier boot (0) est logé directement dans le CPU, ainsi que toutes les clés de cryptage propre à chaque wii, c'est grillé. alors à moins de trouver un moyen de dumper les clés contenues dans le CPU, ça risque d'être dur. Sans compter que ces fameuses clés sont au chaud dans une mémoire interne du CPU, inaccessible de l'extérieur (câblée en interne) et donc inviolables même par une puce. donc autant le graver dans l'inconscient collectif : bootmii boot2 ne risque pas d'être compatible avec les wii actuelles (boot1c et supérieurs).

bonjour, il faut reculer la date de la console. C'est un bug connu de ce clone. Toute date supérieure au 15 avril 2010 (si ma mémoire est bonne) fera irrémédiablement planter le linker. ps : y'a une section R4, merci de faire un effort la prochaine fois.

tu n'as absolument rien compris au fonctionement de la wii. et tu n'as pas respecté le tuto à la lettre, parce que sinon tu n'aurais pas ce genre de problème. Si le cIOS était installé (ce dont je doute), wad manager (ou i/s wad ou channel file manager) ne ferait PAS d'erreur -2011. le cIOS est tout simplement obligatoire, sauf utilisation d'une méthode encore plus compliquée (si tu n'arrives pas à installer un cIOS, alors ne cherche même pas à utiliser la méthode SNEEK, tu vas t'y casser les dents !) donc relis le tuto comme il se doit, pour une wii 4.2. Si ça a marché pour tous ceux qui l'ont déjà suivi, y'a pas de raison que ça ne marche pas pour toi. et quitte à me répéter, -2011 = pas d'accès à la NAND. (et NON, ça n'a rien à voir avec le fait d'avoir dumpé la NAND !)

fais donc ça pour planter définitivement ta console, comme ça tu auras tout gagné. si tu t'obstines à ne pas lire les tutos et à lire n'importe quoi sur certains sites qui ne semblent pas savoir de quoi ils parlent, tu vas transformer ta wii en presse papier. y'a UN tuto qui centralise TOUTES les manipulations, c'est pas compliqué de l'appliquer...si tu t'en donnes la peine. http://tutoriaux.gueux-forum.net/index.php...TOUTES_VERSIONS au fait, erreur -2011 = pas d'accès à la NAND, ce qui est NORMAL pour une wii 4.2. Donc une fois de plus, TUTO. ps : ceux qui affirment qu'il faut DG sont des pingouins qui n'ont rien compris et qui devraient se mettre au jardinage au lieu de raconter des conneries plus grosses qu'eux.