Comprendre l' Algorithme Checksum .

Version imprimable

20/10/2007, 15h53
Fred.77

Comprendre l' Algorithme Checksum .

Bonjour à tous et à toutes ,

Pour permettre aux gens de comprendre cet algorythme je vais utiliser 1 exemple de calcul d'un checksum dont je cherche a comprendre comment la chaine de caractére est calculés pour génerer et calculer le checksum dans un fichier binaire .

Checksum actuel : 1A A3 56 E2 54 81 2D C4
Checksum calculer : 2A C2 76 FE 54 F4 F9 14

Sur différent sites voici l'algo qui est utilisé pour calculer ce checksum , mais le résultat est différent

x64 + x4 + x3 + x1 + 1

Merci pour tout conseil ou suggéstions pourras calculer le bon checksum .
20/10/2007, 17h22
pseudocode

Il y a tutoriel sur le calcul de CRC dispo ici meme:

http://dvsoft.developpez.com/Articles/CRC
20/10/2007, 18h58
Fred.77

Bonjour ,

Merci beaucoup , mais j'ai déja esayer de coder en se basant sur le lien que tu m'as donner mais le résultat c'est un CRC checksum !!!

Mon checksum c'est un XOR checksum qui est différent de la FAQ cité sur le site developpez.net .

Le résultat du checksum est différent vu que la chaine est de 8 OCTETS .

Mon but est de comprendre cet algo en se basant du un checksum genérer .
20/10/2007, 19h23
pseudocode

Citation:

Envoyé par Fred.77

Le résultat du checksum est différent vu que la chaine est de 8 OCTETS .
Mon but est de comprendre cet algo en se basant du un checksum genérer .

Oui, toi tu as un CRC-64 (64 bits = 8octets de 8 bits). Pour autant l'algoritme reste le meme. Dans le tutoriel (chapitre 7) ils utilisent un CRC-16, donc ils ont pris un "remainder" de 16bits. Toi tu dois prendre un remainder de 64bits.

Citation:

Envoyé par pseudocode

Oui, toi tu as un CRC-64 (64 bits = 8octets de 8 bits).prends un remainder de 64bits.

Exact , t'est le seul a trouver ça , j'ai poster sur différents forum , mais personne n'as remaruqé que y'avais sur la chaine 8 Data Bits .

Merci à toi , mais j'ai déja utilisé un algorythme 64 Bits , mais le checksum génerer est différent .

ReHash génere ce checksum : 0xCD D4 38 3D A1 82 1A 15 .
VisualHash CRC 64 Bits checksum : 7D F4 68 50 99 18 A2 75 .
Avec le logiciel CRC64.exe checksum genérer : C5 72 ED 28 FF AD D4 BB

3 Checksum différent avec le méme fichier utilisé en utilisant 3 logiciels différents pour calculer un checksum 64 Bits .

Faut t'il changer la maniére dont les Bits sont XOrés ?
Commençer a faire un Bit Shifted Ou un Bit Oriented ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 * Computes the CRC64 of the buffer of the given length using the * ( slow ) bit - oriented approach */ int crc64_bitoriented ( unsigned char * buffer , int length ) { int i, j; uint64 crcreg = INITXOR ; for (j = 0; j < length ; ++j) { 10 unsigned char b = buffer [j]; for (i = 0; i < 8; ++i) { if (( crcreg ^ b) & 1) { crcreg = ( crcreg >> 1) ^ CRC; } else { crcreg >>= 1; } b >>= 1; } } return crc ^ FINALXOR ; }

20/10/2007, 20h19
pseudocode

Citation:

Envoyé par Fred.77

Exact , t'est le seul a trouver ça , j'ai poster sur différents forum , mais personne n'as remaruqé que y'avais sur la chaine 8 Data Bits .

oui, je suis tres observateur.

Citation:

Merci à toi , mais j'ai déja utilisé un algorythme 64 Bits , mais le checksum génerer est différent .

Sans doute qu'ils n'utilisent pas le meme polynome générateur. C'est louche.
Test tes logiciels avec une chaine texte dont le crc64 est connu:

CRC64("123456789") = 0x46A5A9388A5BEFFE

Quand a ton code, ca me parrait louche vu qu'il utilise un "uint32" pour faire du 64 bits.
20/10/2007, 20h45
Fred.77

Citation:

Envoyé par pseudocode

oui, je suis tres observateur.

Sans doute qu'ils n'utilisent pas le meme polynome générateur. C'est louche.
Test tes logiciels avec une chaine texte dont le crc64 est connu:
CRC64("123456789") = 0x46A5A9388A5BEFFE

Oui surement , mais ce que je ne comprend pas c'est comment les bytes son Xorés ?

voici un checksum que je viens de calculer et qui est BON !

Current Checksum : 1A A3 56 E2 54 81 2D C4
Calculated CheckSum : 2A C2 76 FE 54 F4 F9 14

Le 5 éme Byte en partant de la gauche n'as pas changer .

On remarque que le premier octet avant calcul 1A = 26 en Decimal devient 2A aprés calcul c'est a dire 2A qui donne 42 en Decimal .

Cordialement ,
Fred .
20/10/2007, 21h14
pseudocode

Citation:

Envoyé par Fred.77

voici un checksum que je viens de calculer et qui est BON !

Current Checksum : 1A A3 56 E2 54 81 2D C4
Calculated CheckSum : 2A C2 76 FE 54 F4 F9 14

C'est quoi ces 2 checksum que tu nous donnes ?

Tu parles d'un checksum qui est BON et tu en montres deux. C'est quoi le premier et c'est quoi le deuxieme ?
20/10/2007, 21h24
Fred.77
Citation:

Envoyé par pseudocode

C'est quoi ces 2 checksum que tu nous donnes ?
Les deux checksum sont génerer par un logiciel qui calclul le checksum 64 Bits !
Code:

1 2 C'est quoi le premier et c'est quoi le deuxieme ?
Le premier est l'ancien checksum du fichier binaire et le second et le checksum calculé par le logiciel on ouvrant le fichier binaire .
Code:

1 2 3 Tu parles d'un checksum qui est BON et tu en montres deux.
http://img220.imageshack.us/img220/3406/chksumfa0.jpg

Oui , y'a un Checksum avant que l'utilisateur ait fait des modifications dans un fichier binaire et le deuxiéme checksum est le checksum calcluler
qui est réecrit dans le fichier binaire par le logiciel et la valeur checksum sera récrite dans le fichier binaire .

Cordialement ,
Fred .
20/10/2007, 22h07
pseudocode

Citation:

Envoyé par Fred.77

Oui , y'a un Checksum avant que l'utilisateur ait fait des modifications dans un fichier binaire et le deuxiéme checksum est le checksum calclulerqui est réecrit dans le fichier binaire par le logiciel et la valeur checksum sera récrite dans le fichier binaire .

Donc, pour résumer ce que j'ai compris:

1. Fichier original: CRC=1A A3 56 E2 54 81 2D C4
2. Modification du fichier par l'utisateur
3. Fichier modifié: CRC=2A C2 76 FE 54 F4 F9 14

Jusque la c'est normal. Comme le contenu du fichier a changé les checksum sont differents.

Question: c'est quoi le probleme ?

Edit: j'ai peut d'avoir compris :aie:. Ton programme calcule le CRC des données "seules" et écrit ce CRC dans le fichier. Et toi tu calcules le CRC du fichier qui contient à la fois les données PLUS le CRC. c'est ca ?
20/10/2007, 22h20
Fred.77

Re ,

Merci à Toi .
Que dire de plus c'est EXACTEMEN ça , sauf :

Citation:

Envoyé par pseudocode

Donc, pour résumer ce que j'ai compris:

3. Fichier modifié: CRC=2A C2 76 FE 54 F4 F9 14

EXACT , le logiciel genére un autre CRC aprés que l'utilisateur ait modifié le fichier , donc le checksum est corrigé par le logiciel .

Ce que je comprends pas c'est comment CRC 1A A3 56 E2 54 81 2D C4 .
est calculé pour genérer : CRC=2A C2 76 FE 54 F4 F9 14 .

Cordialement , Fred .
20/10/2007, 22h31
Jedai

Citation:

Envoyé par Fred.77

Ce que je comprends pas c'est comment CRC 1A A3 56 E2 54 81 2D C4 .
est calculé pour genérer : CRC=2A C2 76 FE 54 F4 F9 14 .

La phrase n'est toujours pas compréhensible... Le premier CRC n'est nullement calculé en fonction du second, donc je ne comprend toujours pas ta question.

--
Jedaï
20/10/2007, 22h33
pseudocode

Citation:

Envoyé par Fred.77

Ce que je comprends pas c'est comment CRC 1A A3 56 E2 54 81 2D C4 .
est calculé pour genérer : CRC=2A C2 76 FE 54 F4 F9 14 .

Le 2eme CRC n'est pas calculé à partir du 1er CRC. Non ! Il n'y a pas de formule pour passer directement d'un CRC a l'autre.

Le 2eme CRC (tout comme le 1er) est calculé a partir des données, c'est a dire en parcourant TOUT LE CONTENU du fichier.
20/10/2007, 22h57
Fred.77

Merci à Toi pseudocode ,
21/10/2007, 16h45
Fred.77

Salut pseudoode ,

As tu une idée comment les octets sont calculés ?
Comment comprendre le fonctionnement de ce Checksum ?
21/10/2007, 16h53
pseudocode

Citation:

Envoyé par Fred.77

Salut pseudoode ,

As tu une idée comment les octets sont calculés ?
Comment comprendre le fonctionnement de ce Checksum ?

heu.. oui, je sais comment ils sont calculés. :yaisse2:

Comme c'est expliqué dans le tutoriel. :mrgreen: Tu parcours tous les bits de ton fichier et tu met a jour le registre 64bits du CRC. A la fin, ces 64 bits sont représentés comme 8 octets de 8 bits.

Je dois avoir dans mes archives l'algo implémenté en java si ca peut t'aider.
21/10/2007, 17h01
Fred.77

Quelle trés bonne nouvelle !!!

Ca va faire 2 mois que j'essaye de comprendre ce calcul de bits sur une chaine de 8 Data Bits et tu viens en 2 messages trouver la solution !!!

J'éspére que ce code trouvera et calculera le bon checksum pseudocode , c'est tout ce que je souhaite .

C'est When you Want MAN
21/10/2007, 17h10
pseudocode

Code posté dans le sous-forum "contribuez":

http://www.developpez.net/forums/sho...d.php?t=429810

;)
21/10/2007, 17h13
Fred.77

Un Grand Merci à Toi pseudocode .;)

J'éspére que ce code calculera le bon checksum pour mon fichier binaire .

Sinon je te tiens au courant .
21/10/2007, 23h53
Fred.77

Citation:

Envoyé par Jedai

La phrase n'est toujours pas compréhensible... Le premier CRC n'est nullement calculé en fonction du second, donc je ne comprend toujours pas ta question.

--
Jedaï

Salut ,

Pardon , j'ai pas vu ta réponse hier soir .
Le probléme c'est comment le checksum est calculé ?

Je vais faire quelques exemples pour comprendre ce checksum :

le checksum actuel : 31 22 05 70 89 02 20 7E

Checksum calculé : 81 0C CA 8C FE 2A 38 7B

On va changer juste le premier OCTET de la chaine et on va voir le changement du premier OCTET .

On va incrémenter d'un BYTE la premiére chaine pour voir le chnagement des BYTES dans la 2 éme chaine :

41 22 05 70 89 02 20 7E

Résultat aprés incrémentation d'un Byte Gauche dans la 2 éme chaine :

F1 0C CA 8C FE 2A 38 7B

51 22 05 70 89 02 20 7E
Résultat aprés incrémentation d'un Byte de gauche dans la 2 éme chaine :

E1 0C CA 8C FE 2A 38 7B

On monte toujours d'un Byte de gauche c'est à dire de 51 a 61

61 22 05 70 89 02 20 7E
D1 0C CA 8C FE 2A 38 7B

Plus on ajoute un byte on remarquera que y'a une décrementation .

Premier Octet CRC 1 : 61
Premier Octet CRC 2 Calculé : D1

Premier Octet CRC 71
Premier Octet CRC 2 Calculé : C1

Dés qu'on arrive au 8 l'algo fais l'inverse c'est ç dire décremente i-- ;

Premier Octet CRC : 81
Premier Octet CRC 2 Calculé : 31

Premier Octet CRC : 91
Premier Octet CRC 2 Calculé : 21

Pour le Byte de Droite c'est simple plus on ajoute un byte plus il sera ajoutée à la deuxiéme chaine CRC genérer c'est à dire si on ajoutes +1 on a +1 .

CRC 1 : 32 22 05 70 89 02 20 7E

Résultat CRC 2 Calculé : 82 0C CA 8C FE 2A 38 7B

CRC 1 : 33 22 05 70 89 02 20 7E
Résultat CRC 2 Calculé : 83 0C CA 8C FE 2A 38 7B

CRC 1 : 34 22 05 70 89 02 20 7E
Résultat CRC 2 Calculé : 85 0C CA 8C FE 2A 38 7B

CRC 1 : 37 22 05 70 89 02 20 7E
Résultat CRC 2 Calculé : 87 0C CA 8C FE 2A 38 7B

Et ainsi de suite .

Le Byte de GAUCHE et incrémenter d'un BYTE i ++
Le Byte de DROITE et décrémenter d'un BYTE i --

Fred .

C'est les premiers TESTS éffectués sur ce type de Checksum .
22/10/2007, 00h22
Jedai

Non, non !!
On ne calcule pas un checksum à partir d'un checksum, ok ?

On calcule le checksum d'un fichier, d'une chaîne de caractère... Quand on modifie le fichier, on ne peut pas calculer le nouveau checksum à partir de l'ancien, il faut repartir du fichier.

--
Jedaï
22/10/2007, 14h02
Fred.77

Citation:

Envoyé par Jedai

Non, non !!
On ne calcule pas un checksum à partir d'un checksum, ok ?

J'ai calculer le checksum en changeant le premier OCTET d'une chaine de caractére dans le fichier binaire .

As tu une idée sur le chnagement des BYTES sur la chaine par les exemples que j'ai utilisé plus haut .