CRC oder andere Checksumme

[Dieter G. (docemmet)]

Hallo ich brauche Unterstützung bei der Suche zur Berechnung der 
Checksumme.
Es handelt sich um Can-Bus Befehle von einem BMW. Ich habe zur 
Berechnung der Checksumme schon einiges probiert, jedoch ohne Erfolg.

Hier eine par Beispiel Befehle in Dezimal:

143,8, 208,240, 251,124,82,0,19,16
143,8, 141,241, 251,124,82,0,19,16
143,8, 106,242, 251,124,82,0,19,16
143,8,  55,243, 251,124,82,0,19,16
143,8, 185,244, 251,124,82,0,19,16
143,8, 228,245, 251,124,82,0,19,16
143,8,   3,246, 251,124,82,0,19,16
143,8,  94,247, 251,124,82,0,19,16
143,8,   2,248, 251,124,82,0,19,16
143,8,  95,249, 251,124,82,0,19,16
143,8, 184,250, 251,124,82,0,19,16
143,8, 229,251, 251,124,82,0,19,16
143,8, 107,252, 251,124,82,0,19,16
143,8,  54,253, 251,124,82,0,19,16
143,8, 209,254, 251,124,82,0,19,16

Oder in Hex:

8F 08  D0 F0  FB 7C 52 00 13 10
8F 08  8D F1  FB 7C 52 00 13 10
8F 08  6A F2  FB 7C 52 00 13 10
8F 08  37 F3  FB 7C 52 00 13 10
8F 08  B9 F4  FB 7C 52 00 13 10
8F 08  E4 F5  FB 7C 52 00 13 10
8F 08  03 F6  FB 7C 52 00 13 10
8F 08  5E F7  FB 7C 52 00 13 10
8F 08  02 F8  FB 7C 52 00 13 10
8F 08  5F F9  FB 7C 52 00 13 10
8F 08  B8 FA  FB 7C 52 00 13 10
8F 08  E5 FB  FB 7C 52 00 13 10
8F 08  6B FC  FB 7C 52 00 13 10
8F 08  36 FD  FB 7C 52 00 13 10
8F 08  D1 FE  FB 7C 52 00 13 10

Aufbau:
Zahl   1 = ID (Möglich 0 bis 2047)
Zahl   2 = Anzahl der Daten- Byte
Zahl   3 = Checksumme  (CRC8, CRCITT oder ???)
Zahl   4 = Durchlaufende Nummer 240 bis 254 oder (F0 bis FE)
Zahlen 5 bis 10 = Daten (6 Byte)

Nach meiner Einschätzung müsst die Checksumme aus den Zahlen von 
Position 4 bis 10 berechnet werden, da die erste Stelle kein Byte ist 
und die zweite Stelle nur die Anzahl der Daten Byte angibt.

Vieleicht kennt ja jemand diese Art von Befehlen, Datenübertragung und 
kann wir bei der Lösung behilflich sein.

Vielen Danke für die Antworten

lg

[Klaus (Gast)]

Ja, so was. Da sollte doch tatsächlich jemand mal das CAN-Protokoll 
irgendwie aufschreiben. Irgendwann wird sicherlich der Gänsekiel 
erfunden. Solange musst Du halt noch warten.

[Disco (Gast)]

Also die ersten 2 Zahlen nicht im CRC zu haben währe doch Quatsch. Die 
sind doch genauso wichtig. Wenn sie das nicht währen braucht man sie ja 
nicht übertragen.

[Disco (Gast)]

Ups. Die sind ja schon durch die 12 bit CRC vom Can abgesichert. 
Genauso wie die anderen 8

[Pandur S. (jetztnicht)]

Das 0x10 0x13 ist ein Carriage Return & Linefeed, zusammen auch genannt 
Zeilenumbruch. Das sind Befehle, die eine Terminalanbindung erleichtern.

[CAN mich aus (Gast)]

Das sieht ganz stark nach einer E2E Absicherung aus (END-to-End). Ist 
seid kurzem voll modern. Dabei gibt es einen Sequenz-Zähler (Zahl 4; 4 
Bit; 0x00 .. 0x0F) und eine zusätzliche SW-CRC (Zahl3; 8 Bit). Diese CRC 
wird über alle Daten mithilfe von (vertraulichen) Polynomen gebildet. Am 
Besten mal bei "Vector Informatik" oder bei "Autosar.org" suchen.
Viel Spaß bei der Polynomdivision :-)

[Torsten C. (torsten_c)]

CAN mich aus schrieb:
> Diese CRC wird über alle Daten mithilfe von (vertraulichen)
> Polynomen gebildet

"Security through obscurity"

Was für ein Sch**ß!

Meist Du wirklich, dass die Polynome bei Vector oder Autosar 
standardisiert sind? Die sollen doch geheim sein, wie Du selbst sagst.

[Dieter G. (docemmet)]

Hallo CAN mich aus,

danke ich glaube Sie haben den Nagel auf den Kopf getroffen.