redundancia - Tratando de aplicar ingeniería inversa a una suma de comprobación de paquete/CRC/hash

cyclic redundancy check

Question

Tengo un dispositivo electrónico viejo, ya no fabricado, con un puerto serie. Estoy intentando realizar una ingeniería inversa del paquete de datos CRC / suma de comprobación / hash utilizado en este dispositivo.

¿Alguien con ojos penetrantes, habilidades matemáticas agudas que podrían ser capaces de descifrar esto?

Esto es lo que sé hasta ahora ...

• Cada paquete siempre tiene 21 bytes. 19 bytes de datos más 2 bytes al final para CRC / suma de comprobación / hash
• Por lo tanto, aquí no hay bytes de longitud o encabezado. Los 19 bytes están involucrados en el cálculo hash.
• Tengo la capacidad de generar ciertas cantidades de paquetes de datos con el dispositivo
• Lo primero que pienso es que los paquetes de datos tienen algún tipo de cálculo CRC-16
• Así que seguí sugerencias www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html en www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

• Verificó que mis muestras de paquetes de datos observaran el "principio de superposición" descrito en el enlace web anterior. Esto indica que tienen una relación XOR matemática.

• Comenzó a sentirse bien ... pero luego se quedó perplejo después de eso. No se ha podido determinar un polinomio CRC-16. Existe una gran posibilidad de que estos hashes de paquetes de datos no estén relacionados con el CRC, sino más bien con algún esquema de elaboración casera.

• Lea a través de "UNA GUÍA INOLVIDABLE DE ALGORITMOS DE DETECCIÓN DE ERRORES DEL CRC" por Ross N. Williams

• Ver http://www.ross.net/crc/download/crc_v3.txt
• También se utiliza la aplicación: CRC Reveng - una aplicación de ingeniería inversa
• Ver reveng.sourceforge.net
• Todavía no hay suerte ...

• Lamentablemente, no tengo acceso a ninguno de los dispositivos fuente / código binario

• También ejecutó pruebas para ver si se usaban otros hashes como la suma de comprobación de Fletcher

Aquí hay varias muestras de mis paquetes de datos.

0x47366B2EE00000000000751CEB5F3469543B585E2D
0x47366B2ED00000000000751CEB5F3469543B582A2C
0x47366B2EC80000000000751CEB5F3469543B580B2B
0x47366B2EC40000000000751CEB5F3469543B58BB2A
0x47366B2EC20040000000751CEB5F3469543B58DFE7
0x47366B2EC10000000000751CEB5F3469543B58A328
0x47366B2EC08000000000751CEB5F3469543B584127
0x47366B2EC04000000000751CEB5F3469543B588126
0x47366B2EC02000000000751CEB5F3469543B580525
0x47366B2EC01000000000751CEB5F3469543B580124

Tenga en cuenta lo siguiente sobre estos paquetes de datos ...

• CRC se encuentra en los últimos 2 bytes del paquete de datos.
• Si miro los bits en un analizador lógico, he expresado los bytes como MSB-first
• Por lo tanto, el paquete 0x47366B2EE00000000000751CEB5F3469543B585E2D se ve en binario como:
• 01000111 ................................................. ............ 00101101

• (0x47) ............................................... ...................... (0x2D)

• No sé si mi sistema es grande o poco endian, pero los bytes bastante seguros son LSB-first

• Tenga en cuenta que para las 10 muestras de paquete de datos anteriores, cada paquete difiere en 1 bit de desplazamiento a través de 10 posiciones de bit. Excepto por el quinto paquete, donde tuve que cambiar 2 bits

• Ver bytes de datos que siguen a la porción 0x47366B2E del paquete de datos.

• El único patrón que veo que surgió son los últimos decrementos de byte en uno (2D, 2C, ...) en cada paquete de datos. (Excepto el 5º paquete, donde tuve que cambiar 2 bits)

• Este último byte NO es una especie de número de secuencia, ya que puedo generarlos en cualquier momento con el mismo valor.
• Pero posiblemente da una pista sobre el hash matemático utilizado.

¡Cualquier ayuda es apreciada!

Answer 1

He ejecutado algunos paquetes a través de una aplicación llamada "SRP16", que busca y muestra los parámetros de CRC16 Rocksoft. La salida sigue:

===== Result parameter sets =====
CRC=$2a2c Poly=$2817 init=$3141 xorout=$ffff refin=true refout=true
*** Second data set verified
CRC=$2a2c Poly=$2817 init=$70f4 xorout=$0000 refin=true refout=true
*** Second data set verified
CRC=$2a2c Poly=$2817 init=$9bf3 xorout=$0000 refin=false refout=true
*** Second data set verified
CRC=$2a2c Poly=$2817 init=$da46 xorout=$ffff refin=false refout=true
*** Second data set verified
CRC=$2a2c Poly=$4777 init=$1263 xorout=$0000 refin=false refout=true
*** Second data set verified
CRC=$2a2c Poly=$4777 init=$6f2d xorout=$0000 refin=true refout=true
*** Second data set verified
CRC=$2a2c Poly=$4777 init=$a127 xorout=$ffff refin=true refout=true
*** Second data set verified
CRC=$2a2c Poly=$4777 init=$dc69 xorout=$ffff refin=false refout=true
*** Second data set verified
CRC=$2c2a Poly=$7354 init=$1dab xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$7354 init=$417e xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$7354 init=$a401 xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$7354 init=$f8d4 xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$8a23 init=$0fa0 xorout=$0000 refin=false refout=true
*** Second data set verified
CRC=$2c2a Poly=$8a23 init=$3f6a xorout=$ffff refin=false refout=true
*** Second data set verified
CRC=$2c2a Poly=$8a23 init=$cc70 xorout=$0000 refin=true refout=true
*** Second data set verified
CRC=$2c2a Poly=$8a23 init=$fcba xorout=$ffff refin=true refout=true
*** Second data set verified
CRC=$2c2a Poly=$9656 init=$3460 xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$9656 init=$ff4b xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$a644 init=$195b xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$a644 init=$70ca xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$a644 init=$a3e8 xorout=$0000 refin=false refout=true
*** Third data set verified
CRC=$2c2a Poly=$a644 init=$ca79 xorout=$0000 refin=false refout=true
*** Third data set verified
===== done =====

Tal vez intentar esto y ver si funcionan para usted?

¡Buena suerte!

Answer 2

SI sigue la relación XOR simple, (suma de verificación (A ^ B) == suma de comprobación (A) ^ suma de comprobación (B)) ¡entonces hay una solución de fuerza bruta simple!

Ilustración. Supongamos que tiene un valor de 1 byte con una suma de comprobación de K bits, donde K realmente no importa, por lo que simplemente representamos las sumas de comprobación como c (i).

Paso 1. Experimento: observe la suma de comprobación c (-1) del paquete de todos los ceros.

0b0000000 => c(-1)

Paso 2. Experimento: observe las sumas de comprobación c (i) de todas las secuencias binarias con un solo 1 en ellas en la posición i

0b00000001 => c(0)
0b00000010 => c(1)
0b00000100 => c(2)
0b00001000 => c(3)
0b00010000 => c(4)
0b00100000 => c(5)
0b01000000 => c(6)
0b10000000 => c(7)

Los valores que observó las sumas de comprobación forman una base lineal para GF (2), y la relación XOR ahora le permite calcular cualquier suma de comprobación.

Ahora puede calcular sumas de comprobación agregando las sumas de comprobación para cada posición de bit con un 1, por ejemplo, suponga que desea la suma de comprobación de 0XF3 que en binario es 0b11110011. Ya que

0b11110011 = (0) + 0x80 + 0x40 + 0x20 + 0x10 + 0x02 + 0x01

luego por relación XOR,

checksum(0b11110011) = c(7) + c(6) + c(5) + c(4) + c(1) + c(0) + c(-1)

es decir, por cada bit que salga, simplemente acumule XOR la ​​suma de comprobación conocida para ese bit.

Si hace este ejercicio y escribe experimentalmente todas las 152 sumas de comprobación de los vectores de base, es posible que también encuentre en el proceso un patrón simple que explica cómo las sumas de comprobación provienen de los vectores de base. :) Si es así, sería bueno publicar eso aquí! (¿Y quizás nos diga qué estamos invirtiendo?)