dinozore

Membres
  • Compteur de contenus

    1 774
  • Inscription

  • Dernière visite

Messages posté(e)s par dinozore

  1. Lu,

    Merci pour la news et le fichier. :)

    @mikratek : Aucun FW n'est identique. Un seul bit de modifié et tu as un cheksum différent pour chaque console.

    Seulement voila, si MS avait tout bêtement créer une BDD des cheksum de toutes les consoles qui sortent de leurs usines (je parle uniquement du FW du lecteur ici) et donc un cheksum lié a une adresse MAC ou numéro de série, et s'ils ont moyen de lire le FW a distance, suffit de comparer au cheksum enregistré a la sortie d'usine(même pas besoin d'une personne tierce) de maniere automatique. Et la on prend un mois dans l'année et on lance une vague de BAN pour bannir ceux qui était déjà ciblé et ceux qui se connecte de manière instantané.

    Alors dans ce cas la, même le super LT ne pourra JAMAIS être indétectable...

    Vu que la console connait les emplacements de la clé, il lui suffit tout simplement d'ôter cette dernière du calcul de hash. Dans ce cas un firm dans une version donnée aura toujours le même hash, sauf s'il a subi la moindre modification.

    Aucun besoin pour kro$oft de se prendre la tête plus que ça.

    D'ailleurs le pire c'est que celui ci étant crypté, si ils sortent le "vrai" LT non crypté il sera impossible de comparer les 2 pour savoir si ils sont identiques j'imagine ?

    Ils ne prendront pas le risque de le distribuer en clair, ils changeront tout simplement le cryptage ou plus probablement la clé.

    Tant qu'on ne connaitra pas l'algo, pas moyen pour nous de vérifier quoi que ce soit.

    nostealth, à tester...

    attention, il y aura surement bientôt une mise à jour de JF pour empêcher le flash de ce lecteur mais c'est tout simplement logique j'ai eu échos que la dernière version ne supportait pas le 1.60 NO Stealth donc wait and see pour voir comment ça réagit...

    il y aura des applications tierce , et puis si tu a la clé ,tu fais ce que tu veux après pour l'implémentation de ton firmware ,même le faire en hexa comme aux temps immémoriaux :D

    Ou tout simplement des versions débridées de JF...

    ++

    Dino

  2. Lu,

    :(

    Ca serait quand même plus simple qu'ils se mettent d'accords, surtout qu'il est pas question de toute une stratégie mais seulement d'un emplacement...

    Merci pour la news.

    ++

    Dino

  3. Lu,

    bonjour,

    désoler de vous embeter mais le lien pour telecharger la version v1.3 - 'Odyssey' a l aire d'etre mort. si quelqu un pouvais m en indiquer un autre car je n arrive pas a trouver.

    merci d avance.

    ;)

    Effectivement.

    Tu peux le récupérer <Ici> en attendant pour la version Pal.

    Sinon le problème est résolu de mon côté.

    J'ai pas tenu informé avant mais entre temps j'ai refait une install propre de Xp parce qu'il était grand temps, puis refait l'extraction pour la troisième fois desfois que.

    Et bien là plus aucun soucis. Le hash n'étant pas le même je pense qu'il y avait avant une légère corruptions au niveau des données ce qui fait que le disque ne passait pas car signature incorrecte. Je sais pas, pas le temps d'investiguer d'avantage, mais en tous cas ça roule.

    Je repasserai donner les hashs de l'extraction qui va bien pour moi (pas sous la main là).

    Edit:

    CRC32: 3B9CB3E8

    MD5: 730CA2C2BD3A8B5DFAEFE8FAC024A7CA

    SHA-1: DB0360862CA9D918FEC82C411F8455678C59738F

    ++

    Dino

  4. Lu,

    J'ai pas lu la réponse des autres... Mais bon tu peux foutre un coup de cryptage AES puis un coup de Zlib... Ou l'inverse... d'une manière dont tu as envie, c'est à dire sur le début du fichier ou autre... Pour en quelques sorte créer ton propre format !

    Après si on veut vraiment le modifié suffit de mettre un coup de désassembleur dedans mais bon Nintendo ni résiste pas non plus donc ca tu ne pourra pas y faire grand chose :)

    Enfin voila pour moi le meilleur moyen c'est l'AES et le Zlib pour compresser un peu... Maintenant, dans tous les cas tes 4.8mo seront chargé en mémoire, donc que tu fasse quelques opération de "décryptage" avant ne changera pas grand chose !

    Voila pour l'explication !

    @Ac_K>

    L'idée d'une compression + cryptage est pas mal mais alors quand tu dis "AES puis un coup de Zlib... Ou l'inverse..." c'est sans aucun doute l'inverse qu'il faut faire parce que la couche symétrique AES va faire péter l'entropie et la compression n'aura alors plus aucun intérêt autre qu'un éventuel archivage inutile dans le cas présent.

    @TomizFlash>

    Une solution aurait été de passer plutôt par du cryptage assymétrique + serveur, mais je ne vois pas à première vue comment l'appliquer à ton cas de figure. Et puis ça serait planter des carottes au tracto. :rolleyes:

    Après comme vous dites un coup de reverse et envolée la protection, surtout si justement tu n'y connais rien lorsque tu codes la dite protection. Et même si c'était le cas, tu aurais beau faire tous les efforts du monde, l'énergie déployée en face dépendra de l'intérêt de ce que tu caches. Sans connaissances préalables ça ne servirait qu'à décourager les badauds. Ce qui m'ammène à te dire qu'un simple cryptage de ta conception fera l'affaire ici.

    ++

    Dino

    Edit: Oups désolé, je m'aperçois que je réagis à un déterrage...

  5. Lu,

    @xam>

    en toute logique on peut penser que l'extraction (RDv2+8164b) a du se faire correctement

    J'ai pas été suffisamment explicite ; donc iso obtenue comme d'hab à l'aide du couple RawDump v2 + lg_8164b (un peu old school mais toujours efficace vu que j'suis pas pressé).

    ++

    Dino

  6. Lu,

    Essayé hier soir dans la foulée et ça ne fonctionne pas chez moi. :unsure:

    Une d2c-d1 en 3.2E, et une d2e-epoxy en 4.2E.

    Rien à faire, "Une erreur de lecture est survenue... Reboot obligatoire" avant même reconnaissance du backup dans la chaîne jeu. Même pas de proposition de maj sur la 3.2E.

    Le même dvd est reconnu sans soucis sur une dms 4.2E + wiikey-1 en 1.9g (par contre bug après quelques minutes, normal), et sur une d2b-pinless 4.2W + wiikey-1 en 1.9s (idem).

    La même iso fonctionne parfaitement une fois patchée sur 4.2W trucha actif, mais donne la même erreur de lecture lors de la phase de reconnaissance sur les deux consoles en wiikey-2 odyssey précédemment citées.

    Un scan d'erreur des disques indique qu'ils sont tous deux plus qu'honnêtes question qualité.

    Je comprends pas, malheureusement dans les deux cas j'ai fait d'emblée la maj odyssey après modif du coup je sais pas ce que ça aurait donné sans.

    Je vais regardé ça rapidement sur les prochaines (le avant/après).

    J'vais aussi refaire mon iso dans le doute (j'vois plus que ça) mais bon y'a pas de raison que ça ait merdé la première fois, surtout que comme indiqué en patché le jeu se fini sans l'ombre d'un bug donc en toute logique on peut penser que l'extraction (RDv2+8164b) a du se faire correctement (puis y'a jamais eu de soucis de ce côté là).

    J'ai essayé de jouer sur les paramètres region free et maj lock (desfois que, ça mange pas de pain), mais rien n'y a fait.

    Si quelqu'un a un indice je suis preneur.

    Et merci pour la news. :)

    ++

    Dino

  7. Lu,

    Donc si on se loupe, il suffit de re-ecrir avec la meme commande et la console redemarrera ? Si oui c'est vraiment cool. Car les dump de 10H...ca saoul un peu

    Oui, mais ne surtout pas oublier le "600" à la fin de la commande, sinon la console est foutue.

    Il reste quand même conseillé de dumper complètement la NAND

    Yep, y va y avoir des loupés... crying

    ++

    Dino

  8. Lu,

    Il faut donc refaire le dumps sans les modifier du tout (ce qui est devenu complètement inutile ... surtout que ta puce bloque très bien les mises à jour) pour qu'ils puissent fonctionner.

    C'était on ne peut plus vrai il y a quelques semaines encore, mais depuis l'arrivée de la nouvelle protection inaugurée par New Super Mario Bros Wii, la faille trucha s'impose, y compris pour une lecture via puce malheureusement.

    On peut penser que les prochains jeux vont rapidement l'embarquer. :(

    ++

    Dino

  9. Lu,

    Liteon 74 (et vraisemblablement pour liteon 93):

    0x1E138

    0x1EAEC

    0x1E742

    0x1E680

    0x1EECD

    0x1EB34

    0x1E83F

    0x1E725

    0x1E52A

    0x1E201

    0x1E9DF

    0x1E023

    0x1E4A0

    0x1E59A

    0x1E3FE

    0x1EF49

    Héhé, alors j'avais vu juste! -_-

    http://gueux-forum.net/index.php?s=&sh...t&p=1562952

    Est-ce que le dernier JF permet de spoofer en 83v2 ou en 93 (j'arrive aps à le lancer sur cette machine et l'autre est démontée pour le moment) ?

    Parce que sinon c'est vite fait de faire un soft qui extrait la clé en mode 74 (le plus probable selon la news) et 82 pour faire des tests.

    Après si ça fonctionne on pourrait sortir le reste histoire de flasher directement, mais l'article ne précise pas si c'est possible... ?

    ++

    Dino

  10. Lu,

    ca veut dire qu'ils entretiennent leur twitter, en gros ils postent pour rien dire lol, perso la seul chose qui m'intéresse c'est le firm en lui meme et je lirais le readme a ce moment la

    sinon mot a mot c'est ajout de code pour parait aux imprévues, testé avec succès... par contre quelles imprévues ?

    Libre à chacun de faire comme bon lui semble, mais la communication sur l'avancement de leur développement est très probablement la meilleure solution pour eux.

    Sans ça ils se prendraient encore des "Ils sont morts à ce qui se dit, les gars c'est la misère ! crying ", ou bien des "Apparemment les devs de l'équipe auraient tous était rachetés par micro$oft...", ou pire encore des "Salauds!, on a rien payé mais vous nous aviez dit que ça sortirait bientôt alors bougez vous l'cul !".

    Bref, ça fait parler les curieux et ça évite les bruits de couloir et les remarques déplaisantes d'ingrats qui veulent tout tout de suite. :rolleyes:

    Sinon y parait que "parait" s'écrit pas du tout comme ça dans ce cas là... sick

    ++

    Dino

  11. Lu,

    J'ai pas eu le temps de regarde mais si tu avais chercher un peu tu aurais vu :

    - Utiliser un usb loader qui patche la protection a la volée

    - Patcher l'iso du backup et :

    ...... - Lancer via un usb loader

    ...... - Lancer via chaine jeu avec puce mais par contre faille trucha obligatoire (donc utiliser dopios/truchabugrestorer ou autre firm alternatif si firm wii > 3.2)

    ++

    Dino

  12. Lu,

    Mario Paper quel région sur console quelle région/firmware ? Quels autres backups essayés qui ne fonctionnent pas ?

    La wiikey 2 quelle version ? Quell montage ? Avec des photos ça serait mieux ?

    Le disque de config de la Wiikey 2 passe quand à lui mais rien n'a l'air d'anormal dans les options. Par contre, le rescue ne fonctionne pas.

    Pas de rescue disc sur wiikey 2... :mellow:

    ++

    Dino

  13. Lu,

    WiiCrazy et I.R.on on envoyés ce programme sur TehSkeen, qui est en faites un décrypteur de mots et phrase secrète dans des textes ou autres support audio, vidéo et image que l'on appel la stéganographie.

    Cette méthode ancienne est utiliser sur la wii pour cacher les nouvelles protections a l'intérieur des io

    Heu j'ai un peu de mal à voir le réel intérêt de ce programme sur la scène Wii (ou alors j'ai pas compris) ?!

    C'est vrai que la Wii emploie de la stegano mais bon là c'est genre un tp qui à la limite avec la source aurait plus sa place sur un site de développement parmi les autres.

    Bref je crois que j'ai pas capté l'intérêt, ou sinon c'est pas avec ça qu'on saura quelle protection se trouve sur un iso/ios.

    Merci de m'éclairer. :)

    Et merci pour la news.

    ++

    Dino

  14. Lu,

    - le 1er tenait bizzarement sur un DVD simple couche alors qu'il doit apparemment tenir sur un double couche.

    - Quand au second il s'agissait effectivement d'une version US.

    [...]

    En fait tous mes anciens backups (5 en tout) n'étaient tout simplement plus compatibles, impossibles d'expliquer pourquoi

    Le premier est trucha signé donc incompatible avec firm officiel > 3.2.

    Le second est zoné donc incompatible avec firm officiel > 4.1.

    ++

    Dino

  15. Lu,

    Quelqu'un a t'il d'autres propositions sans devoir investir dans un 3è graveur?

    T'es pas obligé d'investir pour tester un autre graveur, la moitié des gens que tu connais doivent en avoir un chez eux.

    Par contre l'autre proposition consiste à essayer avec une autre wiikey 2, mais là pour la peine c'est le prix d'un graveur.

    Faut savoir ce que tu veux, on va pas aller te les faire les tests.

    Fais donc voir des photos de qualité de ton montage stp, qu'on puisse te dire s'il a l'air dans les normes de bon fonctionnement.

    ++

    Dino

  16. Lu,

    On voit que ça galère quand même...

    Si on prend la norme 802.11g du wifi (encore de loin la plus répandue dans les chaumières et la moins chère pour les constructeurs), on a un débit théorique maximum de 54Mbits/s, ce qui fait du 54/8 = 6,75Mo/s.

    Or un disque Wii standard est sensé tourner en 6X pour ne pas laguer, soit (150*9*6)/(2^10) = 7,91Mo/s.

    Donc même dans le meilleur des cas qui n'est concrètement jamais atteint (en raison des erreurs de transmission, interférences, distances, etc), sans tenir compte des temps de calcul, et surtout sans tenir compte de tous les pics de ping qui accompagne le wifi, on ne dépassera jamais les (54*(2^7))/(150*9) = 5,12X en lecture dvd simulée.

    Quelqu'un connaitrait'il la norme wifi max supportée par le récepteur ?

    EDIT: J'ai regardé de nouveau sur le site officiel et j'avais louché, c'est bien indiqué : il s'agit d'un récepteur 802.11g max.

    En tous cas merci pour la news. ;)

    ++

    Dino

  17. Lu,

    un oeil sur gueux annonces , ceci ne témoigne pas du sérieux des monsieurs , tout le monde peut s'inscrire et s'improviser poseur donc MEF

    ++

    Tout à fait d'accord ;)

    C'est pourquoi il faut ensuite chercher un peu sur le forum voir ce qu'ils racontent tous ces monteurs.

    Une autre question, je viens de télécharger le fichier wk2EurV1.2.tar sur le site officiel wiikey et il y a un truc que je ne m'explique pas.

    Le fichier fait 100ko, comment une fois extrait le fichier boot_eur.iso peut il faire 1.4 Go ???? , c'est d'ailleurs le cas, winrar a mis un certain temps mais

    il n'y a pas eu d'erreur.

    Si le fichier fait 1,4Go une fois décompressé c'est pour être au format standard d'un disque gamecube. On rempli l'espace manquant avec du vent (mais toujours le même, genre que des 0).

    Ensuite pour comprendre pourquoi ça se compresse si bien il faut chercher du côté du principe de la compression :

    En vulgarisant beaucoup, on pourrait simplifier ça par le fait que si un compresseur rencontre un fichier avec 1 milliards de 0 qui se suivent (donc 1Go), et bien il va jusque écrire dans le fichier compressé "ICI écrire 1 milliard de 0".

    Et voilà, on est loin en dessous du Ko et une fois décompressé le fichier comportera bien le milliard de 0 demandé.

    ++

    Dino