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

[Necroalbert]

XK a raison les différences entre la version UMD et PBP de l'upgrade 1.5 est minime :

[corsu]

sachant que l'update sur l'umd n'a pas de checksum

en partant de la la méthode de yoshihiro, n'est t'il pas possible de lancer l'eboot de la memory stick1, de mettre en veille, puis au lieu de remplacer la memory stick, feinter la psp pour qu'elle pointe sur le repertoire update d'un umd qui possede l'udate 1.5 ? metal gear solid acid EU par exemple ?

ou faire pareil que la methode des 2 ms mais en switchant 2 UMD, l'un avec la 2.0 et l'autre avec la 1.5 ??

c'est beau les rêves hein ?

Modifié 17 septembre 2005 par corsu

[aracnide]

Ou pitetre que le MD5 de la fin est le MD5 du ficher moins le MD5

C'est pitetre dur ce que je dis, mais le MD5 est calculé pour tout ce qui est avant ce fameux MD5, non ?

[Necroalbert]

corsu > faudrait demander a yoshihiro de faire comme tu as dit mais avec l'update de l'umd

Aracnide > non j'ai deja essayer

[xzibit0007]

Barty il serai faile pour un programmeur de faire un programme qui analyse toute les lignes et de calculer a chaque fois toutes les possibilité pour voir celle qui correspond mais se serai je penses asser long car les firmware font quand meme 15 mo

504507[/snapback]

Dit moi exactement ce que le programme doit faire et j'essayerais de le pondre.

Mais si c'est un genre de "bruteforce" il faudra certe du temps...

[XKCorp]

Necroalbert > d'après tes MD5 les SFO du 1.51 et 2.00 sont identiques, étrange!

Un truc qui me chiffonne : quand on modifie les fichiers SFO lors de la MAJ il dit après avoir redémarré que les données sont corrompues, donc il vérifie aussi l'intégrité du SFO. Il faudrait essayer de mettre un SFO de 2.00 dans une update de 1.51 pour voir si ça passe comme ils ont le même MD5...

Dans les fichiers PSP et PSAR il doit aussi y avoir le numéro de version, mais comme ils sont cryptés on ne peut pas y toucher

[Necroalbert]

Je penses que Barty veux faire un programme qui prend une lignes qui calcul le md5 si c pas bon ca passe a la ligne suivante et ca recalcul le md5 etc ... si c pas du tout ca ben j'ai rien compris

[Barty]

heu xzibit0007, si tes assez calé, faudrait plutot chercher les lignes de prog dans le systeme d'upgrade de la psp qui permet la vérification entre la signature md5 et les lignes du firmaware correspondantes... lol enfin necroalbert ma dit que ca pouvait se trouver mais que par qqun de vraiment calé, alors bon, faudrai voir.

Voili, si qqun dautre pouvait qd meme me dire si cette idée cest de la m*** ou si cest envisageable...

EDIT : looool NecroAlbert, cest po ca, jabandonne

Modifié 17 septembre 2005 par Barty

[Necroalbert]

Je viens de comparer eboot.bin et data.psp ui font exactement la meme taille et regarde ca :

[rem02]

heuuu barty,

comment veu tu chercher dans les lignes de prog du systeme d'upgrade de la psp. kelk1 a les sources ou vous vous amusez à analyser le code hexa ?

[Barty]

lol je sais po, cetait quune supposition, personne na analysé le système de la psp?

EDIT :

Pour ceux qui ont compris ce dont je parlais, si cest trop compliqué, faut pas s'embeter, cetait quune idée comme ça : certains disent quil fau partir de la signature pour arriver à des lignes de prog du firmware, dautres qui fallait partir des ligne de code du firmware pour arriver à la signature md5: en gros

analyser signature md5 ------> lignes de l'upgrade

analyser lignes de l'upgrade------> signature md5

et ainsi retrouver les lignes qui correspondent à la signature.

Moi j'ai pensé au tiers programme qui lui met en corrélation les deux pour faire le check, la ligne de prog ou le prog contenu peut dans le systeme meme de la psp qui "dit" à l'upgrade quel ligne de code de l'upgrade il doit vérifier avec cette signature md5.

Voila si cest po clair, dsl je vois po comment mexprimer mieux.

Modifié 17 septembre 2005 par Barty

[Necroalbert]

Grace a tous ce qu'il y a depuis le debut on pourrait tester comme mix les fichiers :

DATA.PSAR extrait de l'umd

DATA.PSP de la version 1.5

ICON0.PNG n'importe c'est tous les meme

PARAM.SFO n'importe lequel de la 1.5 ou de l'umd de toute facon ils sont pareil

Théoriquement si il y a un check comme sur les jeux pour la version ca ne devrait pas marcher.

Mais en modifiant la version dans les fichiers peut etre que sa pourrais marcher ca ril n'y aurait peut etre plus de probleme de md5 donc plus de fichier corompue

[fuktop13]

Grace a tous ce qu'il y a depuis le debut on pourrait tester comme mix les fichiers :

DATA.PSAR extrait de l'umd

DATA.PSP de la version 1.5

ICON0.PNG n'importe c'est tous les meme

PARAM.SFO n'importe lequel de la 1.5 ou de l'umd de toute facon ils sont pareil

Théoriquement si il y a un check comme sur les jeux pour la version ca ne devrait pas marcher.

Mais en modifiant la version dans les fichiers peut etre que sa pourrais marcher ca ril n'y aurait peut etre plus de probleme de md5 donc plus de fichier corompue

504576[/snapback]

Mais yoshi a dit qu il y avai un flag sur le version les UMD donc sa ne marhcera pas car on sai pa ou est le flag et si on le changer il faudrai le checksum non?

[XKCorp]

Le fichier EBOOT.BIN est le même qye DATA.PSP mais il ne fait pas la vérification du MD5, on peut le supposer car le MD5 n'est pas à la fin du fichier DATA.BIN.

D'après Yosh il n'est pas crypté de la même façon car il est destiné à être lu seulement sur l'UMD. Il est donc impossible de lancer EBOOT.BIN depuis le MS et donc de passer la vérif du CRC par cette façon

[rem02]

sa va n'a rien n'avoir avc le md5 et sa va paraitre ridicule comme question mais jme lance.

pour une psp avc firmware 2.0 on peut lancé du code php et java. dc ma question et là je pense que seul un expert peu y répondre, peut programmer un updater ki forcerai l'update sans vérification du checksum et autre ou ki remplacerai celui de la psp ?

(jpense ke les team y ont pensé avant moi mais bon sa ma traversé l'esprit en essayant pspos)

[Barty]

eh si on supprimait la dernière ligne de code? celle avec la signature?

lol jcontinu dans mes idées stupides

[rem02]

tinkiete y a pas que toi barty... et pui tte les idée mm les plus stupide m'érite d'etre dit.

Modifié 17 septembre 2005 par rem02

[magikpsg]

et cette idée on cotise tous et on achéte un cray x1 :fouf: bon ok sa c'est idiot mais bon se qu'on fait c'est comme si on essayai de trouver le nombre pi , bon j'exagere mais la je deprime. lol

[Necroalbert]

Fuktop regarde sur les images que j'ia mise avant la seul différence entre la version umd et 1.50 c le md5 a la fin et le eboot.bin et data.psp

[fuktop13]

Fuktop regarde sur les images que j'ia mise avant la seul différence entre la version umd et 1.50 c le md5 a la fin et le eboot.bin et data.psp

504633[/snapback]

Mais donc si la seule difference c est cette ligne sa doit vouloir dire qu'a un moment donné si il n'y a pas la derniere ligne alors c est l'umd et il doit pouvoir detecter si il li de l umd ou de la memory stick ?

je te dis ca sans vraiment savoir non plus , mais ca m'a lair trop facile pour ne pa avoir eté tester .

[Necroalbert]

Je cherche l'update de la version 1.5x a la version 2.00 celui de l'umd de demo m'irait bien uploader le svp

[Overkill]

Tout d'abord bjr, je suis l'actualité tout comme vous mais... y'a qq choses d'etranges dans votre histoire de md5.

Je m'explique : Si le md5 est rajouté par sony, lors d'un repack de fichier par PBP Unpacker, la derniere ligne commençant par 81 ne devrait pas y etre.

Pourtant en unpackant les fichiers et puis repack, j'obtiens le md5. Tres etrange quand meme...

Et pire encore, en suivant la logique, je modifie PARAM.SFO et je repack le tout. Oh encore le meme md5. Pourtant c'est impossible car j'ai modifié le fichier.

Juste en derniere preuve, changez l'image icone0 par une autre, repack le tout.

Votre resultat EBOOT.PBP n'aura pas la meme taille mais tjrs la meme fin commençant par 81 ..

Alors est-ce vraiment le md5 ? y'a pas de chance ...

[xzibit0007]

g le disque de demo.

Je sais l'extraire avec ma V2 ?

[blade98000]

ben y a qu a demander si vous voulez l update 2.0

voila le lien:

ICI RAPIDSHARE

c la version 2.0 que j ai pris sur le net grace a ma connexion wifi

j espere que ca pourra vous aider en tt cas

[fuktop13]

Tout d'abord bjr, je suis l'actualité tout comme vous mais... y'a qq choses d'etranges dans votre histoire de md5.

Je m'explique : Si le md5 est rajouté par sony, lors d'un repack de fichier par PBP Unpacker, la derniere ligne commençant par 81 ne devrait pas y etre.

Pourtant en unpackant les fichiers et puis repack, j'obtiens le md5. Tres etrange quand meme...

Et pire encore, en suivant la logique, je modifie PARAM.SFO et je repack le tout. Oh encore le meme md5. Pourtant c'est impossible car j'ai modifié le fichier.

Juste en derniere preuve, changez l'image icone0 par une autre, repack le tout.

Votre resultat EBOOT.PBP n'aura pas la meme taille mais tjrs la meme fin commençant par 81 ..

Alors est-ce vraiment le md5 ? y'a pas de chance ...

504678[/snapback]

bien sur que c'est normal lol

Le cheksum c est une valeur fiXe pour verifié qu'on a rien changé , on compare donc une valeur ( ce qu'on cherche) au cheksum et si valeur = cheksum alors c 'est ok !