damngod

Membres
  • Compteur de contenus

    10
  • Inscription

  • Dernière visite

damngod's Achievements

Débutant

Débutant (1/7)

0

Réputation sur la communauté

  1. damngod

    Le Lt+ En Phase De Test

    En gros, concernant les Slim, c'est pas pour tout de suite. Je vais donc vendre la mienne et garder ma Arcade 1.5.
  2. Hello, Voilà j'ai acheté une Slim quelques jours après son lancement afin de jouer a SSF4 en ligne, ma console Arcade ayant été bannie il y a un an. J'ai décidé de lâcher SSF4 il y a quelque temps, et le jeu en ligne en général, que je trouve frustrant. Je me retrouve donc avec une Slim quasi neuve. Ma question est de savoir quelle console je devrais garder dans l'optique de jouer offline avec mes backups. Avec les nouvelles protections qui sont arrivées, et le LT+ en approche, je suis un peu perdu et je n'arrive pas à me décider. Est-il plus sage de conserver un vieux modèle, qui aura peut-être par la suite une plus grande compatibilité avec mes futurs jeux ? J'ai peur que la Slim, du fait des mises à niveau hardware, soit plus difficilement contournable et me pose régulièrement souçis. Bien entendu, ma question se pose dans l'optique d'un futur flash de ma Slim en LT+. Alors, Arcade en 1.5 (et futur flash si nécessaire) ou Slim en LT+ ? Qu'en pensez-vous ? Merci d'avance à tous.
  3. Salut ! J'avais lu que pour le LT, certains (TeamJungle peut-être bien) avaient mis en ligne plusieurs 360 dans diverse configurations (LT + original, LT + backup, etc.). On aura évidemment pas les retours de cette expérience avant la prochaine vague de ban mais je me demandais si ça avait déjà été fait auparavant avec d'autre firmware ? Je me demandais également s'il existe une base de donnée permettant de recenser son ban (date, firmware, jeu avant retail date, etc.) ? Car a l'heure actuelle, on ne sait toujours pas si c'est le firmware, les backups ou les deux qui sont responsables du ban. EDIT : Au passage, j'en suis à ma 2ème 360. La première m'a fait un RROD mais a tenu 1 ans sans ban. La deuxième s'est fait ban lors de la dernière vague.
  4. Oui c'est ca. Cracker le MD5, s'il s'agit bien de ca, n'est pas possible dans ce cas la. http://fr.wikipedia.org/wiki/MD5 Plus d'infos ici.
  5. Yosh, quand est il vraiment du MD5 ? Il existe des algo de hashage beaucoup plus performant que le MD5 aujourd'hui (SHA-1 par exemple), comment peut-on etre sur de ne pas se planter de hashage ?
  6. Non. Tu lances le EBOOT de la 2.0 puis tu swap la 1.5 apres avoir passer certains verrous. Ensuite, l'update verifie le MD5 d'une partie de l'EBOOT (meme pas sur a 0.01%) qui est maintenant celui du 1.5. Donc ca ne peut que foirer.
  7. Je balance une idee comme ca : Oublions une modification sur le MD5. L'update veut verifier une certaine valeure, faisons lui verifier le veritable EBOOT auquel il s'attend. Une fois la verification du EBOOT officiel termine, le flash est confirme et il faudrait ensuite a nouveau swapper de MS pour lui faire flasher le 1.5 au lieu du 2.0. Evidemment, je postule qu'on peut arreter le temps, swapper tranquillement de ms juste apres la verification du MD5 et je postule egalement qu'aucune autre verification "de derniere minute" n'est faite.
  8. Je ne crois pas que le MD5 soit un algorythme de cryptage. C'est simplement un algorythme qui permet de donner une identite propre a chaque fichier. On pourrait eventuellement tirer des informations de ce pretendu MD5 connu (puisque rien n'est secret dans le MD5), cela pourrait permettre d'orienter les recherches. EDIT : Il semblerait que le MD5 utilise un cryptage 128bits, il est certes moins sur que l'AES, mais il reste je crois a l'abri face a des tentatives a notre echelle (meilleurs hackers compris). Ca reste un travail de professionnel. Le MD5 n'est plus juge comme sur car il y a une probabilite que deux fichiers differents possedent le meme MD5 mais elle reste faible. Ca nous laisse la possibilite de modifier la valeur du MD5 que le processus d'update va verifier avec celle de notre nouveau fichier modifie.
  9. Voila mon avis concernant ce fameux MD5. Si je ne me trompe pas, chaque fichier possede son propre MD5. Si deux fichiers ont des MD5 differents, les fichiers sont differents; si les MD5 sont les memes, les fichiers ne peuvent etre que strictement identique. A ce que je comprends, le processus d'update verifie le MD5 d'un fichier (ou d'une partie d'un fichier). Si le MD5 ne correspond pas a la valeur attendue, c'est que le fichier qu'il verifie ne correspond pas au fichier attendu et la mise a jour se fige. Imaginons qu'on soit capable de trouver a quoi correspond ce MD5, il faut encore etre capable de passer outre cette verification. Comme l'a dit Yoshi, il suffit de modifier un byte pour que le MD5 soit change. Il faudrait donc etre capable de renvoyer le MD5 attendu meme si le MD5 du fichier en question n'est pas le meme. Ou eventuellement, modifier la valeur attendue (la modifier afin qu'elle corresponde a la valeur de notre fichier modifie) directement dans le processus d'update. EDIT : le thread evolue tellement vite que ma reponse est deja depassee au moment du post.
  10. damngod

    Console Qui Galére...

    J'ai effectivemment remarque ce probleme de chargement sur Virtua Tennis. La ou c'est le plus genant, c'est dans le mode World Tour.