[gelöst] CRC-Checksum berechnen [==> Problem lag an Big-Endian vs. Little-Endian]

Liebe Community

ich brauche für eine Serielle Verbindung eine CRC-Checksum zu berechnen, für die ich nach der Dokumentation folgende Vorgabe habe:

Vorweg: Der Aufbau eines Kommandos sieht wie folgt aus:
DLE | STX | <Nachricht> | DLE | ETX | CRC
wobei: DLE = 10, STX = 02, ETX = 03

Die CRC-Prüfsumme wird nach CCITT (x^16+x12+x^5+1) mit dem Initialwert 0 über die reine Nachricht (nach dem DLE STX) gebildet. [Die DLE Verdopplung in der <Nachricht> wird hierbei nicht berücksichtigt,]* aber das Endezeichen ETX ist im CRC enthalten!
Beispiel:

  
10 02 80 00 00 10 03  
      80 00 00    03   => CRC = 1FF5  
  

*DLE-Verdopplung wird eingesetzt wenn 0x10 innerhalb der Nachricht erscheint, aber kein DLE ist - es wird sozusagen escaped, sollte im Beispiel aber nicht weiter relevant sein.

<Nachricht> ist also 80 00 00.
Mit dem ETX am Schluss berechne ich die CRC-Checksum also mit der zweiten Zeile im obigen Beispiel.

Wenn ich das wie auf Wikipedia beschrieben berechne, erhalte ich allerdings CRC=ED5B. Unter Einsatz dieses Algorithmus (mit einigen Anpassungen der Datentypen (ushort => uint) und des Polynoms (69665)) bekomme ich das gleiche Ergebnis.

Wenn ich das Kommando mit "meiner" Checksum übertrage, bekomme ich allerdings eine Fehler-Antwort vom Gerät. Mit der Checksum des Beispiels nicht - klar.

Allerdings bin ich mit meinem Latein am Ende. Kann mir jemand sagen wo mein Problem sein könnte?

Bedankt!

DiscMaster

Ich habe das Problem lösen können.

Generell hilfreich: On-line CRC calculation and free library

Ich habe die ganze Zeit schweigend angenommen, dass ich mit CCITT XModem richtig fahre. Zufällig habe ich gemerkt, dass ich (offenbar) mit CCITT Kermit korrekt gewesen wäre. Das findet sich im o.g. Link.

(Fürs Verständnis: In der vorher erwähnten Dokumentation heißt es das die beiden CRC-Oktette vertauscht werden, sprich wenn CRC=1FF5 ist, dann wird F51F übertragen. Und genau das findet sich, wenn man auf o.g. Link bei CCITT Kermit nachsieht)

Gruß

DiscMaster

Ich möchte ergänzen das eine wirklich performance-intensive CRC32 Checksumme meistens garnicht zwingend notwendig ist. Ein 16byte[] MD5 Hash genügt dafür üblicherweise. Der Security.Cryptography.MD5CryptoServiceProvider(ComputeHash) kann dies sehr viel effizienter innerhalb <Millisekunde lösen. Damit lassen sich Dateien auf dem FileSystem eben so gut vergleichen wie anyonyme byte[] arrays oder memory streams.

(Der MD5 Hash ist mit dem Ergebniss von CRC32 nicht kompatibel. Ferner ist der MD5 Hash anfälliger für Manipulationen, bzw. für Vergleichswerte mit dem Ergebniss, die ist in nicht-sicherheitskritischen Szenarien(Hash-Salt Vergleich) allerdings kaum von Bedeutung das dieses Problem eher theoretisch als praktisch existiert(ähnlich wie Guids, sie sind nicht wirklich sicher aber sicher genug, bei einer Wahrscheinlichekeit von 1 zu irgendwas (vergessen zu wieviel) Billionen Möglichkeiten, das kennen wir vor ja schon von RSA)

Sebastian, das kommt immer drauf an was man vor hat.
Möchte man Downloads mit sicheren Checksummen versehen führt kein Weg an SHA1 vorbei. Geht es nur um die Übertragung einzelner Chunks, dann reicht MD5.

Hallo zusammen,

wenn wir schon dabei sind, dann kommt es darauf an, was man unter Sicherheit versteht. Geht es um reine Übertragungssicherheit oder um Sicherheit gegen Angriffe? Das wurde unter anderem bereits in Wie Datenintegrität [bezüglich Übertragungsfehlern] sicherstellen ? (Prüfsumme, Hash) besprochen. Insofern brauchen wir das hier nicht noch mal im Detail aufzurollen.

herbivore