Recherche Sur Downgrader

[mph]

Recherche sur les updates au format EBOOT.PBP :

-----------------------------------------------

3 facons possibles pour updater :

- Par la memory stick ( PSP/GAME/UPDATE/EBOOT.PBP )

- Par un UMD ( SYSDIR/UPDATE/PARAM.SFO, EBOOT.BIN et DATA.BIN )

- Par connexion internet ( recherche du dernier EBOOT.PBP sur un site )

Comment trouver le MD5 du EBOOT.PBP :

Un EBOOT.PBP d'update de la memory stick contient :

- un PARAM.SFO (informations pour le vshell, notamment la version du firmware)

- un ICON0.PNG (un icone affiché par le vshell)

- un DATA.PSP (le programme d'update, signé)

- un DATA.PSAR (les données de l'update)

Le dossier SYSDIR/UPDATE de l'umd contient :

- PARAM.SFO (Pareil que le PARAM.SFO de l'EBOOT.PBP de la memory stick)

- EBOOT.BIN (Pareil que le DATA.PSP de l'EBOOT.PBP de la memory stick)

- DATA.BIN (Pareil que le DATA.PSAR de l'EBOOT.PBP de la memory stick)

Si on compare les fichiers entre eux :

- PARAM.SFO de l'EBOOT.PBP est identique a PARAM.SFO de SYSDIR/UPDATE

- DATA.PSP de l'EBOOT.PBP est identique a EBOOT.BIN de SYSDIR/UPDATE

- DATA.PSAR de l'EBOOT.PBP est identique a DATA.BIN de SYSDIR/UPDATE MAIS contient 16 octets supplementaires a la fin

En fait DATA.PSAR et DATA.BIN sont identiques et les 16 octets rajoutés le sont a la fin du fichier EBOOT.PBP mais comme le

fichier EBOOT.PBP ne contient pas d'informations de taille mais des informations d'adresses de fichier, PBP-Unpacker et

n'importe quel autre programme de gestion de PBP croit que ces 16 octets font parties de DATA.PSAR.

-> 16 octets * 8 bits = 128 bits -> Taille d'un MD5

Pourquoi vouloir connaitre le MD5 :

Si on veut downgrader en 1.50, il faut absolument mettre la version de UPDATER_VER dans le PARAM.SFO > 2.00 pour qu'il

veuille bien demarrer mais si on modifie un octet dans l'EBOOT.PBP, le MD5 va changer et ne correspondra plus au MD5 contenu

dans EBOOT.PBP.

J'ai ensuite fait des tests sur l'EBOOT.PBP en modifiant des octets :

- Si un octet est modifié a PARAM.SFO, l'archive est corrompue -> PARAM.SFO fait partie du calcul MD5

- Si un octet est modifié a ICON0.PNG, l'archive est corrompue -> ICON0.PNG fait partie du calcul MD5

- Si un octet est modifié a DATA.PSAR, l'archive est corrompue -> DATA.PSAR fait partie du calcul MD5

- Si un octet est modifié a DATA.PSP, le programme d'update ne se lance pas -> Erreur 0xFFFFFED2 (Le jeu ne se lance pas),

est ce qu'il fait partie du calcul MD5 ?

J'ai ensuite créé un programme PSP qui calcule le MD5 d'un fichier (Voir sur ce site), le calcul MD5 de la

PSP est identique a celui d'un programme sur PC.

Pour calculer le MD5 du fichier EBOOT.PBP, il faut d'abord retirer les 16 derniers octets du fichier (le MD5 deja ajouté par

sony).

Ensuite, on peut faire le calcul qui donne (pour le EBOOT.PBP de l'update 1.50 JAP) :

AF D4 B8 F4 6C 89 BC F7 FC 32 EC 3D C7 1D C7 60

et celui qui est dans l'EBOOT.PBP (les 16 derniers octets) :

81 C8 EA 64 16 B2 3B 85 B7 A5 6B BF A9 32 35 58

Ce qui ne correspond pas !

J'ai ensuite extrait le DATA.PSP de l'EBOOT.PBP et je l'ai decodé avec un programme (voir sur ce site).

J'ai recuperé le code asm avec asmdump pour comprendre comment le MD5 est calculé.

J'ai trouvé du code qui fait appel au coprocesseur (Le coprocesseur qui decrypte ??) avec des calculs complexes, je pense que

ce code correspond au code qui calcule le MD5 :

89774: 3c020010 lui v0,0x10

89778: c441fbbc lwc1 at,-1092(v0) <- acces au coprocesseur

8977c: 3c030024 lui v1,0x24

89780: c4609200 lwc1 zero,-28160(v1)

89784: 46016b42 mul.s $f13,$f13,$f1 <- calcul avec registres du coprocesseur ?

89788: 46016302 mul.s $f12,$f12,$f1

8978c: 00803021 addu a2,zero,32

89790: ac80000c sw zero,12(a0)

89794: 4600683c c.lt.s $f13,$f0

89798: e48c0004 swc1 t4,4(a0)

8979c: 45000003 bc1f c

897a0: e48d0018 swc1 t5,24(a0)

897a4: 24020001 addiu v0,zero,1

897a8: ac82001c sw v0,28(a0)

897ac: 3c020024 lui v0,0x24

897b0: c4419204 lwc1 at,-28156(v0)

897b4: c4c00004 lwc1 zero,4(a2)

897b8: c4629200 lwc1 v0,-28160(v1)

897bc: 3c020010 lui v0,0x10

897c0: 46010002 mul.s $f0,$f0,$f1

897c4: c441fbc0 lwc1 at,-1088(v0)

897c8: acc50020 sw a1,32(a2)

897cc: 460000cd trunc.w.s $f3,$f0

897d0: acc00010 sw zero,16(a2)

897d4: 46801820 cvt.s.w $f0,$f3

897d8: 46020002 mul.s $f0,$f0,$f2

897dc: 46010002 mul.s $f0,$f0,$f1

897e0: 4602003c c.lt.s $f0,$f2

897e4: 00000000 nop

...

Ca continue apres et je pense que pour calculer le MD5, il faudrai créer un programme PSP en assembleur qui accede au

coprocesseur pour lui faire calculer ce MD5.

Je continue les tests ...

MPH (mphtheone@hotmail.com)

[xzibit0007]

alors, là, c'est la premiere fois que je vois vraiment quelque chôse de concret sur toute cette scène PSP et je ne peux que t'encourager et te féliciter MPH.

Continue comme ça et encore bravo.

[ManuSupra]

Oui ça à l'air balèze! Maintenant on attend... ^_^

[nemo12fr]

Un grand merci à toi pour ce grand pas MPH, je ai malheureusement pas les compétences pour t'aider, cequi me fait une raison de + pour tirer mon chapeau

[Kyo_13]

Salut MPH ..... Bravo !

Enfin du concret : tu démontres ce que tu as fait et comment !

Hélas moi non plus je n'ai pas les compétences pour t'aider , ça aurait été volontier !

Je voulais juste te dire Bravo c'est balaise ! Bon courage et bonne chance !!!!

[yooplaboom]

bravo bravo je clap dans mes mains

[mph]

Merci a tous pou vos encouragements et je continue mes recherches des que j'ai le temps.

Merci aussi a ceux qui m'ont proposés de l'aide, pour l'instant c'est ok mais si j'ai besoin d'aide vous serez les premiers prevenus.

Merci encore.

[Titoudoc]

Un grand bravo...il est clair que si on arrive a patcher la rom a updater pour faire passer une 1.5 pour une 2.0 c'est good

Bref, continus tes recherches dans te prendre la tête...prends ton temps...have fun tu es sur la bonne voie.

[Ecco_]

Salut MPH, c'est cool d'avoir quelqu'un qui s'y connait un minimum _ET_ qui est poli et qui partage _vraiment_ ses découvertes. Merci.

Par contre, juste une petite interrogation : tu montre que quasiement tous les morceaux du eboot servent au calcul du MD5. C'est bien. Cependant, le calcul d'une somme MD5 ne dépend de rien du tout. Je veux dire, tu prends un fichier, tu calcule son MD5 sur un Palm, sur un Mac, ou sur une station SUN, t'as toujours le même hash (c'est d'ailleurs un interêt du MD5). Bien. Hors, tu pars d'une affirmation : "on a 128 bits DONC c'est du MD5". Euh... le fait que l'on ait 128 bits de checksum, je suis tout à fait d'accord. C'est même très crédible.

Mais pour quoi donc du MD5 ??? Sincèrement, on a juste 128 bits comme ça, et d'où sait-on que c'est du MD5 ?? Je trouve ça complètement délirant, sincèrement. Le but de ce MD5, manifestement, c'est aussi d'empêcher le piratage. Alors pourquoi ne pas utiliser un autre algorithme nettement plus performant ?

La question que je me pose est la suivante : Sony n'utiliserait-il pas finalement un algo à clef publique-clef privé, qui serait véritablement incassable ?

Merci à MPH de bien vouloir réagir (et s'il vous plait ne pourrissez pas le forum pour dire "whaaa, cool, des mots compliqués") :-D

[tonio2k]

Hello,

- Si un octet est modifié a DATA.PSP, le programme d'update ne se lance pas -> Erreur 0xFFFFFED2 (Le jeu ne se lance pas), 

est ce qu'il fait partie du calcul MD5 ?

J'imagine que le data.psp, une fois l'octet modifié, n'est plus un executable valide. Peut-etre serait-il possible de comparer en injectant dans le pbp une autre version du data.psp (provenant d'une autre version d'upgrade) afin de conserver un executable correct.

Si l'archive est encore corrompue, alors il y'a des chances que le data.psp soit utilisé dans le calcul de ce md5 (mais sous quelle forme, cryptée, decryptée ?).

Mais pour quoi donc du MD5 ??? Sincèrement, on a juste 128 bits comme ça, et d'où sait-on que c'est du MD5 ?? Je trouve ça complètement délirant, sincèrement. Le but de ce MD5, manifestement, c'est aussi d'empêcher le piratage. Alors pourquoi ne pas utiliser un autre algorithme nettement plus performant ?

Il me semble qu'effectivement, l'idée du md5 n'est qu'une hypothese de travail (comme toute recherche sur la psp, tentative de buffer overflow etc...). Mais on peut penser (et ce sont toujours des hypotheses) que:

- le md5 est parfait pour vérifier si une archive n'a pas été endommagée, et cela sans considerer une quelconque protection contre le piratage, cad: ereur lors du telechargement, lors du transfert sur la ms, lors de la lecture de la ms...

- la protection, la vrai, celle a base d'algo de cryptage rsa et ou aes, peut tout à fait rester inviolable puisque, dans le cas du dg, on réutilise des executables deja signés, dans les autres cas, on cherchera comment court-circuiter la vérification du cryptage.

[mph]

Salut MPH, c'est cool d'avoir quelqu'un qui s'y connait un minimum _ET_ qui est poli et qui partage _vraiment_ ses découvertes. Merci.

Par contre, juste une petite interrogation : tu montre que quasiement tous les morceaux du eboot servent au calcul du MD5. C'est bien. Cependant, le calcul d'une somme MD5 ne dépend de rien du tout. Je veux dire, tu prends un fichier, tu calcule son MD5 sur un Palm, sur un Mac, ou sur une station SUN, t'as toujours le même hash (c'est d'ailleurs un interêt du MD5). Bien. Hors, tu pars d'une affirmation : "on a 128 bits DONC c'est du MD5". Euh... le fait que l'on ait 128 bits de checksum, je suis tout à fait d'accord. C'est même très crédible.

Mais pour quoi donc du MD5 ??? Sincèrement, on a juste 128 bits comme ça, et d'où sait-on que c'est du MD5 ?? Je trouve ça complètement délirant, sincèrement. Le but de ce MD5, manifestement, c'est aussi d'empêcher le piratage. Alors pourquoi ne pas utiliser un autre algorithme nettement plus performant ?

La question que je me pose est la suivante : Sony n'utiliserait-il pas finalement un algo à clef publique-clef privé, qui serait véritablement incassable ?

Merci à MPH de bien vouloir réagir (et s'il vous plait ne pourrissez pas le forum pour dire "whaaa, cool, des mots compliqués") :-D

510285[/snapback]

Je me disait que c'etait peut etre un MD5 mais seulement sur certains fichiers du EBOOT.PBP et pas dans sa totalité, ca aurait renforcé la securité, vu que la premiere chose que les gens ferait, ce serait de faire un MD5 sur le fichier complet.

Mais tu as raison, je ne pense pas que c'est un MD5, c'est une signature comme un MD5 mais calculée autrement.

[mph]

Hello,

- Si un octet est modifié a DATA.PSP, le programme d'update ne se lance pas -> Erreur 0xFFFFFED2 (Le jeu ne se lance pas), 

est ce qu'il fait partie du calcul MD5 ?

J'imagine que le data.psp, une fois l'octet modifié, n'est plus un executable valide. Peut-etre serait-il possible de comparer en injectant dans le pbp une autre version du data.psp (provenant d'une autre version d'upgrade) afin de conserver un executable correct.

Si l'archive est encore corrompue, alors il y'a des chances que le data.psp soit utilisé dans le calcul de ce md5 (mais sous quelle forme, cryptée, decryptée ?).

Mais pour quoi donc du MD5 ??? Sincèrement, on a juste 128 bits comme ça, et d'où sait-on que c'est du MD5 ?? Je trouve ça complètement délirant, sincèrement. Le but de ce MD5, manifestement, c'est aussi d'empêcher le piratage. Alors pourquoi ne pas utiliser un autre algorithme nettement plus performant ?

Il me semble qu'effectivement, l'idée du md5 n'est qu'une hypothese de travail (comme toute recherche sur la psp, tentative de buffer overflow etc...). Mais on peut penser (et ce sont toujours des hypotheses) que:

- le md5 est parfait pour vérifier si une archive n'a pas été endommagée, et cela sans considerer une quelconque protection contre le piratage, cad: ereur lors du telechargement, lors du transfert sur la ms, lors de la lecture de la ms...

- la protection, la vrai, celle a base d'algo de cryptage rsa et ou aes, peut tout à fait rester inviolable puisque, dans le cas du dg, on réutilise des executables deja signés, dans les autres cas, on cherchera comment court-circuiter la vérification du cryptage.

510404[/snapback]

Merci pour l'idée du test de DATA.PSP, je n'y avait pas pensé.

J'ai fait le test et l'archive est corrompue, donc mon hypothese (simple) est :

La signature a la fin du fichier EBOOT.PBP est calculée sur le fichier EBOOT.PBP complet et n'est pas un MD5 (vu que le MD5 du fichier complet donne un autre resultat).

Je crois toujours que la signature est calculée par le co processeur qui s'occupe de decoder les programmes signés.

Mais je ne suis pas sur, je continue les tests

(pour le buffer overflow, j'ai fait aussi des tests et j'ai remarqué que la psp ne sauve pas ses variables a coté du registre pointeur d'instructions, donc je ne pense pas qu'un buffer overflow est possible mais je me trompe peut etre)

Modifié 22 septembre 2005 par mph

[stanley]

salut a tous

bah ecouter chapeau bas c vraiment cool ce que vous faite et en plus je suis sur que vous aller y arriver c en se serrant les coudes qu'on y arrive

au moins c'est du concret

ciao et encore bravo messieurs

[Ecco_]

Rebonjour MPH.

Je te propose que nous nous retrouvions sur le channel #psp-fr sur irc.freenode.net

J'aimerais bien discuter "en direct".

Merci

[ManuSupra]

Petite question: c'est pour la 1.52 ou la 2.0? Car je suis sur le point de passer à 2.0 mais j'hésite encore... Merci!

[$po_on]

Si on veut downgrader en 1.50, il faut absolument mettre la version de UPDATER_VER dans le PARAM.SFO > 2.00

apparement c est la 2.00 qu il essaie de hacker et tant mieux

moi j avais la 1.52 j ai passé en 2 pour tester je regrette pas de toute facon y a rien de plus au niveau du hack sur la 1.52

[Jlz]

Lo,

vous êtes carrement hors-sujet.....

J'ai du nettoyer....

++

[kyu]

J'ai pas pris le temps de tout lire mais apparment un nouveau moyen de trouver des collisions dans un md5 vient d'etre trouver (le brute force ne serait plus necessaire) :

http://linuxfr.org/~tfe/19512.html

Donc si il se revele possible de faire un firmware avec un meme md5 que le firmware officiel, la question du calcul du md5 actuel ne se poserait plus ... ce qui pourrait etre trés intérressant.