Peut-être L'indice Qui Nous Manquait Pour Le Hack

[fuktop13]

il n'y a pas besoin AES la parceque tu auras pas besoin de modifier executable mais seulement les fichier satellite quil y a autour . tu a juste besoin du md5 pour quil les acceptes .

504299[/snapback]

Quel moyen il y aurai pour faire ca a part de brute forcer ?

Ou justement tu ne connais pas de moyen rapide et cest ca le probleme ?

[slumb]

1/ Peux-tu expliquer en quelques mots ce que c'est ?

2/ As tu une idée où trouver ca, je pourrais essayer de la chercher et te la refiler après

1. La rainbow table est une table de mot de passe enfaite c'est une table a ce que j'ai compris qui est contient tousles pass possible de 1 a 8 caractère contenant tous,les caractères de la table ASCII

Pour la trouver on la trouve facilement sur internet mais elel se telecharge par bittorrent http://rainbowtables.shmoo.com/

xzibit0007 > Scuse j'ai pas tout compris

Pour la clef AES pas beosin de l'avoir je penses pour la clef md5 faut savoir ce qu'elle contient et a quoi elle correspond

@+

504301[/snapback]

Tu veux qu'on la télécharge a plusieurs et dès qu'on là on te la passe par FTP ?

[chriscc]

Corriger moi si je me trompe, mais la raindow table permet de cracker les mot passe encrypter en MD5, mais ce n'est pas ce que l'on cherche, car ici le md5 n'est pas utiliser pour crypter une cle, mais comme valeur de hachage.

Modifié 17 septembre 2005 par chriscc

[XKCorp]

il n'y a pas besoin AES la parceque tu auras pas besoin de modifier executable mais seulement les fichier satellite quil y a autour . tu a juste besoin du md5 pour quil les acceptes .

504299[/snapback]

Si j'ai bien compris : il faut prendre l'updater du 1.52, y placer l'update 1.50, refaire l'eboot, calculer son MD5 et le remplacer dans eboot? Je n'arrive pas à comprendre comment calculer avant le MD5, car quand on le met dans l'eboot ça va encore modifier le hashage?

La technique de la vérification du MD5 est comme le CRC, certaines modifications dans le fichier pourraient permettre de retrouver le même CRC sans avoir le même contenu mais la probabilité est très faible, seul un bon brute force pourrai le faire

[Neolink]

Slt a tous

Pour ce qui est du MD5 et du brute force, voici un lien qui pourrait, je l'espére, vous étre utile :

MDCrack

Bonne continuation...

Modifié 17 septembre 2005 par Neolink

[Ecco_]

Moi j'aimerais bien que Yoshi m'explique où il voit un hash MD5 dans le fichier eboot.pbp. Parce que sincèrement, c'est bien de dire "les 32 derniers HEXA c'est du MD5", mais ça ne forme en aucun cas une preuve... Puis je veux dire c'est même pas "probable" quoi, parce que je sais pas mais ils ne sont pas séparés genre par des 0 ou quoi...

Yoshi, si tu pouvais me convaincre j'en serais ravi :-)

[wikee]

Corriger moi si je me trompe, mais la raindow table permet de cracker les mot passe encrypter en MD5, mais ce n'est pas ce que l'on cherche, car ici le md5 n'est pas utiliser pour crypter une cle, mais comment valeur de hachage.

504319[/snapback]

Donc deja le md5 n'encrypt pas mais fait une empreinte du "mot" encrypté et ensuite par exemple dans le cas d'un mot de passe il va faire lempreinte du mdp que tu lui donne et comparée celle ci avec l'empreinte enregistrée.

Sinon dsl j'ai eu la flemme de lire tous les post mais j'ai les set de rainbow tables, je vais tester des ke je rentre chez moi cet aprem mais je doute que l'on puisse faire quelquechose avec celle ci, et de plus jespere ke ce n'est pas un md5 salt pour ceux qui connaissent....

je vais tester tout a lheure et je vous donnerais des nouvelles ^_^

[Yoshihiro]

J'ai deja expliquer ecco regarde ça .

Pour la methode 2 . c'est un MD5 qui ce trouve dans eboot.pbp de update ce qui fait que si vous modifiez n'importe quel byte de updater il seras lancé mais sous le PSP OS UPDATER vous allez avoir un jolie Message comme quoi votre update est corrompue et ne peut etre lancé ce MD5 est telement gros et voyant  que personne en parle . il ce trouve a la derniere ligne de Eboot en dessous du psar c'est grace a ça que updater verifie que Eboot n'a jamais etait modifier . ce md5 ne ce trouve pas dans les updater des jeux umd une petite colle ? . la reponse est parceque sony c'est trés bien que les umd's ne sont pas copiable donc il on pas ajouter de securiter pour verifier si le psar a etait modifié . je n'ai pas encore trouvé comment calculer ce md5 et trouvé a quoi il correspond . mais lui seul est la clée  . la derniere chose pour les Executable updater umd comme le 2.0 il son completement identique a celui lançable depuis la memory stick mais il son signée autrement avec un flag special UMD donc pour la psp c'est impossible de le lancé depuis la memorystick

et en anglais aussi :

it is a MD5 in eboot.pbp program of update, if you modify any byte of updater it will be launched but under

the PSP OS UPDATER you will have pretty a message that your update is corrupt and cannot be launched,

this MD5 is so large and visible that nobody speaks about it. It is placed at the last line of Eboot below

the psar it is thanks to that which Updater verifie that Eboot was never modified. This md5 is not

in the updater of UMD Game a small hard question? . the answer is because Sony knowledge very although

the umd' S are not thus copied they did not add a security for verifier if the psar were modified.

I did not find yet how to calculate this md5 and to find to what it corresponds.

But him only is clée. the last thing for Executable updater umd as the 2.0 they are completely identical

to that which functions since the memory stick but they are signed differently with a

special flag UMD thus for the psp that is impossible to launch it since the memorystick

Modifié 17 septembre 2005 par Yoshihiro

[Ecco_]

Merci Yoshihiro pour la réponse, mais pourrais-tu me dire maintenant :

-> Regarde ce dump hexa de la fin du fichier :

00D41970 93 39 9A EC CD 0F 7A 7C 55 B1 5D 02 74 E8 CA 06 .9....z|U.].t...

00D41980 15 59 9C B9 24 95 72 6F 20 0C 84 3C BE AA 42 56 .Y..$.ro ..<..BV

00D41990 88 4F B6 CF 90 D0 1A C3 B7 3D AE 5F 79 53 A4 5B .O.......=._yS.[

00D419A0 A6 00 15 40 80 18 50 13 6D 57 E6 CE 39 C4 35 CA ...@..P.mW..9.5.

00D419B0 C8 81 C8 EA 64 16 B2 3B 85 B7 A5 6B BF A9 32 35 ....d..;...k..25

00D419C0 58

Sincèrement, je ne sais pas ce que tu en pense, mais la fin n'a pas l'air _si_ différente que le début. Comment sais-tu que les 32 derniers caractères hexa sont bien un hash ?

-> Autre question : en admettant que ce soit un hash, comment sais-tu que l'algorithme utilisé est du MD5 ?

Si tu pouvais répondre à ces deux questions, et si tu m'affirmais que c'est la seule chose qui empêche le downgrader de fonctionner, je serais très chaud pour apporter ma contribution.

Merci par avance

[Yoshihiro]

Le md5 embarqué est : 81C8 EA64 16B2 3B85 B7A5 6BBF A932 3558

comment je c'est que c'ets 1 md5 sony utilise seulement le ADLER32 , SHA1 et MD5 le plus souvent et AES 128 que pour les Executables . voila !!!!!

[Ecco_]

Merci encore pour la rapide réponse,

Bon, soit pour le fait que si c'est un hash, ce soit du MD5. Moi aussi je trouve ca probable, de tte façon le MD5 c'est ce qui est le plus utilisé pour faire des checksum de téléchargements.

Mais tu ne m'as toujours pas dit comment tu savais que c'était un hash ? Parce que a priori rien ne différencie ce que tu dis être le hash "81C8 machin là" de ce qu'il y a avant...

[chriscc]

Tu peux egalement comparer les deux eboot.

Un provenant d'un dump d'UMD qui n'a pas de checksum et celui d'un eboot telecharger contenant le checksum.

La partie manquante est le checksum

[XKCorp]

Le md5 embarqué est  : 81C8 EA64 16B2 3B85 B7A5 6BBF A932 3558

comment je c'est que c'ets 1 md5 sony utilise seulement le ADLER32 , SHA1 et MD5 le plus souvent et AES 128 que pour les Executables . voila !!!!!

504361[/snapback]

j'ai calculé le MD5 de l'eboot avec MD5SUM, ce n'est pas le même que celui à la fin du fichier... alors sur quoi calculer le MD5? That's the question...

[fuktop13]

oki , on va prendre pour argent content ce que dis yoshi .

Maintenant que faut t il faire eXactement :

-rajouter des craracteres pour obtenir le meme cheksum = quasi impossible

-decrypter le cheksum ?

eXpliquer les demarches et les diverses possiblités envisageable s'il vous plait !

Et yoshi tu as bossé dessus donc di nous tes avancées qu'on est pas a refaire ce que tu as deja fait , ou donne nous des directions deja !!

@XKCorp : on m'a parlé de MD5 dérive peut etre mais je ne sais pas a quoi sa correspond :s

Modifié 17 septembre 2005 par fuktop13

[joeldc13]

oki , on va prendre pour argent content ce que dis yoshi .

Maintenant que faut t il faire eXactement :

-rajouter des craracteres pour obtenir le meme cheksum = quasi impossible

-decrypter le cheksum ?

eXpliquer les demarches et les diverses possiblités envisageable s'il vous plait !

Et yoshi tu as bossé dessus donc di nous tes avancées qu'on est pas a refaire ce que tu as deja fait , ou donne nous des directions deja !!

@XKCorp : on m'a parlé de MD5 dérive peut etre mais je ne sais pas a quoi sa correspond :s

504385[/snapback]

Bonjour,

Je ne suis pas tout a fait sur que ce soit cela qu'il faille faire.

Pour moi je verrai plus :

1 ) Trouver a partir de quels morceaux du fichier le md5 est calculé. Pour cela prendre le fichier original pour lequel on connait le md5 (celui donné par Yoshi) et essayer de le retrouver a partir de différents morceaux du fichier, oui c'est de la brute force, j'ai pas essayé de calculer combien de temps cela va prendre....

2) Une fois que l'on sait ou est calculé ce md5, on peut modifier le fichier eboot puis recalculer le md5 sur le fichier modifié et l'inscrire a la fin du fichier au lieu de l'ancien.

Moi c'est plus comme ça que je le vois...

Maintenant je me trompe peut etre.

A+

[Barty]

Donc si j'ai bien compris, la derniere ligne en md5 correspond a la signature dune partie du eboot et cette signature est comparée a cette partie du eboot pour voir si rien na ete modifié? si ca ete modifié, ca marche po...

Donc le plus dur, en admettant que ca soit du md5, est de retrouvé cette partie qui correspond a cette signature?

Apres cest un jeu denfant? lol car faudra juste modifier cette partie pour faire fonctionner le DG et ensuite modifier la derniere ligne en md5 pour quelle corresponde a la signature de la partie modif?

Lol dsl mais jy connais po grd chose mais ca minterresse pas mal cette histoire, et jveux voir si j'ai bien compris, et faire un chtit résumé pour ceux qui arrivent lol.

EDIT : lol joeldc13 a mieux résumé que moi, apparement javais bien compris

Modifié 17 septembre 2005 par Barty

[damngod]

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.

Modifié 17 septembre 2005 par damngod

[joeldc13]

Donc si j'ai bien compris, la derniere ligne en md5 correspond a la signature dune partie du eboot et cette signature est comparée a cette partie du eboot pour voir si rien na ete modifié? si ca ete modifié, ca marche po...

Donc le plus dur, en admettant que ca soit du md5, est de retrouvé cette partie qui correspond a cette signature?

Apres cest un jeu denfant? lol car faudra juste modifier cette partie pour faire fonctionner le DG et ensuite modifier la derniere ligne en md5 pour quelle corresponde a la signature de la partie modif?

Lol dsl mais jy connais po grd chose mais ca minterresse pas mal cette histoire, et jveux voir si j'ai bien compris, et faire un chtit résumé pour ceux qui arrivent lol.

EDIT : lol joeldc13 a mieux résumé que moi, apparement javais bien compris

504394[/snapback]

Ce qui n'est pas un jeu d'enfant c'est de savoir sur quelle partie du fichier le md5 est calculé, car il me semble (je parle au conditionnel j'mi connais pas trop en checksum) que l'on peu faire un md5 sur n'importe quelle taille de fichier. Et pour peu que Sony ai fait le md5 sur des parties non connexes (genre un bout la, un bout 3 octets plus loin etc....) Cela fait énormément de combinaisons possibles sur un fichier de 13 Mo.....

Et là ca risque d'être super long....

[XKCorp]

je viens de faire un test. j'ai pris le firmware original 2.00 US, je l'ai extrais avec PBP Unpacker, puis avec les fichiers extraits j'ai refais un nouveau eboot.

donc au final j'ai eu 2 eboots : l'original, le repacké ainsi que les fichiers extraits.

il se trouve qu'en regardant à l'éditeur HEX la fin du eboot original est la même que celle de l'eboot repacké et que celle du fichier DATA.PSAR... donc dans le fichier eboot, après le fichier PSAR il n'y aurait rien? pas de MD5? on m'aurait menti?

[Necroalbert]

Moi je suis comme plusieurs ici je ne penses pas que la clef de la fin soit une chaine de caractère crypté mais en meme temps j'ai utiliser md5.exe pour recupérer le hash de chaques fichiers du eboot mais aucun ne correspond :s

Sinon qqn a essayer de prendre le fichier eboot.pbp du firm 1.50 de prendre la chaine md5 a la fin du firm 1.52 et de le lancer sur une 1.51 ?

[corsu]

y a un truc que je pige pas, le eboot de la memory stick 2 étant un original non modifié, le md5 est correct non ?

Donc pourquoi ca ne passe pas ? :fouf:

[Yoshihiro]

y a un truc que je pige pas, le eboot de la memory stick 2 étant un original non modifié, le md5 est correct non ?

Donc pourquoi ca ne passe pas ?  :fouf:

504429[/snapback]

bas la c'est parcequil reverifie la version du SFO . et la il tombe sur un ic parceque dans le param.sfo il y a toujours marquer 1.50

[damngod]

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.

[corsu]

Merci pour la precision

[KaMbiOkIkA]

Salut,

Bon j'ai pas lu tous les posts, mais la plupart ne m'ont pas l'air très clair.

Le MD5 est un algorythme de cryptage de données, utilisé principalement pour la reconnaissance de fichier.

Le calcul du MD5 est connu depuis bien longtemps, et il est très facile d'en trouver les sources (légales en plus).

Le seul problème, c'est de savoir si ce dont Yoshihiro parle est bien du MD5... et de deux, a quel(s) fichier(s) ou donnée(s) correspond ce MD5.

++