dinozore

Membres
  • Compteur de contenus

    1 774
  • Inscription

  • Dernière visite

Tout ce qui a été posté par dinozore

  1. Lu, Juste une précision : sauf si firm waninkoko 4.0 ou 4.1 installé. Mais bon vous êtes au courant si c'est le cas. ++ Dino
  2. dinozore

    D3-2 : un nouveau lecteur Wii

    Lu, Y ont peut-être fait d'une pierre deux coups. Ca a peut-être un lien avec la news de la team wiikey 2... ++ Dino
  3. Lu, C'est l'ouverture du champ des possible, c'que c'est euphorisant... C'est d'ailleurs pour ça que j'continue à jouer au loto de temps en temps. ++ Dino
  4. Lu, , c'est de la super news ça ! Vivement qu'on nous en dise un peu plus. J'espère que ça va donner du bon. ++ Dino
  5. dinozore

    Drole De Mails De Paypal

    Lu, Des phrases bizarrement tournées, des fautes d'orthographe... On peut pas dire que ça inspire confiance. Comme déjà dit, pour tout ce qui est sensible il faut toujours passer par le site principal et ne surtout pas passer par des liens foireux reçus par mail. ++ Dino
  6. dinozore

    Probleme Wiikey

    Lu, C'est même plus que très probablement un hasard selon moi. Ca donne toujours cette impression paranoïaque pendant une petite période qui suit une release de maj console. ++ Dino
  7. Lu, @Shakin> Tu es sûr que bootmii d'installé suffit en cas de low level brick ? Ca ne serait pas plutôt bootmii (où j'ai zappé une étape) ? ++ Dino
  8. Lu, @Shakin> Cool, j'avais zappé. Merci. ++ Dino
  9. dinozore

    Probleme Wiikey

    Lu, Pour moi c'est un soucis de bloc lentille à changer. Bannerbomb + Usb loader feraient effectivement l'affaire. Par contre ça implique de tout transférer sur un disque dur compatible. Pour un loader dvd, si c'est bien le bloc alors le résultat sera le même. ++ Dino
  10. Lu, Super! En revanche il faudrait un moyen de déterminer facilement les versions du boot1 et du boot2. Pour le boot1 on peut comparer, et pour le boot2 on pourrait le faire aussi mais il faudrait avoir un référent pour savoir si la version est supérieure ou non. Peut-être déjà une correspondance approximative en fonction du numéro de série ? Sinon un équivalent pour un dump infectus serait génial, ou tout simplement rendre publique la méthode de conversion d'un dump bootmii vers un dump infectus... Merci pour la news. ++ Dino
  11. Lu, T'inquiète que si la plupart des points sont sur le d1a ils sont bien capables chez wiiclip d'en sortir un spécial dans la foulée. PS: Ca m'empêche pas de penser que bitonio n'a pas compris ce qu'était un D3 (déjà que lui et la résine...). ++ Dino
  12. Lu, A mon avis c'est plutôt une nouvelle puce sinon pourquoi faire attendre si longtemps (même si un plan de câblage filaire pour la wiikey 2 serait cool). ++ Dino
  13. Lu, Je crois pas en avoir vu passer et je me souviens plus de leur valeur... Mais de toutes façons c'est rare d'en avoir besoin et dans ce cas tu le pontes. ++ Dino
  14. dinozore

    Puce Wii

    Lu, C'est justement tout le problème. Si tu nous trouvais des points alternatifs tu serais le bienvenu. ++ Dino
  15. dinozore

    Puce Wii

    Lu, Tiens, elles étaient sur mon bureau. Cherche + d'infos avec d2 nothing ou d3, c'est la même chose. Il est pas tant nouveau que ça mais on est même pas vraiment certain qu'il y en ait déjà en France. Si je me souviens bien, le membre en question ne connaissait pas la provenance de sa Wii. En tout cas ça reste rare pour l'instant. ++ Dino
  16. Lu, @Kouba> T'as vu le lien que legueux file juste au dessus pour une news ? Te prends plus la tête le mystère est percé. ++ Dino
  17. dinozore

    LiteOn Openkey 0.1

    Lu, Merci legueux pour la news. Ca va être facile d'automatiser toute la tâche maintenant. Donc pour info : @00h ou 10h ou 20h ou 30h => Clé de decryptage (adresse obtenue à partir de modulo(((valeur de l'octet en @A9h) divisée par 2), 5) multiplié par 16) @50h => Ivec (Vecteur aléatoire d'initialisation de l'algo de cryptage en gros) @60h => Clé dvd cryptée (-Zou- tu avais raison ) Ensuite AES-128 avec ça. Et pour finir un Xor octet par octet du résultat avec l'Ivec. Edit: La v0.2 est sortie. Le code a été explicité et confirme ce que j'ai écrit au dessus. L'octet en @DFh (qui n'est pas utilisé par FreeKey) est simplement une confirmation de celui en @A9h. [HS pour ceux qui s'intéressaient au problème] Pour ma part j'avais hier soir isolé précisément ces composantes (c'était les seules qui influaient sur le résultat). J'avais vu qu'en fonction de l'octet en @A9h on obtenait 5 clés différentes (ce qui implique forcément un modulo 5) mais je n'avais pas eu le temps de trouver en quoi il influençait le décodage. Et bien il sert à déterminer la position de la clé dvd de decryptage justement (comme indiqué au dessus elle peut avoir 4 adresses différentes). D'ailleurs le calcul fait très n'importe quoi soit dit au passage. Je pensais que la clé dvd cryptée se trouvait en @50h dans le fichier d'exemple à cause du fait que la clé dvd décryptée était obtenue à partir d'un simple ou exclusif octet par octet sur celle-ci avec la clé en @50h mais en fait c'est juste une petite touche finale ajoutée dans l'algo après le Rijndael. Jusque là c'est du bidon mais là ou ça se compliquait c'était qu'un bit changé dans cette clé en @50h modifiait complètement la clé dvd décryptée, ce qui impliquait qu'elle avait une plus grande fonction que le xoring de fin. Idem avec celle en @00h. C'est là que je voulais faire un peu de reverse engineering ce weekend. Dommage j'ai été trop curieux et en regardant l'algo j'ai manqué une occasion de m'amuser. Maintenant le challenge (et surtout la perte de temps qu'il implique) a beaucoup moins d'intérêt vu que ça ne servirait plus la communauté. [/HS pour ceux qui s'intéressaient au problème] Par contre si Seacrest a pu le faire grâce à un debugage, il m'est très difficile de croire que Geremia et Maximus ont trouvé ça aussi rapidement avec un ou deux fichiers reçus de foudmy comme il le prétendraient (au conditionnel parce que perso je suis pas allé chercher leur propos donc j'ai pas vu de mes yeux). Ca m'a l'air plus qu'orchestré tout ça comme il en était question. Reste plus qu'à savoir s'il est possible également de dumper directement la clé sur les 74850 et si non pourquoi ? ++ Dino
  18. Lu, On est d'accord, seulement dans un des tes posts précédent tu dis : "On remarque que la clé DVD normalement présent à l'adresse 0000000060 n'est pas présent dans un dump d'un 74850." Alors que de ce que j'en ai regardé hier soir c'est presque évident qu'elle se trouve en @50h dans le dump d'un 83850. Donc pour être clair dans le fichier d'exemple la clé cryptée serait "GERE LOVES MAXIM". C'est pour ça que je demandais, et que je demande toujours, si c'est une information confirmée ?! ++ Dino
  19. Lu, @Kouba> On a du mal à se comprendre... Tu fais pas mal de confusions (par exemple "en hexa une adresse commence par 0x" => Faux, c'est simplement la notation d'une valeur hexadecimale instaurée par le C et utilisée depuis par d'autres langages qui en découle). Bref -Zou- m'a mieux compris. Sinon je me demande d'où vous tenez l'info comme quoi la clé se trouverait en @60h sur 16 octets ? C'est de l'info confirmée ? Parce que pour avoir regardé quelques minutes je dirais qu'elle se trouve plutôt en @50h toujours sur 16 octets. Je regarderai ça de plus près ce wekend, là je suis crevé. ++ Dino
  20. Lu, @Kouba> Et dans un ancien firm en @1C138 tu trouves 00 ? Je n'ai pas de firm sur ma machine de travail mais je parierais que non. Idem pour les autres adresses. De + il s'agit des adresses dans le firm iX, mais rien ne nous dit qu'il s'agisse des même dans le firm original. Donc rien n'est prouvé : ça peut-être le programme qui bloque la lecture, ou bien également une protection sauté du 74 au 83, tout comme ça peut être les adresses du 83 qui pointeraient désormais volontairement vers des octets à 00 dans le 74 histoire de compliquer un peu la donne. ++ Dino
  21. Lu, Je pense pas que ça soit le programme qui bloque volontairement l'extraction de la clé des 74850. En fait je vois pas trop l'intérêt qu'aurait eu foundmy à faire ça. Au contraire, ça leur aurait fait une énorme pub et donc plus de clients pour les 83850. D'un autre côté je vois pas non plus l'intérêt qu'aurait eu kro$oft à enlever une protection déjà en place. Peut-être la clé n'est-elle tout simplement pas à la même place (mais bon, que des 0 à cette adresse sur un 74850, possible mais bizarre) et un extracteur 74850 identique verra bientôt le jour. Si je suis pas trop fatigué je jèterai un oeil dès que j'ai fini le boulot. Avec un moyen de calculer le résultat c'est encore plus intéressant. ++ Dino
  22. Lu, Merci pour la news. Donc ou c'était très simple, ou il s'agit bien d'un délit d'initié. ++ Dino
  23. Re, Je précise que je spécule parce que je n'ai pas encore vu de modèle de ce liteon, et que je n'ai pas vu non plus ces fameux fichiers. Ca on s'en fout le nouveau JF le fait. En plus il y énormément de chance pour qu'il s'agisse des mêmes positions que les premiers liteon, tout simplement parce qu'aucun firmware spécifique n'a vu le jour et que donc à moins d'un fonctionnement dynamique les positions se doivent d'être celles prévues. Pour que ça soit le cas (le fonctionnement dynamique) il faudrait soit que les positions découlent des valeurs de la clés, soit qu'il s'agisse d'une possibilité présente dans le firmware original (une table d'adressage par exemple) qui aurait été reproduite par zèle alors que pour les premiers liteon elles restaient constantes. De toutes façons ça sera fait en quelques minutes et je pense que ça ne nous avancera à rien. En l'absence de connaissance de l'algo et sans le fichier de départ ça ne s'appelle plus du décryptage mais de la magie (ou bien du délit d'initié...). ++ Dino
  24. Lu, Comme déjà dit dans la news, je serais également intéressé mais par un (ou mieux plusieurs) couple fichiers envoyés/reçus. L'un sans l'autre qui va avec ne servirait à rien. ++ Dino