Calculadora de suma de verificación CRC

Respuestas rápidas

¿Qué es un CRC?

// CRC-16/MODBUS: poly=0x8005, init=0xFFFF, refin/refout=true, xorout=0x0000
// Written in the reflected form, so the polynomial appears bit-reversed as 0xA001.
function crc16Modbus(bytes) {
  let crc = 0xffff;
  for (const byte of bytes) {
    crc ^= byte;
    for (let i = 0; i < 8; i++) {
      crc = crc & 1 ? (crc >>> 1) ^ 0xa001 : crc >>> 1;
    }
  }
  return crc;
}

crc16Modbus([0x01, 0x03, 0x00, 0x00, 0x00, 0x0a]); // 0xCDC5
// On the wire Modbus RTU sends the low byte first: ... 0x0A 0xC5 0xCD

Qué hace esta calculadora

Ejemplos resueltos

123456789

CRC-32/ISO-HDLC = 0xCBF43926, CRC-16/MODBUS = 0x4B37, CRC-8/SMBUS = 0xF4

01 03 00 00 00 0A

CRC-16/MODBUS = 0xCDC5

DEADBEEF

MODBUS = 0xC19B, CCITT-FALSE = 0x4097, XMODEM = 0xC457, KERMIT = 0x1915

123456789 con valor esperado 0x29B1

CRC-16/IBM-3740 (tu manual quizá la llame CRC-16/CCITT-FALSE)

Cómo usar la calculadora de CRC

1. 1

   Elige texto o hexadecimal

   Las tramas de protocolo son casi siempre hexadecimal. Usa texto solo cuando calcules la suma de una cadena literal, como el valor de autocomprobación 123456789.

2. 2

   Pega tus datos

   En modo hexadecimal los separadores se ignoran, así que 01 03 00 00 00 0A, 0x01 0x03 y 010300 00000A se aceptan por igual.

3. 3

   Localiza la variante que necesitas

   La tabla está agrupada por ancho. Los nombres formales vienen del catálogo RevEng, con los alias que probablemente use el manual de tu equipo impresos debajo.

4. 4

   O trabaja al revés

   Si ya tienes una suma de verificación y quieres saber su variante, escríbela en el campo de valor esperado y lee la fila resaltada.

Por qué tu suma de verificación no cuadra

Text mode, input "01 03" -> 5 bytes: 30 31 20 30 33

Hex mode, input "01 03" -> 2 bytes: 01 03

expected 0xC5CD  (bytes read in transmission order)

expected 0xCDC5  (bytes reassembled low-byte-first)

01 03 00 00 00 0A C5 CD    <- trailer included

01 03 00 00 00 0A          <- payload only

spec says: "trailer is a CRC-16"

spec says: "CRC-16/MODBUS, poly 0x8005, init 0xFFFF, refin/refout true"

Cuándo la necesitas

Depurar un enlace Modbus

Un PLC rechaza tus tramas y necesitas saber si el CRC está mal o solo tiene los bytes intercambiados. Calcula el CRC-16/MODBUS y compara los dos órdenes.

Identificar un protocolo sin documentar

Has capturado tráfico con un remolque de dos bytes que parece una suma de verificación. Pasa la carga útil y ese remolque a la búsqueda inversa y mira qué variante lo reclama.

Portar firmware entre cadenas de herramientas

La biblioteca del fabricante y tu propia implementación no coinciden. Comparar ambas contra el valor de autocomprobación del catálogo revela cuál se desvió.

Escribir o revisar una especificación

Poner «CRC-16» en un documento de protocolo garantiza fallos de interoperabilidad. La tabla de parámetros te da los seis valores que de verdad fijan el algoritmo.

Verificar datos almacenados

Los sistemas de archivos, los formatos de archivado y las imágenes de flash llevan campos CRC-32. Recalcular uno te dice si un bloque sobrevivió intacto.

Cómo funciona el CRC

Representación del polinomio

La tabla imprime los polinomios en forma normal (MSB primero): 0x8005 significa x^16 + x^15 + x^2 + 1. Las implementaciones reflejadas suelen mostrar ese mismo polinomio como 0xA001, y la notación de Koopman lo desplaza de otra forma más. Tres notaciones para un mismo polinomio son una fuente habitual de portes fallidos.

El valor inicial

Arrancar el registro en 0xFFFF en lugar de 0x0000 hace que la suma de verificación sea sensible a los bytes cero iniciales. Con un init a cero, anteponer ceros a un mensaje deja el CRC intacto, que es justo la corrupción que un protocolo con tramas necesita detectar.

Reflexión

refin invierte los bits dentro de cada byte de entrada; refout invierte el registro final. El hardware desplaza los bits con el MSB primero mientras que al software orientado a bytes le sale más barato el LSB primero, y las formas reflejadas de los parámetros reconcilian ambos mundos.

XOR final

xorout se aplica en último lugar, y no equivale sin más a un init en el otro extremo. Los bytes cero añadidos al mensaje se detectan en ambos casos. Lo que cambia un xorout distinto de cero es el residuo que obtiene un receptor al pasar el CRC sobre el mensaje y la suma de verificación juntos: con xorout cero ese residuo vale a su vez cero, así que los ceros añadidos después del campo CRC siguen pasando. También hace que el mensaje todo a ceros produzca una suma de verificación distinta de cero.

El valor de autocomprobación

Cada variante catalogada publica su resultado para la cadena ASCII 123456789. Los 63 valores que muestra esta página cuando se carga esa entrada son exactamente esas constantes publicadas, y así es como se prueba el motor de esta página.

Cómo conseguir que el resultado cuadre

Nombra los parámetros, no el algoritmo

En las especificaciones escribe «poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000». «CRC-16/CCITT» ha significado al menos tres cosas distintas.

Comprueba el orden de bytes por separado

Cuando a una suma de verificación le falta un intercambio de bytes para cuadrar, el algoritmo es correcto y lo que falla es el entramado. Trátalos como dos errores distintos.

Valida primero contra el valor de autocomprobación

Antes de depurar tus datos, confirma que tu implementación devuelve el valor del catálogo para 123456789. Separa en segundos un algoritmo roto de una entrada rota.

Deja claro qué bytes quedan cubiertos

La mayoría de las discrepancias vienen de incluir o excluir marcadores de inicio, direcciones o campos de longitud. Decide exactamente qué bytes abarca el CRC y déjalo por escrito.

No uses CRC donde hace falta un MAC

El CRC es lineal y se falsifica sin esfuerzo. Si un adversario pudiera modificar los datos, usa HMAC en su lugar.

Preguntas frecuentes