Kalkulator sumy kontrolnej CRC

Szybkie odpowiedzi

Czym jest 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

Co potrafi ten kalkulator

Przykłady obliczeń

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 z wartością oczekiwaną 0x29B1

CRC-16/IBM-3740 (w instrukcji urządzenia może figurować jako CRC-16/CCITT-FALSE)

Jak korzystać z kalkulatora CRC

1. 1

   Wybór trybu: tekst albo hex

   Ramki protokołów są prawie zawsze szesnastkowe. Tryb tekstowy przydaje się tylko wtedy, gdy sumę kontrolną liczy się z dosłownego ciągu znaków, jak wartość autotestu 123456789.

2. 2

   Wklejenie danych

   W trybie szesnastkowym separatory są ignorowane, więc 01 03 00 00 00 0A, 0x01 0x03 oraz 010300 00000A zostaną przyjęte tak samo.

3. 3

   Odczyt potrzebnego wariantu

   Tabela jest pogrupowana według szerokości. Nazwy formalne pochodzą z katalogu RevEng, a pod nimi widnieją aliasy, które najpewniej występują w instrukcji urządzenia.

4. 4

   Albo droga na odwrót

   Jeżeli suma kontrolna jest już znana, a szukany jest jej wariant, wystarczy wpisać ją w pole wartości oczekiwanej i odczytać podświetlony wiersz.

Dlaczego suma kontrolna się nie zgadza

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"

Kiedy przydaje się kalkulator CRC

Diagnostyka łącza Modbus

Sterownik PLC odrzuca ramki i trzeba ustalić, czy CRC jest błędne, czy tylko ma zamienione bajty. Wystarczy policzyć CRC-16/MODBUS i porównać obie kolejności.

Rozpoznanie nieudokumentowanego protokołu

W przechwyconym ruchu widać dwubajtowe zakończenie ramki, które wygląda na sumę kontrolną. Wystarczy podać payload i to zakończenie do wyszukiwania wstecznego i zobaczyć, który wariant się do niego przyzna.

Przenoszenie firmware'u między toolchainami

Biblioteka producenta i własna implementacja dają różne wyniki. Porównanie obu z wzorcową wartością kontrolną z katalogu pokazuje, która z nich odjechała.

Pisanie i recenzowanie specyfikacji

Napisanie w dokumencie protokołu samego „CRC-16” gwarantuje błędy interoperacyjności. Tabela parametrów podaje sześć wartości, które naprawdę przypinają algorytm.

Weryfikacja zapisanych danych

Systemy plików, formaty archiwów i obrazy pamięci flash niosą pola CRC-32. Przeliczenie takiego pola mówi, czy blok przetrwał w całości.

Jak działa CRC

Zapis wielomianu

Tabela drukuje wielomiany w postaci normalnej (najstarszy bit pierwszy): 0x8005 oznacza x^16 + x^15 + x^2 + 1. Implementacje odwrócone często pokazują ten sam wielomian jako 0xA001, a notacja Koopmana przesuwa go jeszcze inaczej. Trzy notacje na jeden wielomian to częsta przyczyna nieudanych portów.

Wartość początkowa

Wystartowanie rejestru od 0xFFFF zamiast od 0x0000 sprawia, że suma kontrolna jest czuła na wiodące bajty zerowe. Przy zerowej wartości początkowej dopisanie zer na początku wiadomości nie zmienia CRC — a to dokładnie ten rodzaj przekłamania, który protokół ramkowy musi wychwycić.

Odwrócenie bitów

refin odwraca bity wewnątrz każdego bajtu wejściowego, refout odwraca gotowy rejestr. Sprzęt taktuje bity od najstarszego, a oprogramowaniu operującemu na bajtach taniej wychodzi od najmłodszego; odwrócone postacie parametrów godzą oba podejścia.

Końcowy XOR

xorout stosuje się na samym końcu i nie jest to po prostu wartość początkowa przeniesiona na drugi koniec. Bajty zerowe dopisane na końcu wiadomości zostaną wykryte tak czy inaczej. Niezerowy xorout zmienia natomiast resztę, jaką dostaje odbiorca, gdy przepuści przez CRC wiadomość razem z sumą kontrolną: przy xorout równym zero ta reszta sama jest zerem, więc zera dopisane za polem CRC nadal przechodzą. Sprawia też, że wiadomość złożona z samych zer daje niezerową sumę kontrolną.

Wartość kontrolna

Każdy skatalogowany wariant publikuje swój wynik dla ciągu ASCII 123456789. Pokazywane na tej stronie po wczytaniu tego wejścia 63 wartości to dokładnie te opublikowane stałe — i na nich testowany jest silnik tej strony.

Jak uzyskać zgodny wynik

Nazwanie parametrów zamiast algorytmu

W specyfikacjach warto pisać „poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000”. Nazwa „CRC-16/CCITT” oznaczała już co najmniej trzy różne rzeczy.

Osobne sprawdzenie kolejności bajtów

Kiedy do zgodności brakuje jednej zamiany bajtów, algorytm jest poprawny, a błędne jest ramkowanie. Warto traktować to jako dwa różne defekty.

Weryfikacja najpierw wzorcową wartością kontrolną

Zanim zacznie się diagnozować dane, warto potwierdzić, że implementacja zwraca dla 123456789 wartość z katalogu. To w kilka sekund oddziela zepsuty algorytm od zepsutego wejścia.

Jasne określenie zakresu obliczeń

Większość niezgodności bierze się z włączenia albo pominięcia znaczników początku, adresów lub pól długości. Trzeba dokładnie ustalić, które bajty obejmuje CRC, i to zapisać.

Nieużywanie CRC tam, gdzie potrzebny jest MAC

CRC jest liniowe i trywialne do podrobienia. Jeżeli atakujący może zmodyfikować dane, należy sięgnąć po HMAC.

Najczęściej zadawane pytania