dinozore

Membres
  • Compteur de contenus

    1 774
  • Inscription

  • Dernière visite

Tout ce qui a été posté par dinozore

  1. Lu, Il faut chercher un peu : http://tutoriaux.gueux-forum.net/index.php...r_votre_wii_4.0 Après tu repasses en 4.1 waninkoko. ++ Dino
  2. dinozore

    Problème De Maj Avec Wasabi Dx

    Lu, Si tu ne fais pas de homebrew alors vas'y : fais la mise à jour de la console et par internet de forte préférence (ça plante moins souvent et ça t'évite de changer les options de configuartion de ta puce). L'option de blocage a double emploi : - Dans un premier temps bloquer les maj étrangères. C'est très utile. - Dans un second temps bloquer les maj locales "au cas ou" vu qu'on sait jamais. Ca n'a encore jamais été utile en ce qui concerne les puces. Sur Wasabi Dx il me semble qu'on peut pas détailler : soit on bloque tout, soit on bloque rien. Mais bon pas sûr vu que je connais mal les wasabi. ++ Dino
  3. Lu, 95% de chances pour qu'il s'agisse de jeux ntsc. Rachète toi la version PAL ou cherche des infos sur le dézonage total (HBC+geckoOs). Sinon si c'est pas ça c'est que tu as bloqué les mises à jour dans les configuration Wiikey mais normalement tu le saurais si c'était le cas. Dans quel version de firmware est ta Wii ? ++ Dino
  4. Lu, Si SSBB passe c'est que tu es déjà en 1.9g ou 1.9s donc, sauf en cas de soucis avec les points cités dans le tuto, tu n'as aucun besoin de mettre à jour : tous les jeux récents passeront sans soucis. Tu n'as pas besoin non plus de changer de puce, la Wiikey 2 n'étant utile que pour les nouveaux modèles de Wii incompatibles avec les anciennes puces comme la Wiikey 1. EDIT: Comme la question revient régulièrement je l'ai rajoutée à la fac (n°21). ++ Dino
  5. Lu, Si je comprends bien ça voudrait dire que les clés sont simplement stoquées dans le fichier nand bootmii mais que le contenu de la nand physique n'est pas crypté avec ?! Pourtant je croyais que le Boot1 et le Boot2 étaient tous les deux cryptés puis hashés ?! Etrange, je vois pas pourquoi alors bootmii refuse d'injecter une nand obtenue sur une autre console s'il n'en a pas besoin ou s'il lui suffisait de la récupérer à la volée sur la console depuis laquelle il s'éxécute. Par sécurité ? A mon avis c'est juste qu'il la stoque en plus dans le fichier pour comparer avec les clés de la machine histoire que le Boot0 n se retrouve pas avec un Boot1 indécryptable. Logiquement pour que ça soit compatible il faudrait décrypter, recrypter, puis hasher. Ce qui est tout à fait faisable si on a les clés vu qu'il s'agit d'algos très standards. Ensuite il faudrait également rendre le dump bootmii compatible avec le soft de l'infectus. Là ça devrait être assez facilement faisable, il ne devrait manquer que des contrôles de redondance mais apparemment, à ce qu'en dit l'auteur de l'article, ils se sont déjà penchés dessus sur le forum de bootmii. En tout cas si ça fonctionne cette méthode devrait permettre de récupérer absolument tous les bricks, y compris les low-level. A suivre. Demain si j'ai la motive je regarderai déjà si je trouve trace des clés dans le fichier nand. Ca serait sympa si ça pouvait fonctionner. EDIT: J'avais lu une histoire de version du boot2 qui ne devait pas être de version inférieure ou un truc comme ça dans une théorie sur le transfert de nand. Je crois que c'était en raison des versions du boot0 qui checkait le fait que la version ne soit pas inférieure (voire même égale je sais plus) à une telle version selon la série de la console. Il me semble même que c'était de Bushing mais bon là j'ai vraiment trop la flême de chercher, je vais dormir. En tous cas il faudrait aussi tenir compte de ça (ou les récupérer sur la nand pourrie -Boot1 et Boot2- comme y'a de grande chance que le problème vienne pas de là mais du reste de la nand corrompu). Merci pour le lien en tous cas. ++ Dino
  6. Re, Les 16ème et 17ème pattes ont pas l'air très nettes. Vérifie déjà au multimètre sur la position ohmètre (pas bipeur). Et de toute façon nettoie (edit: avec de la tresse pour ton cas) ça pourra être que mieux. ++ Dino
  7. Lu, @Romain> Nettoyer tout ça proprement à la tresse et vérifier ensuite au multimètre qu'il n'y ait plus aucun court circuit. ++
  8. Lu, Pour ton pc qui ne veut pas booter sur la clé, mon ancien pc me faisait la même. Le soucis a été simplement résolu avec une mise à jour du bios. Pour le liteon, ton l-oeras n'a probablement pas fonctionné correctement. Tu as fais attention d'avoir le bon code retour ? ++ Dino
  9. Lu, La réponse à tes question est simple : refais tes backups proprement sans les patcher et ça devrait fonctionner s'ils t'ont laissé lecteur+puce d'origine. ++ Dino
  10. Lu, Merci. Ca fait plaisir que ça soit encore utile. ++ Dino
  11. Lu, Ok, merci pour la confirmation. ++ Dino
  12. dinozore

    Firmware Updater v4.1

    Lu, Cool, merci pour l'info. ++ Dino
  13. Re, Tu as mal lu ou en tout cas ces des conneries. Ca a eu brèvement posé des soucis à l'époque des 2 premières version de la d2ckey qui était alors là seule puce pour chipset > d2b. Fais voir la photo même si selon moi si le disque de config passe c'est pas le montage qui est en cause. ++ Dino
  14. Re, T'as pas regardé au bon endroit. C'est le chipset d'à côté, celui un peu plus petit. ++ Dino
  15. Lu, Très probable. Wifi ou bluetooth. Sinon j'vois pas non plus. Ou alors il lit les gueux et il s'est dit qu'il valait mieux la jouer fine sur ce coup. ++ Dino
  16. Lu, Si le dvd de config est bien passé c'est qu'elle est bien installée. Ton soucis doit venir du dvd/graveur/iso. ++ Dino
  17. dinozore

    Le hack DSi est est en marche

    Lu, Super news ! Ca risque d'être encore autre chose le hack sur DSi s'ils parviennent à leur fins (et à mon avis il y a de grandes chances pour que ça soit le cas). Merci pour l'info. @bitonio> Toi plus personne t'explique quoi que ce soit, tu reposes les mêmes questions deux semaines après comme si on avait rien dit. Edit: @Badablek et dégueux> Je lisais un peu le début du topic, et je n'avance rien parce que je n'ai aucune idée de comment peuvent bien fonctionner les rom snes, mais je pense que votre conflit vient d'une incompréhension due à la confusion entre cryptage et codage. A mon avis comme sur la plupart des systèmes embarqués ou même plus largement des contextes d'éxécution où l'espace de stocage est limité, on va tendre à coder l'information sur un minimum de place, surtout si celle-ci revient souvent. Par exemple pour du texte uniquement en majuscule on ne va souvent utiliser que 5 bits, etc. Il y a une infinité de combinaisons possibles en fonction du besoin. Après : - Soit c'est une norme et c'est le compilateur qui se charge du transcodage pour le texte du code et les ressources, puis le packeur pour les données, le système éxécutant étant à la norme - Soit c'est libre et dans ce cas chaque fichier de données ou plus globalement chaque jeu possède une ou des tables de spécification de son ou ses codage pour que le système éxécutant conçu pour prendre en charge cette fonctionnalité s'y retrouve - Soit c'est un mélange des deux solutions pour permettre des utilisations plus spécifiques au besoin Comme un éditeur hexadécimal n'est pas devin, il se contente d'afficher les bits dans la correspondance la plus utilisée/standard, c'est à dire avec une interprétation par groupement de 8 bits (donc par octet) avec en plus un transcodage sur la table ascii de ces octets. Les caractères système ainsi que les caractères de la table ascii étendue (qui pour rappel eux ne sont pas universels) étant représentés par des points. Alors on peut dire qu'essayer d'aller lire directement ne serait-ce que le texte contenu dans une rom avec un éditeur hexadécimal c'est presque peine perdue d'avance. Donc rien n'empêche que les données de la rom soient simplement codées et qu'une portion de la rom soit en plus cryptée. ++ Dino
  18. Lu, On me posait la question justement pas plus tard que hier et je me suis demandé si la bannerbomb fonctionnerait pas dessus ? Parce qu'avant le soucis venait du fait qu'il n'y avait pas de version koréenne du jeu ZTP. Il me semble bien avoir lu un retour d'expérience sur ce point mais impossible de me souvenir si c'était positif ou négatif. ++ Dino
  19. Lu, C'est clair. 99% des papas qui font monter une puce en ont strictement rien à faire et veulent juste que ca fonctionne et les gosses leur fichent la paix. ++ Dino
  20. Lu, En tous cas ça n'était sûrement pas la bonne boutique ! http://gueux-forum.net/index.php?showtopic=176368 ++ Dino
  21. Lu, Encore une fois tu chipotes. Ca dépend d'où on place la puce et de toutes façon à un centimètre près ça change absolument rien ici. ++ Dino
  22. Lu, Plutôt que de nous sortir des "on dit que", tu devrais essayer. Jète un coup d'oeil <Ici> déjà. Après je suis d'accord, on travaille mieux avec du câblage rangé mais bon, ça fonctionnait ou pas ? ++ Dino
  23. Lu, C'est surtout que si tu n'as pas bricolé ta console logiciellement, à part à se prendre la tête ça ne sert à rien de ne pas les faire. Tu peux y aller, aucun soucis. ++ Dino
  24. Lu, Je tombe par hazard sur ce topic... T'as vu cette vidéo datant de 8 ans auparavant ? ++ Dino
  25. Lu, Le montage poulpe c'est un choix, le reste c'est de l'esthétisme. Tu payes pour que ça fonctionne bien, pas pour que ce soit beau surtout si c'est pris en sandwich entre lecteur et carte mère donc totalement invisible. La colle ça fait une sécurité en plus, ça n'empêche pas que les soudures soient très bonnes à la base. ++ Dino