CRC-calculator: checksum berekenen en herkennen

Snelle antwoorden

Wat is een 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

Wat deze calculator doet

Uitgewerkte voorbeelden

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 met verwachte waarde 0x29B1

CRC-16/IBM-3740 (in je handleiding waarschijnlijk CRC-16/CCITT-FALSE)

Zo gebruik je de CRC-calculator

1. 1

   Kies tekst of hex

   Protocolframes zijn vrijwel altijd hex. Gebruik tekst alleen als je de checksum van een letterlijke string berekent, zoals de zelftestwaarde 123456789.

2. 2

   Plak je data

   In hex-modus worden scheidingstekens genegeerd, dus 01 03 00 00 00 0A, 0x01 0x03 en 010300 00000A worden alle drie geaccepteerd.

3. 3

   Lees de variant af die je nodig hebt

   De tabel is gegroepeerd op breedte. De formele namen komen uit de RevEng-catalogus, met daaronder de aliassen die je apparaathandleiding waarschijnlijk gebruikt.

4. 4

   Of werk andersom

   Heb je al een checksum en wil je weten van welke variant die is, typ hem dan in het veld voor de verwachte waarde en lees de opgelichte rij af.

Waarom je checksum niet klopt

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"

Wanneer je dit nodig hebt

Een Modbus-verbinding debuggen

Een PLC wijst je frames af en je wilt weten of de CRC fout is of alleen een omgekeerde bytevolgorde heeft. Bereken CRC-16/MODBUS en vergelijk beide volgordes.

Een ongedocumenteerd protocol identificeren

Je hebt verkeer opgenomen met een staart van twee bytes die op een checksum lijkt. Voer de payload en die staart in bij het terugzoeken en kijk welke variant hem opeist.

Firmware overzetten tussen toolchains

Een bibliotheek van de leverancier en je eigen implementatie zijn het oneens. Beide vergelijken met de checkwaarde uit de catalogus laat zien welke van de twee is afgedreven.

Een specificatie schrijven of nakijken

Alleen “CRC-16” noemen in een protocoldocument garandeert fouten in de koppeling. De parametertabel geeft je de zes waarden die het algoritme werkelijk vastleggen.

Opgeslagen data verifiëren

Bestandssystemen, archiefformaten en flash-images dragen CRC-32-velden. Er één opnieuw berekenen vertelt je of een blok intact gebleven is.

Zo werkt CRC

Notatie van de polynoom

De tabel drukt polynomen af in de normale vorm (MSB eerst): 0x8005 betekent x^16 + x^15 + x^2 + 1. Gespiegelde implementaties tonen dezelfde polynoom vaak als 0xA001, en de Koopman-notatie schuift hem nog weer anders. Drie notaties voor één polynoom is een klassieke oorzaak van mislukte overzettingen.

De startwaarde

Het register op 0xFFFF laten beginnen in plaats van op 0x0000 maakt de checksum gevoelig voor nulbytes aan het begin. Met een startwaarde van nul verandert de CRC niet als je nullen voor het bericht plakt — en precies die corruptie moet een protocol met frames opvangen.

Spiegeling

refin keert de bits binnen elke invoerbyte om, refout keert het eindregister om. Hardware schuift bits MSB-first naar buiten, terwijl byte-georiënteerde software LSB-first goedkoper vindt, en de gespiegelde parametervormen brengen die twee bij elkaar.

De laatste XOR

xorout wordt als laatste toegepast, en het is niet simpelweg een startwaarde aan de andere kant. Nulbytes die achter het bericht worden geplakt, worden in beide gevallen opgemerkt. Wat een xorout ongelijk aan nul wél verandert, is het residu dat een ontvanger krijgt als hij de CRC over bericht en checksum samen laat lopen: bij xorout nul is dat residu zelf nul, zodat nullen achter het CRC-veld nog steeds doorkomen. Het zorgt er ook voor dat een bericht van alleen nullen een checksum ongelijk aan nul oplevert.

De checkwaarde

Elke variant in de catalogus publiceert zijn resultaat voor de ASCII-string 123456789. De 63 waarden die deze pagina toont zodra die invoer geladen is, zijn precies die gepubliceerde constanten, en daarmee wordt de engine achter deze pagina getest.

Zo krijg je een kloppend resultaat

Noem de parameters, niet het algoritme

Zet “poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000” in je specificatie. “CRC-16/CCITT” heeft minstens drie verschillende dingen betekend.

Controleer de bytevolgorde apart

Zit een checksum één byte-omkering van kloppen af, dan is het algoritme goed en deugt de framing niet. Behandel dat als twee verschillende fouten.

Toets eerst tegen de checkwaarde

Voordat je je data gaat uitpluizen: controleer of je implementatie voor 123456789 de waarde uit de catalogus teruggeeft. Dat scheidt binnen enkele seconden een kapot algoritme van een verkeerde invoer.

Wees expliciet over wat er meetelt

De meeste afwijkingen komen doordat startmarkeringen, adressen of lengtevelden wel of juist niet worden meegerekend. Bepaal precies welke bytes de CRC bestrijkt en schrijf dat op.

Gebruik geen CRC waar een MAC nodig is

CRC is lineair en triviaal te vervalsen. Kan een tegenstander de data aanpassen, gebruik dan HMAC.

Veelgestelde vragen