CRC-Rechner

Ein CRC (Cyclic Redundancy Check, zyklische Redundanzprüfung) ist eine kurze Prüfsumme fester Größe, die aus einem Datenblock mittels Polynomdivision über einem binären Feld berechnet wird — sie dient dazu, zufällige Datenverfälschungen zu erkennen, nicht um vor Manipulation zu schützen. Dieser Rechner berechnet die Prüfsumme vollständig in deinem Browser mit dem üblichen tabellenbasierten CRC-Algorithmus: Füge Text ein oder lade eine kleine Datei hoch, wähle CRC-32 (das IEEE-802.3-Polynom 0xEDB88320, das von ZIP, PNG und Ethernet verwendet wird), CRC-16/CCITT-FALSE oder CRC-16/MODBUS, und erhalte das Ergebnis sofort in Hexadezimal, Dezimal und Binär. Nichts, was du eingibst, wird jemals an einen Server gesendet.

Was ist dieses Tool?

CRC steht für Cyclic Redundancy Check, einen fehlererkennenden Code, der erstmals 1975 in einem Paper von W. Wesley Peterson und D.T. Brown beschrieben und später in Referenzwerken wie Ross Williams' „A Painless Guide to CRC Error Detection Algorithms" sowie den ITU-T-/ISO-3309-Standards formalisiert wurde. Ein CRC behandelt eine Nachricht als große Binärzahl und dividiert sie durch ein festes Generatorpolynom; der Rest dieser Division ist die Prüfsumme. Da Polynomdivision sowohl in Hardware als auch in Software günstig zu berechnen ist, wurde CRC zur Standard-Fehlerprüfung für Speicher- und Übertragungssysteme.

CRC-32 — genauer die Variante mit dem Polynom 0xEDB88320, einem Anfangswert von 0xFFFFFFFF und einem abschließenden XOR mit 0xFFFFFFFF — ist in IEEE 802.3 (Ethernet) standardisiert und wird als Prüfsumme in ZIP- und gzip-Archiven, PNG-Bilddateien sowie unzähligen Netzwerk- und Speicherprotokollen verwendet. Es ist bei weitem die am häufigsten angefragte CRC-Variante, weshalb sie in diesem Tool als Standardalgorithmus voreingestellt ist. CRC-16/CCITT-FALSE (Polynom 0x1021) und CRC-16/MODBUS (Polynom 0x8005, gespiegelt) sind zwei weit verbreitete 16-Bit-Varianten, die in seriellen Protokollen wie Modbus RTU, XMODEM und diversen Embedded-/Industriekommunikationsstandards vorkommen.

Wichtig ist zu verstehen, was ein CRC nicht ist: kein kryptografischer Hash. CRCs sind schnelle, lineare Funktionen ohne jeglichen Schutz vor gezielter Manipulation — es ist einfach, eine andere Nachricht zu konstruieren, die denselben CRC-Wert ergibt. Sie erkennen zuverlässig die Art von zufälligen Bitfehlern, die durch gestörte Übertragungsleitungen, Festplattenfehler oder abgebrochene Downloads entstehen, bieten aber keinerlei Schutz gegen einen Angreifer, der Daten unbemerkt manipulieren möchte.

Warum sollte man es nutzen?

Du debuggst eine Firmware für ein Modbus-RTU-Gerät, und der Master lehnt deine Frames mit "CRC error" ab — füge die exakten Bytes des Frames hier ein, berechne den erwarteten CRC-16/MODBUS und vergleiche Byte für Byte mit dem, was dein Code erzeugt.
Eine ZIP-Datei, die über eine langsame Verbindung heruntergeladen wurde, meldet beim Entpacken einen beschädigten Eintrag — berechne den CRC-32 der extrahierten Datei neu und vergleiche ihn mit dem Wert im lokalen ZIP-Header, um zu klären, ob das Problem bei der Übertragung oder der Originaldatei lag.
Du schreibst deine eigene CRC-32-Implementierung in C oder Python für ein Embedded-Projekt und brauchst einen verlässlichen Referenzwert — nutze den Standard-Testvektor "123456789" (der immer 0xCBF43926 ergibt), um zu prüfen, ob dein Code das richtige Ergebnis liefert, bevor du ihn einbaust.
Ein Kollege schickt dir ein PNG, das Photoshop als beschädigt meldet, und du willst klären, ob es ein echtes CRC-Problem im Chunk ist oder nur eine falsche Warnung der Software, bevor du Zeit mit erneutem Herunterladen verschwendest.
Du implementierst XMODEM für Dateiübertragung über die serielle Schnittstelle und musst prüfen, ob deine CRC-16/CCITT-FALSE-Berechnung exakt dem entspricht, was das Protokoll erwartet, byteweise, ohne Bitspiegelung.
Du musst einen CRC berechnen, ohne ein Kommandozeilen-Tool auf einer eingeschränkten Maschine zu installieren — alles läuft im Browser, ohne die Datei an einen externen Server hochzuladen.

Anleitung

Wähle den Tab „Text" und füge deine Eingabe ein oder tippe sie ein, oder wechsle zum Tab „Datei" und wähle eine Datei von deinem Gerät.
Wähle den CRC-Algorithmus: CRC-32 (IEEE 802.3, Standard und am häufigsten verwendet), CRC-16/CCITT-FALSE oder CRC-16/MODBUS.
Die Prüfsumme wird automatisch aktualisiert und in Hexadezimal, Dezimal und Binär angezeigt.
Klicke auf „Kopieren" neben einem Ergebnis, um es in die Zwischenablage zu kopieren.

Beispiel

Eingabe

123456789

Ausgabe

0xCBF43926 (3421780262)

Dies ist der standardmäßig veröffentlichte CRC-32-Testvektor (IEEE 802.3): Der CRC-32 der ASCII-Zeichenfolge „123456789" ist immer 0xCBF43926. Du kannst die Ausgabe dieses Tools mit dieser exakten Zeichenfolge gegen jede andere korrekte CRC-32-Implementierung prüfen.

CRC vs. kryptografische Hashes (MD5 / SHA)

Sowohl CRCs als auch kryptografische Hashes reduzieren Daten auf einen Fingerabdruck fester Größe, lösen aber unterschiedliche Probleme und sind nicht austauschbar.

Eigenschaft	CRC (z. B. CRC-32)	MD5 / SHA-256
Zweck	Zufällige Beschädigung erkennen	Absichtliche Manipulation erkennen / Integrität prüfen
Geschwindigkeit	Extrem schnell, einfache Hard-/Software	Langsamer, mehr Berechnung pro Byte
Kollisionsresistenz	Keine — absichtlich trivial konstruierbar	Rechnerisch unmöglich konzipiert (SHA-256) bzw. bei MD5 gebrochen
Typische Größe	16 oder 32 Bit	128 Bit (MD5) oder 256 Bit (SHA-256)
Typische Verwendung	ZIP/gzip, PNG, Ethernet, Modbus, Speicher	Dateiintegritätsprüfungen, digitale Signaturen, Passwortspeicherung (mit Salting)

Häufige Fehler bei der CRC-Implementierung

Die meisten "mein CRC stimmt nicht überein"-Fälle sind keine Logikfehler, sondern falsch gewählte Parameter. Das sind die häufigsten beim Debuggen einer eigenen Implementierung.

Das Polynom in normaler Form (0x04C11DB7) statt der gespiegelten Form (0xEDB88320) zu verwenden, die der Standard-CRC-32 bei bitweiser Verarbeitung ab dem LSB benötigt.
Das abschließende XOR mit 0xFFFFFFFF bei CRC-32 zu vergessen — ohne es erhältst du den "rohen" CRC vor dem von IEEE 802.3 geforderten Nachbearbeitungsschritt.
CRC-16/CCITT-FALSE (ohne Spiegelung, Anfangswert 0xFFFF) mit anderen CCITT-Varianten zu verwechseln, die Ein- und Ausgabe spiegeln oder einen Anfangswert von 0x0000 verwenden — das sind vier unterschiedliche Algorithmen mit demselben Polynom 0x1021.
Den CRC über Text in einem Editor mit anderer Kodierung als erwartet zu berechnen (UTF-8 mit BOM statt reinem ASCII zum Beispiel), was die tatsächlichen Eingabe-Bytes und damit das Ergebnis verändert.

Häufig gestellte Fragen

Wofür wird ein CRC verwendet?

Ein CRC (zyklische Redundanzprüfung) ist ein Fehlererkennungscode, der an einen Datenblock angehängt wird, damit der Empfänger ihn neu berechnen und bestätigen kann, dass die Daten bei Speicherung oder Übertragung nicht versehentlich beschädigt wurden. Er ist fest in Standards wie IEEE-802.3-Ethernet-Framing, die Formate ZIP und gzip, PNG-Bilder sowie viele serielle und industrielle Protokolle wie Modbus integriert.

Ist CRC-32 dasselbe wie MD5 oder SHA-256?

Nein. CRC-32 ist eine schnelle, lineare Prüfsumme zur Fehlererkennung ohne Sicherheitseigenschaften — es ist trivial, absichtlich zwei unterschiedliche Eingaben mit demselben CRC-32-Wert zu konstruieren. MD5 und SHA-256 sind kryptografische Hashfunktionen, die genau das rechnerisch unmöglich machen sollen. Verwende CRC-32, um zufällige Beschädigungen zu erkennen (eine zerkratzte Festplatte, ein verlorenes Netzwerkpaket); nutze einen kryptografischen Hash aus unserem [Hash-Generator](/hash-generator) oder [MD5-Generator](/md5-generator), wenn du Manipulationssicherheit oder Integritätsgarantien gegen einen Angreifer benötigst.

Welche CRC-32-Variante verwendet dieses Tool?

Die Variante IEEE 802.3 / ZIP / PNG: Polynom 0xEDB88320 (die bitgespiegelte Form von 0x04C11DB7), Anfangswert 0xFFFFFFFF, Eingabe und Ausgabe gespiegelt, sowie ein abschließendes XOR mit 0xFFFFFFFF. Dies ist die Variante, die von Ethernet, ZIP, gzip und PNG verwendet wird und die für die ASCII-Zeichenfolge „123456789" 0xCBF43926 ergibt — der standardmäßig veröffentlichte Testvektor zur Verifizierung einer CRC-32-Implementierung.

Was ist der Unterschied zwischen CRC-16/CCITT-FALSE und CRC-16/MODBUS?

Beide sind 16-Bit-CRCs, aber mit unterschiedlichen Polynomen und Parametern. CRC-16/CCITT-FALSE verwendet das Polynom 0x1021 mit einem Anfangswert von 0xFFFF und ohne Bitspiegelung; es ist üblich in Protokollen wie XMODEM und diversen Telekommunikationsstandards. CRC-16/MODBUS verwendet das Polynom 0x8005 (gespiegelt als 0xA001), ebenfalls mit einem Anfangswert von 0xFFFF, aber mit gespiegelter Eingabe und Ausgabe — es ist die Prüfsumme, die Modbus RTU an jeden seriellen Frame anhängt. Sie liefern für dieselbe Eingabe unterschiedliche Ergebnisse, daher ist es wichtig, die vom Zielprotokoll tatsächlich vorgeschriebene Variante zu wählen.

Kann ich den CRC einer Datei berechnen, nicht nur von Text?

Ja. Wechsle zum Tab „Datei" und wähle eine Datei von deinem Gerät — das Tool liest deren Rohbytes lokal im Browser (über die File API) und berechnet die Prüfsumme genau über diese Bytes, so wie es auch ein ZIP- oder PNG-Reader tun würde.

Werden meine Daten an einen Server hochgeladen?

Nein. Sowohl die Text- als auch die Dateiberechnung laufen vollständig clientseitig in JavaScript mit einem standardmäßigen tabellenbasierten CRC-Algorithmus. Nichts, was du eingibst oder hochlädst, verlässt jemals deinen Browser.

Warum liefert meine Python-Implementierung von CRC-32 ein anderes Ergebnis als dieser Rechner?

Fast immer liegt es an den Parametern, nicht am Algorithmus selbst: Prüfe, ob du das gespiegelte Polynom 0xEDB88320 verwendest (nicht die normale Form 0x04C11DB7), einen Anfangswert von 0xFFFFFFFF, gespiegelte Ein- und Ausgabe sowie ein abschließendes XOR mit 0xFFFFFFFF. Schon ein einziger falscher Parameter — etwa das fehlende abschließende XOR — führt zu einem völlig anderen Ergebnis, selbst wenn der Rest des Algorithmus korrekt ist.

Kann ich damit die Integrität eines kompletten Modbus-RTU-Frames prüfen, inklusive Adresse und Funktion?

Ja — füge die Rohbytes des Frames (Slave-Adresse, Funktionscode und Daten, ohne den abschließenden CRC) im Text- oder Datei-Tab ein und vergleiche den berechneten CRC-16/MODBUS mit den letzten beiden Bytes des Original-Frames, die Modbus in Little-Endian-Reihenfolge sendet.

Was passiert, wenn zwei unterschiedliche Dateien denselben CRC-32 ergeben?

Das ist bei einem 32-Bit-CRC möglich und erwartbar, mit einer Wahrscheinlichkeit von etwa 1 zu 4 Milliarden bei zufälligen unterschiedlichen Dateien. Da CRC nicht auf Kollisionsresistenz ausgelegt ist, sollte er nicht als Integritätsnachweis gegen absichtliche Manipulation verwendet werden — dafür braucht es einen kryptografischen Hash wie SHA-256.

Unterstützt der Rechner sehr große Dateien, etwa ein Disk-Image?

Die praktische Grenze hängt vom verfügbaren Arbeitsspeicher deines Browsers ab, da die gesamte Datei vor der CRC-Berechnung in den Speicher geladen wird. Für Dateien im Megabyte-Bereich funktioniert es gut, für mehrere Gigabyte große Disk-Images empfiehlt sich aber ein Kommandozeilen-Tool wie crc32 oder python -c mit zlib.