J'essaie de trouver le crc qui fonctionne avec les résultats suivants. La chaîne d'octets se compose de 2 octets (ie. 0xCE1E) et la CIDE est un seul octet (ie. 0x03)algorithme crc difficile
byte crc CE1E 03 CE20 45 CE22 6F 0000 C0 0001 D4 FFFF 95
Quelqu'un peut-il aider?
En supposant qu'il s'agit de valeurs à deux octets (16 bits), j'en ai essayé quelques-unes sur certains générateurs CRC en ligne sans obtenir de résultats. Il semble donc que ce n'est pas un algorithme CRC couramment utilisé.
Avez-vous des indices sur l'algorithme probable? Ou est-ce une tâche à faire et vous êtes supposé désosser l'algorithme/les paramètres du CRC?
Résumé: plus d'informations.
Salut, Je n'ai pas d'indices, sauf qu'il donne un résultat de 8 bits (crc ou somme de contrôle?) Et il vient d'un petit émetteur PCB qui transmet des données comme un prototcol dallas 1-wire. Les données sont sous la forme: 0C 0E 01 0E 03 où les quatre premiers octets sont les données et le dernier octet est le crc (ou somme de contrôle). –
D'abord, 4 chiffres hexadécimaux ne sont pas 4 octets. Puisque tous vos exemples montrent 4 chiffres hexadécimaux - 2 octets - je suppose que vous voulez dire 2 octets.
Il n'y a que 65 536 valeurs de hachage distinctes, voici ce que vous faites.
Exécute la fonction de hachage pour toutes les 65.536 valeurs de 0000 à FFFF. Tabuler les résultats. Cette table est la fonction. Il mappe la valeur d'entrée à la valeur de sortie.
Bien que boiteux, c'est toujours correct, ce n'est pas terriblement gros (65K octets), et c'est vraiment rapide après avoir fait le calcul.
Vous ne pouvez pas effectuer de reverse engineering de fonctions de hachage très facilement. Les bons sont des machines d'état sophistiquées qui utilisent tous les bits d'entrée de manière «équitable», de sorte que les valeurs de sortie sont radicalement différentes pour les valeurs d'entrée qui ne diffèrent que de quelques bits.
Si vous comparez 0000 avec 0001, 0002, 0004, 0008, 0010, 0020, 0040, 0080, 0100, 0200, 0400, 0800, 1000, 2000, 4000 et 8000, vous pourriez être en mesure de comprendre ce que chaque peu contribue au hachage. Mais j'en doute.
http://www.geocities.com/SiliconValley/Pines/8659/crc.htm#r2
Il semble à mes yeux inexpérimentés que vous aurez à mettre en œuvre un algorithme crc général et essayer plusieurs polys (essayez les « populaires » mentionnés dans cet article premier).
éditer: après une lecture plus poussée, il semble que vous deviez également prendre en compte les polys inverses.
Un CRC est simplement une division, tout comme vous apprenez la division à longue durée à l'école primaire sauf que l'addition et la soustraction sont remplacées par XOR. Alors, que dans GF (2), vous devez faire est de résoudre les équations suivantes:
CE1E % p = 03
CE20 % p = 45
CE22 % p = 6F
0000 % p = C0
0001 % p = D4
FFFF % p = 95
Il n'y a pas polynôme p pour lequel 0000% p = c0. (0 modulo p vaut 0 pour toutes les valeurs de p.) Donc c'est peut-être (x + input)% p = crc. Dans votre cas, x doit être c0. Si c'est vrai, alors (x + 0001)% p doit être c1. On dirait que ce n'est pas du tout un CRC. Si vous êtes déterminé et que vous croyez que la réponse est linéaire, faites une matrice de zéros et de uns qui est inversible et résolvez l'ensemble des équations qui proviennent de votre matrice times input = output. Cependant, vous aurez besoin de plus d'entrées.
Vos chaînes d'entrée ressemblent plus à des chaînes de 2 octets, c'est-à-dire 16 bits. Si ce n'est pas le cas, vous devez les écrire avec des espaces et (éventuellement) les zéros manquants, par ex. 0C 0E 01 0E -> 03. – unwind
Avez-vous seulement des données de fil, aucun exécutable qui peut être rétrocontrôlé? –