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?)