Go Down

Topic: "Checksummenberechnung "- Wer findets raus? 100 Euro Belohnung ! (Read 2957 times) previous topic - next topic

Floetzinger

ist das evtl. nach  SAE-J1850 Norm (CanBus z.B. Automobil Zulieferer, Hersteller)?
und wo genau kommen die Daten her? und was soll damit passieren? ist mir immer noch nicht so richtig klar.
Namedropping wäre eine gute Hilfe für alle Helfer...

Gazello


Gazello

anbei die Hexdaten schön formatiert Windows Editor  für CRC Reveng. 


Wenn ich reveng  -w8 -s  + 30 sätze eingebe kommt nur  "no models found"

 

Schuppeste

Wenn ich reveng  -w8 -s  + 30 sätze eingebe kommt nur  "no models found"
 
Dann wurde erstmal nix vergleichbares in den standard CRC Einträgen gefunden..

man weiß ja auch nicht ob der das komplette Telegram nimmt und z.B. die Checksumme durch 0x00 oder ähnliches ersetzt.

Viel mehr habe ich mit reveng bisher auch nicht gemacht, man kann auch noch die Poly Search range mit q- angeben und noch diverses einstellen. (Vielleicht via Batch automatisieren)

wenn ich z.B. 0501010000 auf einer Standard CRC-8 Site ausrechne und den richtigen anhänge bekomme ich:

reveng  -w 8 -s 050101000090
width=8  poly=0x07  init=0x00  refin=false  refout=false  xorout=0x00  check=0xf4  residue=0x00  name="CRC-8"

Zeigt das es funktioniert.

Gazello

Ich weiß auch nicht , ob man den Start 49 und Ende  50  mit rechnet?
Was verwendet man den normal  wenn man eine CRC berechent ? nur die Daten  ohne Start und Ende ?


Ich dachte reveng kann auch unbekannte CRC erkennen , indem es das ergebnis zurückrechnet und somit das Polynom und init werte ausgibt. 


Die bekannten protkolle werden doch für das Erzeugen von CRCs gebraucht( macht das Programm ja auch)   

Hab noch -w8 -Fs (forced) im Video gesehen.

Was ist mit den -P  reversed generator polynom

Es muss auch keine CRC8 sein  , kann auch einfacher oder viel komplizierter sein .

Gazello

Die Symmetrie der Datensätze  müßte doch helfen das zu lösen ??


0 + 92  ist das gleiche wie 255-92      ( also 92 erzeugt die gleich Checksumme wie 163)

92+92  ist das gleiche wie 163-92       (also 184 erzwugt die gleiche Checksumme wie 71)


Symmetrische Datensätze:  0= 255, 1= 254 , 3= 253..........


49  5  1   1     0       0     164 50
49  5  1   1     92     0        54 50
49  5  1   1    184    0      128 50
49  5  1   1      20    1      230 50
49  5  1   1     112   1      196 50
49  5  1   1     204   1        45 50
49  5  1   1       41   2        73 50
49  5  1   1      133  2        70 50
49  5  1   1     225   2      100 50
.
.
.

49  5  1   1     30   253    100 50
49  5  1   1    122   253      70 50
49  5  1   1    214   253      73 50
49  5  1   1     51    254     45 50
49  5  1   1    143   254    196 50
49  5  1   1    235   254    230 50
49  5  1   1     71   255     128 50
49  5  1   1     163   255   54  50
49  5  1   1     255   255   164 50




Mit crc 8 bei (hex)  00 00  oder FF FF ist das nicht identisch , also wird entweder vorher noch, oder nur, eine summe oder -256 -*+df asd   gemacht .




postmaster-ino

Hi

Das liest Sich Alles irgendwie nicht ganz koscher - mir ist nicht klar, von wem Du die Daten erhältst, um Diesem die Daten abgeändert wieder zurück zu schicken - und, daß Du Geld bietest, macht die Sache nicht direkt 'sportlicher'.

Für mich klingt Das so, daß Du 250 Datensätze sniffen konntest und nun, mit unserer bescheidenen Hilfe, irgend was damit vor hast.

In diesem Sinne: Happy hacking

MfG
anscheinend ist Es nicht erwünscht, einen Foren-internen Link als 'Homepage' einzubinden, damit JEDER nur einen Klick von combie's Liste zum Thema State-Maschine entfernt ist.
... dann eben nicht ...

uxomm

Ich bin im Bereich Prüfsummen ja überhaupt kein Experte, möchte aber trotzdem auf folgende interessante Datenlage hinweisen.

Ich hab mir die Daten aus #9 angesehen und mich nur für jene Datensätze interessiert, wo es mehrere gleiche Prüfsummen aus unterschiedlichen Ausgangsdaten gibt (die Prüfsumme ist jeweils der vorletzte Wert einer Zeile):
Code: [Select]
  { 49  , 5 , 1 , 1 , 73  , 35  , 106 , 50},
  { 49  , 5 , 1 , 1 , 43  , 65  , 106 , 50},
  { 49  , 5 , 1 , 1 , 176 , 67  , 130 , 50},
  { 49  , 5 , 1 , 1 , 187 , 72  , 130 , 50},
  { 49  , 5 , 1 , 1 ,   0 ,  0  , 164 , 50},
  { 49  , 5 , 1 , 1 , 85  , 85  , 164 , 50},
  { 49  , 5 , 1 , 1 , 84  , 58  , 167 , 50},
  { 49  , 5 , 1 , 1 , 54  , 88  , 167 , 50},
  { 49  , 5 , 1 , 1 , 144 , 25  , 170 , 50},
  { 49  , 5 , 1 , 1 , 165 , 44  , 170 , 50},
  { 49  , 5 , 1 , 1 , 164 ,  8 ,  171 , 50},
  { 49  , 5 , 1 , 1 , 145 , 61  , 171 , 50},
  { 49  , 5 , 1 , 1 , 103 , 23  , 173 , 50},
  { 49  , 5 , 1 , 1 , 93  , 45  , 173 , 50},
  { 49  , 5 , 1 , 1 , 54  , 70  , 173 , 50},
  { 49  , 5 , 1 , 1 , 44  , 92  , 173 , 50},
  { 49  , 5 , 1 , 1 , 216 , 42  , 235 , 50},
  { 49  , 5 , 1 , 1 , 147 , 97  , 235 , 50},
  { 49  , 5 , 1 , 1 , 32  , 51  , 249 , 50},
  { 49  , 5 , 1 , 1 , 43  , 56  , 249 , 50},
//   0    1   2   3    4     5     6     7
// Start  -------- DATA -------  Prfs   End

Es gibt ein paar gleiche Prüfsummen, 173 scheint mir besonders interessant, da gibt es gleich 4.

Diese Datensätze habe ich dann durch ein sehr einfaches "Prüfsummen-Verfahren" geschickt, eine einfache XOR-Verknüpfung ( https://en.wikipedia.org/wiki/Checksum#Parity_byte_or_parity_word ). Start- und Endbyte habe ich dabei weggelassen. Hier der Sketch:
Code: [Select]
// Einfache XOR checksum vs. unbekannte Prüfsumme

byte myData[][8] = {
  { 49  , 5 , 1 , 1 , 73  , 35  , 106 , 50},
  { 49  , 5 , 1 , 1 , 43  , 65  , 106 , 50},
  { 49  , 5 , 1 , 1 , 176 , 67  , 130 , 50},
  { 49  , 5 , 1 , 1 , 187 , 72  , 130 , 50},
  { 49  , 5 , 1 , 1 ,   0 ,  0  , 164 , 50},
  { 49  , 5 , 1 , 1 , 85  , 85  , 164 , 50},
  { 49  , 5 , 1 , 1 , 84  , 58  , 167 , 50},
  { 49  , 5 , 1 , 1 , 54  , 88  , 167 , 50},
  { 49  , 5 , 1 , 1 , 144 , 25  , 170 , 50},
  { 49  , 5 , 1 , 1 , 165 , 44  , 170 , 50},
  { 49  , 5 , 1 , 1 , 164 ,  8 ,  171 , 50},
  { 49  , 5 , 1 , 1 , 145 , 61  , 171 , 50},
  { 49  , 5 , 1 , 1 , 103 , 23  , 173 , 50},
  { 49  , 5 , 1 , 1 , 93  , 45  , 173 , 50},
  { 49  , 5 , 1 , 1 , 54  , 70  , 173 , 50},
  { 49  , 5 , 1 , 1 , 44  , 92  , 173 , 50},
  { 49  , 5 , 1 , 1 , 216 , 42  , 235 , 50},
  { 49  , 5 , 1 , 1 , 147 , 97  , 235 , 50},
  { 49  , 5 , 1 , 1 , 32  , 51  , 249 , 50},
  { 49  , 5 , 1 , 1 , 43  , 56  , 249 , 50}  };
//   0    1   2   3    4     5     6     7
// Start  -------- DATA -------  Prfs   End

void setup() {
  Serial.begin(9600);
  Serial.println(" simple  |  unbekannte");
  Serial.println("  XOR    |  Pruefsumme");
  Serial.println("-----------------------");

  for (int i=0; i<20; i++) {
    // XOR-Verknüpfung:
    byte checksum = myData[i][1] ^ myData[i][2] ^ myData[i][3] ^ myData[i][4] ^ myData[i][5];
    Serial.print("  ");
    Serial.print(checksum);
    Serial.print("        ");
    Serial.print(myData[i][6]);
    Serial.println();
  }
}

void loop() {}

Das Ergebnis finde ich interessant:
Code: [Select]
simple  |  unbekannte
 XOR    |  Pruefsumme
-----------------------
   111        106
   111        106
   246        130
   246        130
     5        164
     5        164
   107        167
   107        167
   140        170
   140        170
   169        171
   169        171
   117        173
   117        173
   117        173
   117        173
   247        235
   247        235
    22        249
    22        249

Links ist die einfache XOR-Verknüpfung, rechts die unbekannte Prüfsumme.

Wie zu erwarten, sind die Zahlen nicht gleich.
Auffällig ist aber, dass die XOR-Verknüpfung immer dann gleiche Zahlen liefert, wenn auch das unbekannte Prüfsummenverfahren identische Ergebnisse für unterschiedliche Datensätze liefert.

Für weitere zielführende Interpretationen liegen meine "aktiven Mathematik-Zeiten" schon zu lange zurück, ich wollte euch aber diese interessante Beobachtung nicht vorenthalten.

Vielleicht ist das ja naiv, aber ich denke das es sich um eine sehr simple Prüfsummen-Methode handelt.

Günstig wäre es, wenn es noch mehr gleiche Prüfsummen aus unterschiedliechen Datensätzen gäbe.


AVR-GCC (also der "Arduino-Compiler") bietet übrigens eine eigene Library für CRC-Berechnungen: http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html
Die hab ich übrigens auch auf die Daten losgelassen, das liefert aber keine so augenfälligen Ergebnisse wie die einfache XOR-Verknüpfung.
Always decouple electronic circuitry.

Gazello

WOW Klasse arbeit, Danke



Mit XOR habe ich auch schon gespielt, aber wie du nie die richtige Antwort bekommen. Es ist vermutlich nur ein Teilschritt.  Vielleicht start mit 255 oder 164 oder 92  xor..... alle Daten .... und Adressen ... sum  ....sowas in der Art.

Wirklich interessant finde ich den hier

   
49 1 0 0 |   0 1 0      0 50                       ist die 0 die Checksumme ? 

49 1 0 0 |   0 1 0  51 16 30 50

49 1 0 0 |   0 1 0  51 16 5 13 243 50


Vielleicht werden auch nur die wirklichen Daten also alles nach dem jeweiligem header ( 100) ( oder (511) vewendet und das vorletzte Byte zu erzeugen .


combie

EDIT: vielleicht ist ja schon ein Fehler in Deinen vorbereiteten Daten...
Ist eigentlich schon bekannt, welche Maschine diese Daten ausscheidet?
Alle sagen: Das geht nicht!
Einer wusste das nicht und probierte es aus.
Und: Es ging nicht.

Tommy56

Dazu gab es schon einige Fragen. Das hällt der TO aber streng geheim. Evtl. hat er Gründe dafür.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

Gazello

Auf direktem Befehl vom  Kim  :)


Ich glaub ich  hab den Teilungstrich fasch gesetzt.

Es scheint

 
Start 49 
Adress Byte
Adress Byte
Adress Byte
Daten Bytes
.
.
.
.
Checksumme
Ende 50

Alle vorkommenden " Adressheader "

 49 51  1  1
 49  5   1  1
 49  1   0  0
 49 51  1  2
 49  1 51  1
 49  1 51  2 


Also alles nach den ersten 4 Bytes sind Daten. aber ob nur Daten oder auch die Adresse zu Checksummen berechnung genutzt werden ?

Oder beide jeweils ein Byte erzeugen welches wiederum zusammen  die Checksumme ergeben.


Tommy56

Auf direktem Befehl vom  Kim  :)
Dann solltest Du Dir die Checksummenprüfung auch von Kim (Schmitz oder Jong-un?) erklären lassen.

Ich habe bei dieser extremen Geheimhaltung des Umfelds den Verdacht, dass wir hier zur Lösung einer gesetzwidrigen Sache missbraucht werden sollen.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

postmaster-ino

Hi

In die RIchtung gingen meine Gedanken ja auch schon - wobei mir die Prüfsumme zu primitiv erscheint.
Der Sketch von uxomm zeigte ja gleiche Prüfsummen bei gleichem Input, ähnlich der Datensätze.

Aber trotzdem ist Das hier äußerst mysteriös (wenn gleich ich das in Aussicht gestellte Geld eh nicht erwarten würde, noch nicht Mal, wenn der TO hier 'mitspielen' würde - also auf Fragen einginge o.Ä.).

Sonst wäre Das hier eine nette Spielerei, so aber nicht!

MfG
anscheinend ist Es nicht erwünscht, einen Foren-internen Link als 'Homepage' einzubinden, damit JEDER nur einen Klick von combie's Liste zum Thema State-Maschine entfernt ist.
... dann eben nicht ...

Schuppeste

Vor allen wenn man hier Leuten die helfen könnten irgendwelche unformatierten Decimal Müll präsentiert, dazu noch komische Erklärungen :D

ich gehe nicht in den nächsten Decimal->Hex Converter damit mir die Zahlen irgendwann was sagen.

Oder prüfe Stundenlang an verformatierten und Laienhaften angeordneten Bytes eines nicht ersichtlichen Original  Dumps.

Go Up