Calcolatore di Checksum CRC

Risposte rapide

Che cos'è 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

Che cosa fa questo calcolatore

Esempi svolti

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 valore atteso 0x29B1

CRC-16/IBM-3740 (il tuo manuale potrebbe chiamarlo CRC-16/CCITT-FALSE)

Come si usa il calcolatore CRC

1. 1

   Scegli testo o esadecimale

   Le trame di protocollo sono quasi sempre esadecimali. Usa il testo solo quando stai calcolando il checksum di una stringa letterale, come il valore di autotest 123456789.

2. 2

   Incolla i tuoi dati

   In modalità esadecimale i separatori vengono ignorati, quindi 01 03 00 00 00 0A, 0x01 0x03 e 010300 00000A sono tutti accettati.

3. 3

   Leggi la variante che ti serve

   La tabella è raggruppata per larghezza. I nomi formali vengono dal catalogo RevEng, con sotto gli alias che con ogni probabilità userà il manuale del tuo dispositivo.

4. 4

   Oppure procedi a ritroso

   Se hai già un checksum e vuoi sapere di quale variante è, scrivilo nel campo del valore atteso e leggi la riga evidenziata.

Perché il tuo checksum non torna

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"

Quando serve

Diagnosticare un collegamento Modbus

Un PLC rifiuta le tue trame e devi capire se il CRC è sbagliato o soltanto con i byte scambiati. Calcola il CRC-16/MODBUS e confronta entrambi gli ordinamenti.

Identificare un protocollo non documentato

Hai catturato del traffico con una coda di due byte che sembra un checksum. Passa il payload e la coda alla ricerca inversa e guarda quale variante se la prende.

Portare firmware tra toolchain diverse

La libreria del fornitore e la tua implementazione non concordano. Confrontarle entrambe con il valore di verifica del catalogo mostra quale delle due è andata alla deriva.

Scrivere o revisionare una specifica

Scrivere «CRC-16» in un documento di protocollo garantisce bug di interoperabilità. La tabella dei parametri ti dà i sei valori che inchiodano davvero l'algoritmo.

Verificare dati memorizzati

Filesystem, formati di archivio e immagini flash portano campi CRC-32. Ricalcolarne uno ti dice se un blocco è arrivato intatto.

Come funziona il CRC

Rappresentazione del polinomio

La tabella stampa i polinomi in forma normale (MSB per primo): 0x8005 significa x^16 + x^15 + x^2 + 1. Le implementazioni riflesse mostrano spesso lo stesso polinomio come 0xA001, e la notazione di Koopman lo trasla ancora diversamente. Tre notazioni per un solo polinomio sono una causa ricorrente di porting falliti.

Il valore iniziale

Far partire il registro da 0xFFFF invece che da 0x0000 rende il checksum sensibile ai byte zero iniziali. Con init a zero, anteporre degli zeri a un messaggio lascia il CRC invariato — ed è esattamente la corruzione che un protocollo a trame deve intercettare.

Riflessione

refin inverte i bit dentro ogni byte in ingresso, refout inverte il registro finale. L'hardware fa scorrere i bit con l'MSB per primo, mentre il software orientato ai byte trova più economico l'LSB per primo, e le forme riflesse dei parametri conciliano i due mondi.

XOR finale

xorout viene applicato per ultimo, e non è semplicemente un init messo all'altro capo. I byte zero aggiunti in coda al messaggio vengono rilevati in entrambi i casi. Quello che un xorout diverso da zero cambia è il residuo che ottiene un ricevitore quando fa passare il CRC su messaggio e checksum insieme: con xorout a zero quel residuo è a sua volta zero, così gli zeri aggiunti dopo il campo CRC passano ancora. Fa anche sì che il messaggio tutto zeri produca un checksum diverso da zero.

Il valore di verifica

Ogni variante catalogata pubblica il proprio risultato per la stringa ASCII 123456789. I 63 valori mostrati in questa pagina quando si carica quell'input sono esattamente quelle costanti pubblicate, ed è così che il motore di questa pagina viene testato.

Come far tornare il risultato

Nomina i parametri, non l'algoritmo

Nelle specifiche scrivi «poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000». «CRC-16/CCITT» ha voluto dire almeno tre cose diverse.

Verifica l'ordine dei byte a parte

Quando a un checksum manca solo uno scambio di byte per tornare, l'algoritmo è giusto e la trama è sbagliata. Trattali come due bug distinti.

Valida prima contro il valore di verifica

Prima di indagare sui tuoi dati, conferma che la tua implementazione restituisca il valore del catalogo per 123456789. In pochi secondi separa un algoritmo rotto da un input rotto.

Sii esplicito su che cosa viene coperto

La maggior parte delle discrepanze nasce dall'includere o escludere marcatori di inizio, indirizzi o campi di lunghezza. Decidi con precisione quali byte copre il CRC e mettilo per iscritto.

Non usare il CRC dove serve un MAC

Il CRC è lineare e falsificabile senza sforzo. Se un avversario potesse modificare i dati, usa invece HMAC.

Domande frequenti