Comment pourrais-je deviner un algorithme de somme de contrôle?

Question

Supposons que j'ai des paquets avec une somme de contrôle de 16 bits à la fin. Je voudrais deviner quel algorithme de somme de contrôle est utilisé.

Pour commencer, à partir des données de vidage, je peux voir qu'un changement d'octet dans la charge utile du paquet modifie totalement la somme de contrôle. Je peux donc supposer qu'il ne s'agit pas d'un simple XOR ou d'une somme.

Ensuite, j'ai essayé plusieurs variantes de CRC16 , mais sans trop de chance.

Cette question est peut-être plus biaisée en faveur de la cryptographie, mais je suis vraiment intéressé par tout outil statistique facile à comprendre permettant de déterminer le CRC que cela pourrait être. Je pourrais même me tourner vers dessiner différents algorithmes de CRC si tout le reste échoue.

Histoire: j'ai un protocole RFID série avec une sorte de somme de contrôle. Je peux rejouer des messages sans problème et interpréter les résultats (sans vérification de la somme de contrôle), mais je ne peux pas envoyer de paquets modifiés car l'appareil les laisse tomber sur le sol.

À l'aide d'un logiciel existant, je peux modifier la charge utile de la puce RFID. Cependant, le numéro de série unique étant immuable, je n’ai pas la possibilité de vérifier toutes les combinaisons possibles. Bien que je puisse générer des dumps de valeurs incrémentant de un, mais pas assez pour rendre la recherche exhaustive applicable à ce problème.

Les fichiers de vidage avec des données sont disponibles si la question est elle-même n'est pas suffisant: -)

Besoin de documentation de référence? GUIDE SANS DOULEUR DU CRC ERREUR DETECTION ALGORITHMES est une excellente référence que j'ai trouvée après avoir posé la question ici.

En fin de compte, après un conseil très utile dans la réponse acceptée que c’est le CCITT, utilisé cette calculatrice CRC et la somme de contrôle générée avec une somme de contrôle connue pour obtenir 0xffff, ce qui m'a amené à conclusion que xor final est 0xffff au lieu de 0x0000 du CCITT.

Answer 1

Un certain nombre de variables doivent être prises en compte pour un CRC:

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

CRC typiques:

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

La première chose à faire est d’obtenir des échantillons en changeant le dernier octet. Cela vous aidera à déterminer le nombre d'octets dans le CRC.

S'agit-il d'une "maison"? algorithme. Dans ce cas, cela peut prendre un certain temps. Sinon, essayez les algorithmes standard.

Essayez de changer le msb ou le lsb du dernier octet et voyez comment cela change le CRC. Cela vous donnera une indication de la direction.

Pour rendre la tâche plus difficile, il existe des implémentations qui manipulent le CRC pour qu’il n’affecte pas le support de communication (protocole).

D'après votre commentaire sur la RFID, cela implique que le CRC est lié aux communications. Généralement, CRC16 est utilisé pour les communications, bien que CCITT soit également utilisé sur certains systèmes.

D’autre part, s’il s’agit d’un marquage RFID UHF, il existe quelques schémas de contrôle CRC: un système à 5 bits et un à 16 bits. Celles-ci sont documentées dans les normes ISO et les fiches techniques IPX.

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

Voici votre réponse !!!!

Après avoir travaillé dans vos journaux, le CRC est celui du CCITT. Le premier octet 0xd6 est exclu du CRC.

Answer 2

Il vous faudrait essayer tous les algorithmes de somme de contrôle possibles et voir lequel génère le même résultat. Cependant, rien ne garantit quel contenu a été inclus dans la somme de contrôle. Par exemple, certains algorithmes ignorent les espaces, ce qui conduit à des résultats différents.

Je ne vois vraiment pas pourquoi quelqu'un voudrait le savoir.

Answer 3

Ce n'est peut-être pas un CRC, ce peut être un code correcteur d'erreur comme Reed-Solomon.

Les codes ECC représentent souvent une fraction substantielle de la taille des données d'origine qu'ils protègent, en fonction du taux d'erreur qu'ils souhaitent gérer. Si la taille des messages est supérieure à environ 16 octets, 2 octets de code ECC ne seraient pas suffisants pour être utiles. Donc, si le message est volumineux, vous avez probablement raison de dire que c'est une sorte de CRC.

Answer 4

J'essaie de résoudre un problème similaire ici et j'ai trouvé un site Web très soigné qui prend votre fichier et exécute des sommes de contrôle avec 47 algorithmes différents et affiche les résultats. Si l’algorithme utilisé pour calculer votre somme de contrôle est l’un de ces algorithmes, vous le trouverez simplement dans la liste des sommes de contrôle produites à l’aide d’une simple recherche textuelle.

Le site Web est https://defuse.ca/checksums.htm

.