jimmikaelkael

Non hackchip, t'inquiete, je confond pas, mais en suivant la piste du decryptage des .PAK, je suis tombé la dessus, et c'est plus interassant de voir la constitution de la signature des elf cryptés... Bien sûr que non il n'y a rien a voir avec le mechacon, c'est juste ue pour PCSX2 il se sont pensé sur la partie mechacon et pas magicgate, vu que c'est le fichier cdvd.c. , mais je pense que c'est pareil : Le header , le bloc data, les offset des ces section, la zone, tout est au même endroit que nos fichiers... Et cette BIT key, rappelle toi la fonction SecrCardBootHeader censée utilisé le magicgate demande un argument bit, je sais pas si c'est en entrée en ou retour, mais je suis sûr que c'est la BIT key. Je vais regarder pour les dossier FILES et FILE1

C'est vrai, et de plus a y regarder de plus près, aucun suport de décryptage n'est fourni par l'emulateur, et donc c'est pour ca qu'il dit qu'il faut que le fichier soit déjà décrypté. Par contre HackChip, c'est quand même bien d'avoir appris que la signature se compose de 2 parties 128 bits non ? Reste à savoir commment générer ces BIT key et content key. C'est surtout pour cela que j'ai voulais un log, car même si PCSX2 ne décrypte pas, certaines fonctions interessantes ont été reconstruites comme dans le secrman.

Tu aurait pas un log justement de pcsx2 histoire de voir ce qu'il t'a afficher lors de la tentative de decryptage ?

Normal il semble y avoir une erreur dans la comparaison... Il faudrait modifier le code et recompiler.

Bon ,j'ai toujours pas de réponse de cdvdmania... En revanche j'ai parcouru le code source de pcsx2, et dans le fichier cdvd.c il y a des trucs interessant sur secrman : case 0x8F: // secrman: __mechacon_auth_0x8F SetResultSize(1);//in:0 if (cdvd.mg_datatype == 1){// header data u64* psrc, *pdst; int bit_ofs, i; if (cdvd.mg_maxsize != cdvd.mg_size) goto fail_pol_cal; if (cdvd.mg_size < 0x20) goto fail_pol_cal; if (cdvd.mg_size != *(u16*)&cdvd.mg_buffer[0x14]) goto fail_pol_cal; SysPrintf("[MG] ELF_size=0x%X Hdr_size=0x%X unk=0x%X flags=0x%X count=%d zones=", *(u32*)&cdvd.mg_buffer[0x10], *(u16*)&cdvd.mg_buffer[0x14], *(u16*)&cdvd.mg_buffer[0x16], *(u16*)&cdvd.mg_buffer[0x18], *(u16*)&cdvd.mg_buffer[0x1A]); for (i=0; i<8; i++) if (cdvd.mg_buffer[0x1C] & (1<<i)) SysPrintf("%s ", mg_zones[i]); SysPrintf("\n"); bit_ofs = mg_BIToffset(cdvd.mg_buffer); psrc = (u64*)&cdvd.mg_buffer[bit_ofs-0x20]; pdst = (u64*)cdvd.mg_kbit; pdst[0] = psrc[0]; pdst[1] = psrc[1];//memcpy(cdvd.mg_kbit, &cdvd.mg_buffer[bit_ofs-0x20], 0x10); pdst = (u64*)cdvd.mg_kcon; pdst[0] = psrc[2]; pdst[1] = psrc[3];//memcpy(cdvd.mg_kcon, &cdvd.mg_buffer[bit_ofs-0x10], 0x10); if (cdvd.mg_buffer[bit_ofs+5] || cdvd.mg_buffer[bit_ofs+6] || cdvd.mg_buffer[bit_ofs+7])goto fail_pol_cal; if (cdvd.mg_buffer[bit_ofs+4] * 16 + bit_ofs + 8 + 16 != *(u16*)&cdvd.mg_buffer[0x14]){ fail_pol_cal: SysPrintf("[MG] ERROR - Make sure the file is already decrypted!!!\n"); cdvd.Result[0] = 0x80; break; } } cdvd.Result[0] = 0; // 0 complete ; 1 busy ; 0x80 error break; Cela prouve bien ma théorie du bloc header et du bloc data, et en plus il y a même des flags... De plus on voit même que notre fameux ID magicgate des fichiers cryptés, et on voit qu'il est composé de 2 partie de 16 octets, la BIT key et la content key. dans le code a mon avis mg c'est pour MagicGate. Et je pense que la BIT key a un rapport avec l'argument bit de la fonction de secrman : int SecrCardBootHeader(int port, int slot, void *buf, void *bit, int *size);

Ouais c'est vrai c'est un point que j'avais zappé, égoïste que je avec ma ps2 au laser foutu !

Non non rei je disait cela a ptit_rat, car il disait que datel a déjà fait ce que nous essayons de faire, en parlant du memory plus. Oui en effet en savoir plus sur cette carte nous aidera, j'ai déjà contacter kiwicider pour faire un dump, mais j'ai pas de réponse.

Tu n'a pas comprit ? nous c'est Free OS, gratuit pour tous, c'est ça le projet.

Notre but est dans un premier d'arriver a le faire fonctionner sur une datel 32mo, et ensuite sur les CM officielles si on peut... Mais rien est au point encore.

ok je vais leur exposer notre projet et demander des infos.

Au fait HackChip, en disant que l'on ne pouurait pas encrypter les fichiers avec SECRMAN, je me suis trompé ! Sur CDVDMANIA il a cette phase : A savoir comment pouvons nous trouver ce secrman spécial... Je suis bien curieux de savoir si cela peut crypter les fichiers exactement comme l'on fait la team memento. Sinon j'ai regardé un peu le code de secrman, et j'ai du mal... Je ne pense pas me tromper en disant que ces 2 fonctions servent à decrypter un elf : /*Decrypts file header using memory card*/ int SecrCardBootHeader(int port, int slot, void *buf, void *bit, int *size); /*Decrypts data block (part of file) using memory card*/ int SecrCardBootBlock(void *src, void *dst, int size); Et celle ci un irx : /*Decrypts a file (IRX) using memory card. (MODLOAD)*/ void *SecrCardBootFile(int port, int slot, void *buf); Mais je ne vois pas laquelle utiliser pour tenter de decrypter les fichiers du FILES.PAK, vu qu'il n'ont pas l'air d'avoir d'entete comme un elf crypté...

Pendant qu'il en est encore temps, j'ai récupéré ça sur google, ca provenait du post free vast sur psx-scene ou un membre l'avait posté. SecrAuthCard start card auth 0x60 mechacon auth 0x80 card auth key change card auth 0x00 mechacon auth 0x81 card auth 0x01 card auth 0x02 mechacon auth 0x82 card auth 0x03 card auth 0x04 mechacon auth 0x83 card auth 0x05 mechacon auth 0x8f mechacon auth 0x84 mechacon auth 0x85 card auth 0x06 card auth 0x07 card auth 0x08 card auth 0x09 card auth 0x0a card auth 0x0b card auth 0x0c card auth 0x0d card auth 0x0e card auth 0x0f card auth 0x10 card auth 0x11 mechacon auth 0x86 card auth 0x12 card auth 0x13 mechacon auth 0x87 card auth 0x14 mechacon auth 0x88 card decrypt start card decrypt 0x40 card decrypt 0x41 card decrypt 0x42 card decrypt 0x43 header length %d secr_set_header: fail write_HD_start secr_set_header: fail write_data secr_set_header: fail pol_cal_cmplt Set Header failed Cannot read BIT SecrCardBootFile: Cannot decrypt header SecrCardBootFile: failed SecrDiskBootFile: Cannot decrypt header SecrDiskBootFile: failed mecha command:%02x param: %02x card_command error 0 sio2 error 0 ID error 0 result failed 0 card_command error %d sio2 error %d ID error %d result failed %d check sum error %d kbit_offset %d kc_offset %d don't get elf header don't get program header load elf error Il ne disait pas d'ou cela provenait, mais on vient un peu le processus de decryptage.

Oui j'y ai pensé plein de fois à tiktok'n botch... Mais peut-être il ont galeré a tout extraire car ils ont peut-être zappé le coups de la FAT qui tourne en boucle. Ont-ils bien eu le memento.bin comme nous l'avons eu ? C'est clair que ca serait vraiment interessant de partager des infos avec eux. Déjà si on arrive a faire tourner l'image de la memento avec la signature modifiée, on aura avancer d'un pas. Et de ton côté, ta ps2 jap tu l'a eu ?

En fait, d'origine l'image memento n'a aucune erreur ECC, myMC en détecte juste parce que les ecc de l'image memento se termine par 0xFFFFFFFF, un bug de myMC car c'est tout de même correct, les ECC n'utilise effectivement que les 12 premiers octets sur les 16 disponibles (quatre morceaux de 128 octets encodés sur 3 octets). Mon Correcteur d'ECC vérifie les ECC de toutes les pages du Dump, il les corrige si l'on a modifié les données d'une page, sauf qu'il termine l'ecc par 0x00000000, et donc par la même occasion ne déclenche plus aucune erreur ecc sous myMC. Pour SECRMAN, apparement non il ne peut pas encrypter, il nous faudrait un kit officiel Sony, on a qu'a demander a la memento team

Pour SECRMAN, j'éssaie de me donner bonne conscience en me disant que tout ce que je veux faire , c'est un backup de mon memento. Oui, peut de programme semblent l'utiliser en effet, mais le module mcsioemu de HdProject l'utilise : Il effectue un hook de la fonction SecrAuthCard afin de retourner success a chacun de ses appels. Et cela dupe le magicgate... Sur cdvdmania on peut déjà trouver ça : /* Decrypts file header using memory card. */ int SecrCardBootHeader(int port, int slot, void *buf, void *bit, int *size); /* Decrypts data block (part of file) using memory card. */ int SecrCardBootBlock(void *src, void *dst, int size); /* Decrypts a file (IRX) using memory card. (MODLOAD).*/ void *SecrCardBootFile(int port, int slot, void *buf); Il faut juste trouver a quoi correspond chaque argument, port et slot je vois déjà. Comme je te l'ai déja expliqué avec les champs hexa des fichiers cryptés, on peut déjà déterminer la taille et l'emplacement du header, et celle du bloc data. Pour l'outil ECC, oui ca marche sans, mais dans ce cas après modifications, il y a des erreurs ECC sur la carte et certains logiciels peuvent les détecter... C'est quand même mieux d'avoir une carte avec des ECC qui correspondent au données, c'est plus logique non ?

Non hackchip, le patch ECC corrige juste les ECC existantes. Cela nous permet de modifier un dump et d'en corriger l'ecc après modification. J'ai juste mis "A virer" dans le pense-bête pour bien stipuler que dans un descripteur de fichier, l'offset 0x00 correspond bien au mode du fichier. Pour les fichier du FILES.PAK, ce ne sont pas des ELF malheuresement, j'ai testé quand même avec ps2-unpacker mais bien sûr ca ne fonctionne pas... Les fichier n'ont pas l'air d'avoir d'entête... en tout cas je ne vois rien de ce qui pourrait y ressembler. Il va falloir utiliser le SECRMAN a mon avis...

Ok bon, j'ai corrigé et complété la table descripteur de fichier : ### Description D'un Fichier Image Dans Une Table MC ### 777F 7F77 7F7F 777F 7F77 7F7F 0000 0000 <= // A virer, c'est l'ECC de la page précédente 1784 0000 0000 8000 0010 160B 1C0A D707 <= Voir *A 775F 0000 0000 0000 0010 160B 1C0A D707 <= Voir *B 0000 0000 0000 0000 0000 0000 0000 0000 <= ??? 0000 0000 0000 0000 0000 0000 0000 0000 <= ??? 6F73 6431 3130 2E65 6C66 0000 0000 0000 <= Nom Du Fichier (osd110.elf) ### *A ### Groupe 01 : 1784 = Attribution Du Fichier (rwx-f) Masques utilisés (à ajouter en ET logique) : 0x0001 DF_READ : Lecture. 0x0002 DF_WRITE : Ecriture. 0x0004 DF_EXECUTE : Execution. 0x0008 DF_PROTECTED : Le dossier est protégé. 0x0010 DF_FILE : Fichier normal. 0x0020 DF_DIRECTORY : Dossier. 0x0040 : Utilisé en interne pour créer des dossiers. 0x0080 : Copié ? 0x0200 O_CREAT : Utilisé pour créer des fichiers. 0x0800 DF_POCKETSTN : Fichiers de sauvegarde PocketStation. 0x1000 DF_PSX : Fichier de sauvegarde PSX. 0x2000 DF_HIDDEN : Caché. 0x8000 DF_EXISTS : L'entrée est utilisée, ce ce flag est OFF, le fichier ou dossier a été éffacé. Groupe 03 Et 04 : 0000 8000 = 8388608 Bytes Groupe 05 : 10 = Seconde de création Du Fichier (16) Groupe 06 : 16 = Minute de création Du Fichier (22) 0B = Heure de création Du Fichier (11) Groupe 07 : 1C = Jour de création Du Fichier (28) 0A = Mois de création Du Fichier (10) Groupe 08 : 07D7 = Année de création Du Fichier(2007) ### *B ### Groupe 01 : 775F = Emplacement Du Fichier Sur La Carte Mémoire (0X18C0000) Groupe 05 : 10 = Seconde de modification Du Fichier (16) Groupe 06 : 16 = Minute de modification Du Fichier (22) 0B = Heure de modification Du Fichier (11) Groupe 07 : 1C = Jour de modification Du Fichier (28) 0A = Mois de modification Du Fichier (10) Groupe 08 : 07D7 = Année de modification Du Fichier(2007)

Voilà j'ai fait un petit outil en ligne de commande pour corriger les ECC de nos dump : ECC.rar Il s'utilise comme suit : ECC fichier_a_corriger Je pense que cela peut être utile pour nos tests, et attention il ne marche que sur un dump de 32mo contenant déjà l'ECC. Sinon Hackchip, tu m'avait demander si je saurait sortir les fichiers du FILES.PAK provenant du dvdplayer, bbnav et autres... Et bien oui, je peut les sortir, mais les plus important semplent cryptés... donc cela ne nous aidera pas beaucoup je pense. Je pense à me demander si je ne pourrait pas faire un prog qui utilise SECRMAN et ses fonction SecrCardBootFile, censée décryptée les fichiers cryptés. Mais il doit falloir hooker cette fonction pour avoir le résultat du décryptage je pense. Peut être que polo en sait plus là dessus...

Pendant que j'y suit voici les sources du Memor Tool : Memor32 Tool Sources Alors moi je l'ai compilé avec lcc, faut juste mettre à jour le .prj Et celle du HdProject v1.07 + McFlasher : HDProject v1.07 + McFlasher Sources HDProject v1.07 + Mc Flasher compilé se trouve ici : HDProject v1.07 + McFlasher Il y a 2 elf, l'un est packé, l'autre non.

Tu semble avoir le descripteur en entier sauf que je suis pas d'accord là dessus : 0x5F77 = cluster 24439 + 1er cluster allouable 137, ca nous fait 24576 *1056 (oui l'ecc en plus) = 0x18C0000 : départ du fichier osdxxx US

Ah oui aussi, je voulais te parler de ça : http://img264.imageshack.us/img264/5637/osdeurey1.th.jpg Si tu ajoute 0x00147FA0(taille du bloc data) + 0x0260(taille du bloc header), tu trouve 1344000, qui est sensée être la taile du fichié crypté, en tout cas la ps2 tient compte de cette taille pour le decryptage et l'execution. Dans mon image modifié j'ai rectifié les tailles des osdxxx de 8mo à 1,3 mo(enfin 1344000 octets) et ca marche bien ! Juste un octets de moins, ca ne boote plus... Tu peut vérifier cette histoire de taille avec les autres fichiers cryptés du dvdplayer ou bbnav et autres, tu verras ca fonctionne a chaque fois.

Oui hackchip, c'est certains que si les dummy sont présent c'est parce qu'il s'en sont servit pour mettre leur fichiers, ensuite ils ont réarrangé la FAT. On le voit bien car rien ne pointe sur les dummy, ils sont enregistrés comme clusters perdus par myMC. Mais se dont je veut parler pour le fichier MEMENTO.BIN, c'est que le cluster de FAT indirecte (celui ou les infos sur le fichier MEMENTO.BIN sont stockées) mentionne une taille de 9 octets (pour le firmware 1.2e, 256 octets pour le FW1.0), et pointe sur un cluster dummy avec marqué MEMENTO dedans. Seulement, en regardant la FAT j'ai pu remarqué que ce cluster dummy, pointe lui sur l'adresse 0x18F1800, là ou commence l'OS memento (qui fait 192 ko pour le 1.2e). En clair, modifie juste la taille du fichier MEMENTO.BIN à 192 ko + 1 ko (le cluster dummy), et tu récupère le fichier MEMENTO.BIN en entier. Essaie tu verra... je vais essayer de te faire un petit util en ligne de commande pour reconstruire les ECC, mais avec myMC tu peut tester en utilisant l'option -i. Regarde bien cette image écran : http://img187.imageshack.us/img187/2778/fatdx0.th.jpg C'est ler 1er cluster de FAT qui démarre a 0x2520, la partie entourée correspond au cluster dummy du fichier MEMENTO.BIN, donc si vraiment le fichier s'arretait là, il y aura FFFFFFFF pour marquer la fin de fichier or là il ya 0x80 au début pour marquer l'utilisation, et 0x6037 (24631 + 137 qui est le premier cluster allouable marqué dans le superbloc * 1056, la taille d'un cluster+ECC = 0x18F1800). Et le plus drôle, regarde : http://img80.imageshack.us/img80/6369/fat2gt8.th.jpg Au passage j'ai juste entouré le cluster qui pointe sur lui même du osdxxx.elf version EUR, celui qui cause la répétition. C'est la suite du fichier MEMENTO.BIN à partir de la ligne, et bien si je met à vide tout ces clusters qui pointe sur les suivants, et bien l'OS memento fonctionne quand même ! Seules les 2 premiers clusters doivent être liés, le 0x04 (le dummy du .BIN lié a la fat indirect, qui d'ailleurs peut être déplacer n'importe ou sur la carte et modifié, du moment qu'i pointe bien sur 0x18F1800 ), et le 0x6037 (0x18F1800). Après je pense que leur programme lit donc a une adresse spécifique.

Ok je comprend mieux Hackchip, merci our le lien. Par contre ce qui m'enerve, c'est de ne pas arriver a déplacer ces fichus fichiers sur la carte de façon à ce que sa rentre sur une 8mo. Ce que je commence à me demander, c'est est-ce que le FW memento ne ferait pas un petit McReadPage aux offsets ou il y a les fichiers et si il vérifie pas que la première page est intacte... Je vais tenter de m'en assurer en déplaçant le memento.bin (code qui commence à 0x18F1800), le relinker dans la FAT, mais sans effacer le code original. A ce sujet je possède une image memento sacrément retouchée ou j'ai déprotéger les fichiers, modifié les tailles des fichiers (en remplacant par celle mentionnée par les 2 dword du header des osdxxx.elf) et supprimé des morceaux de code après le fameux cluster qui se répète... Et ca fonctionne.

ouais, c'est juste dommage que psx-scene ai coupé juste au moment au j'avait mis au point 2 images memento rectifiées avec les signatures des cartes Datel de 2 membres : Stayhyetreez et r3lic... J'ai n'ai donc eu aucun résultat, je croit qu'il n'ont pas eu le temps de télécharger le fichier... Bref je lance un appel, si quelqu'un ici a une ps2 EUR, un original de dvdplayer update installable sur sa machine ainsi qu'une carte mémoire de 32mo, si il veut bien se présenter ca serait cool !

Yes hackchip j'ai commencer a integrer un module McFlasher à Hd_Project. Cela se présente plutôt bien. je vous tiens au courant !