mph

Oui tu as raison, je viens de tester et je m'etait trompé en renommant le fichier (me_img.img a la place de meimg.img ). Donc en fait meme avec ce fichier, je n'ai pas assez de mémoire pour initialiser correctement le ME. Vous pouvez donc a la place de renommer les fichiers .img tout simplement les supprimer. Merci beaucoup pour vos tests et vos tutoriels ;-)

Merci beaucoup mais tu dois faire l'inverse : tu dois supprimer le fichier meimg.img (ou le renommer, le deplacer, ..., si tu ne veux pas le perdre) et tu dois renommer le fichier me_sdimg.img en meimg.img. L'explication est simple : Les fichiers meimg.img et me_sdimg.img sont des images (peut etre d'executables) qui initialise le processeur reprogrammable Virtual Media Engine qui s'occupe de la gestion des vidéos et sons (en gros). le fichier meimg.img contient sans doute la totalité des fonctions tandis que le fichier me_sdimg.img ne contient qu'une version 'light' du meimg.img, il suffit de regarder la taille des fichiers. Comme je manque cruellement de memoire et que le prx de gestion du ME charge le fichier meimg.img, ca bloque a l'initialisation du game loader, si tu utilises le fichier me_sdimg.img (par la technique de renommer les fichiers), ca passe. Ca explique aussi pourquoi le fait de faire un firmware custom retire certaines sequences vidéos et audio (le prx de gestion du ME reste celui de la 2.50 mais quand il va chercher le fichier meimg.img, il ne le trouve pas car le dossier resource est celui du 2.00), ca passe quand meme mais ca n'initialise pas correctement le ME et donc manque de vidéos et de sons dans certains jeux. Maintenant vu que le programme utilise une version 'light' du fichier d'initialisation, je ne garanti pas que tout les jeux auront leur vidéos et sons, il est possible que certaines fonctions manquent dans le ME et que certains fichiers multimedias ne seront pas joués. Mais en attendant la prochaine version du loader (qui chargera sans probleme le firmware 2.50 je l'espere), c'est une bonne petite astuce

http://forums.ps2dev.org/viewtopic.php?t=3917 et http://forums.ps2dev.org/viewtopic.php?t=4249 nem a deja documenté les pins du chip nand/ram de la psp. Si tu veux j'avais fait un programme qui lisait la nand (flash) de la psp avec l'api sceNand, il dumpait la nand complete avec les extra data, si tu veux je te passe les sources. Ce qui est interessant, c'est qu'il y a 1 bad block et 100 blocs non lisible (surement des blocs alternatifs pour le remplacement des blocs défectueux) Il y a aussi de la documentation en pdf sur les memory sticks sony qui sont basées aussi sur de la mémoire nand mais je ne serai plus te dire ou je l'ai vu. Mon idée etait de dumper la nand complete avec les extra data et de la réecrire sur une memory stick pour voir si la psp booterai avec la ms (puisque l'ipl contient du code qui initialise les composants de la psp au demarrage). Courage pour ton projet

http://mphwebsite.tuxfamily.org/phpBB2/viewtopic.php?t=30

Voir ici pour le firmware 2.50 au bon format

Je suis content de tous vous avoir fait plaisir ;-) Joyeux annif, le mien c'est le 29 (demain) Rappel : - Oui on peut revenir en 2.00, 1.50, 2.00, .... - Oui on peut effacer les fichiers une fois passé en 1.50 - Merci a yoshihiro qui m'a aidé dans mes recherches N'oubliez pas, restez legaux, ne tuer pas la psp en n'achetant pas de jeux !! Mon prochain prog, ce sera un reparateur de pixels figés (blancs) A+

Juste pour vous dire que le fait de downgrader puis d'upgrader en 2.00 fonctionne ;-)

Salut a tous voici le lien pour ceux qui ne serait pas aller sur psphack : http://rapidshare.de/files/5607151/MPHDowngrader.zip.html N'ayez pas peur ca marche ;-)

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 ?). 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)

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.

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.

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)