Détermination de l'algorithme CRC à partir de data + CRC - application intégrée.

Question

J'ai un ensemble de données protégées par des sommes de contrôle 16 bits que je dois corriger. Les emplacements de la somme de contrôle sont connus, les zones exactes sur lesquelles ils sont calculés et l'algorithme exact utilisé pour les calculer ne le sont pas. 16 bits, LSB en premier. Je suppose que c'est une sorte de CRC 16 bits, mais je n'ai pas pu trouver le code qui calcule les sommes de contrôle.

Exemple:

00    4E00FFFF26EC14091E00A01830393630  
10    30313131313030393030363030313030  
20    30303131313030393030363030313030  
30    30303131313030393030363030313030  
40    3030FFFF225E363436304D313037**0CE0**  
50    64000000000000008080808080800000  
60    00000000**BE6E**FC01E001EB0013010500  

Les sommes de contrôle sont stockées dans 4E et 64. Je ne sais pas si elles sont calculées à partir du décalage dans le premier mot au début de chaque section de données ou à partir de là, ou sur toute la plage. J'ai essayé un certain nombre d'algorithmes de CRC et de polynômes communs sans succès. Il n'y a pas de références ou spécifications disponibles pour cette application.

Voici une autre section de données avec différents CRC à des fins de comparaison.

00    4E00FFFF26C014091600A01030393132  
10    30313131313030393030313230313030  
20    30303131313030393030313230313030  
30    30303131313030393030313230313030  
40    3030FFFF225E343231324F313044**8348**  
50    64000000000000008080808080800000  
60    00000000**72F8**E001EB00130105000E01  

Ma question est la suivante: quelqu'un peut-il identifier l'algorithme? Existe-t-il un moyen de calculer le polynôme du CRC et d'autres facteurs à partir des données et du CRC?

Merci!

Modifier:

Une recherche de mon désassemblage pour le polynôme CRC16 commun 0xA001 a révélé cette fonction:

34F86 ; =============== S U B R O U T I N E =======================================
34F86
34F86
34F86 Possible_Checksum:                    ; CODE XREF: MEM_EXT_4:00034FEEP
34F86                                         ; MEM_EXT_4:0003503AP ...
34F86                 mov     [-r0], r9       ; Move Word
34F88                 mov     r4, r12         ; Move Word
34F8A                 mov     r5, r13         ; Move Word
34F8C                 shr     r4, #14         ; Shift Right
34F8E                 shl     r5, #2          ; Shift Left
34F90                 or      r5, r4          ; Logical OR
34F92                 mov     r4, r12         ; Move Word
34F94                 mov     DPP0, r5        ; Move Word
34F98                 and     r4, #3FFFh      ; Logical AND
34F9C                 movb    rl3, [r4]       ; Move Byte
34F9E                 mov     DPP0, #4        ; Move Word
34FA2                 movbz   r9, rl3         ; Move Byte Zero Extend
34FA4                 mov     r15, #0         ; Move Word
34FA6
34FA6 loc_34FA6:                              ; CODE XREF: MEM_EXT_4:00034FC8j
34FA6                 mov     r4, [r14]       ; Move Word
34FA8                 xor     r4, r9          ; Logical Exclusive OR
34FAA                 and     r4, #1          ; Logical AND
34FAC                 jmpr    cc_Z, loc_34FBA ; Relative Conditional Jump
34FAE                 mov     r4, [r14]       ; Move Word
34FB0                 shr     r4, #1          ; Shift Right
34FB2                 xor     r4, #0A001h     ; Logical Exclusive OR
34FB6                 mov     [r14], r4       ; Move Word
34FB8                 jmpr    cc_UC, loc_34FC0 ; Relative Conditional Jump
34FBA ; ---------------------------------------------------------------------------
34FBA
34FBA loc_34FBA:                              ; CODE XREF: MEM_EXT_4:00034FACj
34FBA                 mov     r4, [r14]       ; Move Word
34FBC                 shr     r4, #1          ; Shift Right
34FBE                 mov     [r14], r4       ; Move Word
34FC0
34FC0 loc_34FC0:                       

Answer 1

Le code que vous avez publié à partir de loc_34FA6 est fondamentalement le suivant:

unsigned short
crc16_update(unsigned short crc, unsigned char nextByte)
{
    crc ^= nextByte;

    for (int i = 0; i < 8; ++i) {
        if (crc & 1)
            crc = (crc >> 1) ^ 0xA001;
        else
            crc = (crc >> 1);
    }

    return crc;
}

Il s'agit d'un CRC-16 avec un polynôme 0xA001. Une fois que vous avez découvert la plage de données pour laquelle le CRC-16 s'applique, vous initialisez le CRC à 0xFFFF et appelez cette fonction pour chaque octet de la séquence. Stockez la valeur de retour et renvoyez-la la prochaine fois. La valeur renvoyée à la fin est votre CRC final.

Je ne suis pas sûr de ce que fait le prologue ...

Answer 2

Plus généralement, une partie du concept de CRC est que lorsque vous calculez le CRC d’un fichier de données, puis que vous ajoutez le CRC à la fin, vous obtenez un fichier dont le CRC est une valeur qui dépend de la longueur du fichier. fichier, mais pas son contenu. (Pour certains algorithmes CRC, cela ne dépend même pas de la longueur du fichier.)

Donc, si vous pensez que l'application que vous essayez de faire du reverse engineering utilise par exemple CRC16, et que vous disposez d'un programme qui calcule CRC16 et que vous avez plusieurs échantillons de la même longueur, calculez simplement le CRC16 de ces fichiers de données. (qui incluent la somme de contrôle). S'il revient chaque fois avec les mêmes données de somme de contrôle (pour des fichiers de même longueur), ils doivent alors contenir une somme de contrôle CRC utilisant la même largeur et le même polynôme.

Par exemple, j’avais déjà eu recours au reverse engineering de fichiers dans lesquels le développeur pensait être malin en modifiant l’algorithme CRC32 en modifiant deux constantes. Je n'avais pas à trouver le code objet qui vérifiait la somme de contrôle, à le désassembler et à le calculer à la dure. Ce simple test a bien fonctionné.