Edition de fichier en Hexa et Checksum

Edition de fichier en Hexa et Checksum - Divers - Programmation

Marsh Posté le 03-04-2007 à 14:36:28    

Bonjour  :hello:  
 
J'aimerais savoir si des personnes ici s'y connaissent en edition de fichier avec un editeur hexa, et surtout en checksum ?  :??:  
 
En fait je suis en train d'essayer de modifier une sauvegarde de jeu ps3.
Celle-ci est en NTSC, et je voudrais la passer en PAL.
Pour une sauvegarde ps2, pas de soucis, il y a 2 valeurs à modifier dans le fichier,  puis mettre à jour un petit checksum crc-32.
Par contre pour la ps3, c'est autrement plus compliqué, car 3 fichiers sont encapsulé dans un seul au format .PSV  
Et ce fichier possède un (ou plusieurs) checksum, je pense savoir ou il est, mais impossible de trouver son format.
J'ai essayé tous les formats dispo dans Hex WorkShop (crc-32 mais vu la longueur ca ne doit pas être ça, MD2, MD4, MD5, SHA1..)
J'avais trouvé une piste hier, mais j'ai bêtement oublié de noter les positions  :(  
 
Donc si des gens voudraient m'aider un peu, ca serait pas de refus  ;)  
 
 
EDIT : la question est aussi de savoir si l'algorithme de la somme de contrôle est "standard" ou propre à la console.
D'après mes suppositions quand à son emplacement et sa longueur, ca pourrait être deux checksum MD4 (ou MD5) additionnés.
J'ai d'abord pensé à deux checksum different, le premier controlant l'ensemble du fichier, le deuxieme qu'une partie (l'entête par exemple).
Donc autrement dit que les deux soient encapsulés...  :sweat:  
 
 
 
PS : Si ce post est hors charte  :??: , je l'efface de suite. Post autorisé par Harkonnen


Message édité par Profil supprimé le 03-04-2007 à 15:05:52
Reply

Marsh Posté le 03-04-2007 à 14:36:28   

Reply

Marsh Posté le 03-04-2007 à 14:51:03    

la ps3 snul :o
 
[:shay]

Reply

Marsh Posté le 03-04-2007 à 15:04:34    

Voici une jolie image pour montrer un peu à quoi ca ressemble :
 
http://img148.imageshack.us/img148/908/checksumbx3.jpg
 
- L'offset 0010 à 002F represente la position présumée du checksum
- Les deux chaînes de caractères à droite, les valeurs à modifier


Message édité par Profil supprimé le 03-04-2007 à 15:21:52
Reply

Marsh Posté le 03-04-2007 à 15:08:00    

1A-2F ca fait 2E6414A9...3E69
c'est pas un peu immense comme adresse ca ? je sais bien qu'en blu ray on peut stocker bcp mais qd meme...

Reply

Marsh Posté le 03-04-2007 à 15:12:21    

Tamahome a écrit :

1A-2F ca fait 2E6414A9...3E69
c'est pas un peu immense comme adresse ca ? je sais bien qu'en blu ray on peut stocker bcp mais qd meme...


Je me suis peut être mal exprimé, par 0010-002F, je voulait parler du "rectangle" sur la deuxieme et troisieme ligne  ;)  
 
Et oui ca fait beaucoup pour un checksum, mais j'ai entendu parler de checksum "additionnés" (CRC-64 par exemple), donc ca aurait pu être deux MD4 (ou MD5) additionés, même si je doute que ca soit ca.
C'est pourquoi je presume que ca soit 2 checksum different, controlant soit deux parties distinctes du fichier, soit un checksum genéral, et un second qui contrôle qu'une petite partie (entête par exemple).
 
Mais mes connaissances dans ce domaine sont limitées, je fait peut être erreur?  ;)


Message édité par Profil supprimé le 03-04-2007 à 15:22:03
Reply

Marsh Posté le 03-04-2007 à 15:15:38    

ah bah comme ton rectangle rouge prends les 2 lignes, me suis trompé [:joce]
 
Sinon ca parait bizarre ce "saut" entre 1F et 2A pour stocker une adresse... pourquoi ce saut ?

Reply

Marsh Posté le 03-04-2007 à 15:21:20    

Tamahome a écrit :

ah bah comme ton rectangle rouge prends les 2 lignes, me suis trompé [:joce]
 
Sinon ca parait bizarre ce "saut" entre 1F et 2A pour stocker une adresse... pourquoi ce saut ?


 
Désolé j'ai fait un petite erreur de frappe (offset 0010 à 002F).
 
http://img457.imageshack.us/img457/7272/positionchecksumef5.jpg

Reply

Marsh Posté le 03-04-2007 à 15:22:10    

je te remplacerais tout ca par 4E71 moi :D

Reply

Marsh Posté le 03-04-2007 à 15:23:14    

Tamahome a écrit :

je te remplacerais tout ca par 4E71 moi :D


 :lol:  
 

Spoiler :

:??:  :D

Reply

Marsh Posté le 03-04-2007 à 15:25:26    

Je pense serieusement à ce que :
 
La position 0010 à 001F (2ème ligne) corresponde à un checksum sur la totalité du fichier.
La position 0020 à 002F (3ème ligne) corresponde à un checksum sur une partie du fichier.
 
Enfin disons que c'est ce qui me semble le plus probable selon moi  :??:
 
 
Donc le soucis est :
- trouver le format du checksum (en esperant que ca soit un format standard, sinon c'est foutu, enfin trés tendu pour trouver l'algorithme  :whistle: )
- trouver les positions de départ et de fin pour celui-ci  :pt1cable:  
 
Aidez moi, j'en dort plus la nuit, je pense qu'à ca  :bounce:

Message cité 1 fois
Message édité par Profil supprimé le 03-04-2007 à 15:31:12
Reply

Marsh Posté le 03-04-2007 à 15:25:26   

Reply

Marsh Posté le 03-04-2007 à 15:33:17    


 
pour les nostalgiques de l'Atari ST (et du miga), le 4E71 est l'opcode pour NOP en asm 68k (ca permettait d'avoir les vies infinies etc... tu remplacais un jmp par un nop, et hop, plus de décrément ;D)
 
4E75 faisait le meme effet, mais je me souviens plus a quel opcode ca correspond.

Reply

Marsh Posté le 03-04-2007 à 15:34:43    


 
ah ok, ca ne contient pas l'adresse vers le checksum mais le checksum lui meme ! :D
Et comment sais-tu que ce bouilli d'hexadecimal est un checksum  :??:

Reply

Marsh Posté le 03-04-2007 à 15:35:38    

Un fichier de sauvegarde doit pas être énorme, pourquoi ne pas être absolument stupide et tenter une méthode automatique ?  
( tout les algos de checksum sur toute les sous-parties du fichier à rechercher dans tout les offsets du fichier )
C'est crétin, pas forcément rapide, mais peut-être plus que de deviner en fixant son écran des yeux pendant des heures [:spamafote]


---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.
Reply

Marsh Posté le 03-04-2007 à 15:37:47    

Tamahome a écrit :

pour les nostalgiques de l'Atari ST (et du miga), le 4E71 est l'opcode pour NOP en asm 68k (ca permettait d'avoir les vies infinies etc... tu remplacais un jmp par un nop, et hop, plus de décrément ;D)
 
4E75 faisait le meme effet, mais je me souviens plus a quel opcode ca correspond.


Ah ok, j'ai pas connu tout ca, enfin trop jeune pour tenter ce genre de modif à l'epoque   :whistle:  
 
Pour ce qui est de modifier la partie sauvegarde du jeu (un fichier sauvegarde encapsulé dans ce fichier) est simple comme tout, car un tout petit checksum crc-32, mais bon ce n'est pas mon but  ;)  
Enfin de toute manière pour pouvoir modifier cela, il faut aussi corriger la somme de contrôle au début...

Reply

Marsh Posté le 03-04-2007 à 15:42:27    

0x90 a écrit :

Un fichier de sauvegarde doit pas être énorme, pourquoi ne pas être absolument stupide et tenter une méthode automatique ?  
( tout les algos de checksum sur toute les sous-parties du fichier à rechercher dans tout les offsets du fichier )
C'est crétin, pas forcément rapide, mais peut-être plus que de deviner en fixant son écran des yeux pendant des heures [:spamafote]


J'y ai pensé, mais cela risque de prendre du temps .. enfin vu le temps que je passe la dessus, ca serait peut être plus rapide  :D  
Mais le truc, comme je disais c'est que j'avais trouvé hier, si je me souviens bien, la 2eme ligne verifiait casiment tout le document (donc celle d'apres une partie j'imagine) mais je n'arrive plus à me souvenir le type de checksum, et surtout les positions de départ/fin  :sweat:  
 
Je vais peut être tenter "ta méthode" ce soir si j'ai le temps  :jap:
 
 
(La dernière ligne est 00016AB0, et pas mal de ligne "vide" enfin des 00 juste avant, qui influent sur la somme si je me trompe pas)


Message édité par Profil supprimé le 03-04-2007 à 15:45:22
Reply

Marsh Posté le 03-04-2007 à 15:58:19    

faudrait faire plusieurs sauvegardes différentes et comparer. Plus y'en a mieux c'est.

Reply

Marsh Posté le 03-04-2007 à 17:56:13    

Tamahome a écrit :

faudrait faire plusieurs sauvegardes différentes et comparer. Plus y'en a mieux c'est.


Je l'ai fait, et c'est ce qui m'a permis de penser que ces deux lignes contiennent la valeur du checksum  ;)

Reply

Marsh Posté le 04-04-2007 à 19:09:12    

Bon en fait après quelque recherches, les fichier de sauvegarde ps3 sont signé numeriquement, avec une clef qui est (trés) difficile à craquer (tout comme la xbox360), enfin dans tous les cas ca depasse de loin mes compétances dans ce domaine.
 
 :jap:
 
Craquer cette clef en force brute est casiment impossible (si le niveau de sécurité est le même que la xbox360).
 

Citation :

In 1999, a group of cryptographers built a DES cracker. It was able to perform 2^56 DES operations in 56 hours. The machine cost $250K to build, although duplicates could be made in the $50K-$75K range. Extrapolating that machine using Moore's Law, a similar machine built today could perform 260 calculations in 56 hours, and 2^69 calculations in three and a quarter years. Or, a machine that cost $25M-$38M could do 2^69 calculations in the same 56 hours.


 
Le seul moyen serait d'editer le génerateur de clef dans la ps3 avec un assembleur, et de tenter de trouver l'algorithme  :D
 
 
NB: Le checksum pour les fichiers de sauvegarde xbox360 est de 256 bits ...


Message édité par Profil supprimé le 04-04-2007 à 19:51:35
Reply

Marsh Posté le 05-04-2007 à 07:18:05    

et ca ne pose pas de pbm de vendre ca en France ? je croyais qu'on était limité a 128 bits :??:

Reply

Marsh Posté le 06-04-2007 à 21:32:41    

Tamahome a écrit :

et ca ne pose pas de pbm de vendre ca en France ? je croyais qu'on était limité a 128 bits :??:


Oui c'est que je me suis demandé aussi..
Apparement ils ont le droit maintenant  :sweat:  
 
Je voit vraimment pas l'interêt de proteger à ce point une sauvegarde de jeux-vidéo   :heink:

Reply

Marsh Posté le 06-04-2007 à 21:55:15    

surement pour éviter qu'un malin trouve une faille quelconque permettant de faire passer des backups (comme la faille avec les memory card de la ps2)


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 07-04-2007 à 12:30:43    

Tamahome a écrit :

surement pour éviter qu'un malin trouve une faille quelconque permettant de faire passer des backups (comme la faille avec les memory card de la ps2)


Oui surement un truc du genre, enfin là logiquement, la ps3 et la xbox360 sont inattaquable à ce niveau vu le système mis en place.
(fonction de hachage cryptographique avec une clé secrete)


Message édité par Profil supprimé le 07-04-2007 à 12:32:51
Reply

Marsh Posté le 07-04-2007 à 12:37:40    

on est jamais trop prudent, surtout vu les montants en jeu (la ps3 vendu a perte etc...)


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 07-04-2007 à 12:47:36    

Oui c'est certain.
 
Mais c'est quand même bizarre que l'etat autorise des clés de ce niveau, normalement on été limité à 128bits.
(C'etait considéré comme une arme les clés avec un niveau de securité supérieur)
 

Reply

Marsh Posté le 07-04-2007 à 13:30:14    

Citation :

La loi du 21 juin 2004 pour la confiance dans l'économie numérique a totalement libéralisé l'utilisation des moyens de cryptologie


 
(la fameuse LEN - article 30)
http://www.legifrance.gouv.fr/WAsp [...] OX0200175L
 
Bah voila pourqoi :D


Message édité par Tamahome le 07-04-2007 à 13:31:24

---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed