Hallo, ich benötige Hilfe bei Berechnen einer CRC Checksumme, gibt es hier eventuell jemanden der diesbezüglich helfen kann ?
Hi Karl, *wobei hapert es genau? *welche "CRC" Berechnung genau (CRC32, CRCC ...)? *welche Programmiersprache? *wenn Eigenentwicklung: muss es portierbar sein (Endianess)? VG, Stephan
Wenn man bei Google "CRC Berechnung" eingibt, dann kommen eine Menge von Seiten raus. Wo ist das Problem sich dort einzulesen? Geht es um einen Algoithmus/Funktion in einer Programmiersprache? Oder soll die Theorie für eine Hausaufgabe nachvollzogen werden?
> ich benötige Hilfe bei Berechnen einer CRC Checksumme, gibt es hier > eventuell jemanden der diesbezüglich helfen kann ? Da gibt es doch libs dafür und crc sollte so mit das am besten dokumentierte eines Protokolls/Blocksicherung sein. * Beitrag "CRC von Ethernet Frame berechnen" * https://www.patrick-saar.de/programme/crc-online-rechner
:
Bearbeitet durch User
Das klingt doch mal nach einer echten Aufgabe für eine KI. ☺ Und wenn die versagt, bleibt immer noch REVENG. Danach solltest du dann einmal suchen.
Stephan D. schrieb: > Hi Karl, > *wobei hapert es genau? > *welche "CRC" Berechnung genau (CRC32, CRCC ...)? > *welche Programmiersprache? > *wenn Eigenentwicklung: muss es portierbar sein (Endianess)? > VG, Stephan Also, ich habe davon wirklich nicht viel Ahnung, bitte schlagt mich jetzt nicht gleich deswegen.......... Ich habe einen hex- Datenblock der am Ende einen CRC16 Checksumme hat. Ich muss in diesem Block Änderungen vornehmen, demzufolge muss die Checksumme angepasst werden. Ich habe mich versucht ohnline einzulesen, auch einige Generatoren habe ich ausprobiert, leider ohne Erfolg, wahrscheinlich haben diese Generatoren nicht den Algorythmus der hier verwendet wurde.
Karl schrieb: > Ich habe mich versucht ohnline einzulesen, auch einige Generatoren habe > ich ausprobiert, leider ohne Erfolg, wahrscheinlich haben diese > Generatoren nicht den Algorythmus der hier verwendet wurde. Unwahrscheinlich. Aber es gibt viele Optionen für CRC, Initialwert, reflektiert, invertiert. Zeig uns deinen Datenblock und die originale CRC, dann können wir das passende Polynom und Verfahren finden.
Jeder CRC Code wird mit einem Startwert initialisiert: den muss man auch kennen. Der kann 0x0000 sein, muss aber nicht. Ich denke das liegt eher daran, und nicht am Algorithmus.
> Also, ich habe davon wirklich nicht viel Ahnung, bitte schlagt mich > jetzt nicht gleich deswegen.......... Wobei Schläge schon bei manchen das Denkvermögen angestossen haben ... > Ich habe einen hex- Datenblock der am Ende einen CRC16 Checksumme hat. > Ich muss in diesem Block Änderungen vornehmen, demzufolge muss die > Checksumme angepasst werden. Also selbst arduino hat ne crc16 library, wenn das nicht klappt ist vielleicht der Datenbereich falsch oder die Erwartungshaltung. Wenn es jetzt hex Datenblock statt Block heisst, könnte es ja sein, das da jemand ASCII einfüttert wo binary erwartet wird ... Da musste wohl "an der Tafel vorrechnen" müßen, damit dir jemand sagen kann, wo falsch "abgebogen" wurde.
Falk B. schrieb: > Karl schrieb: >> Ich habe mich versucht ohnline einzulesen, auch einige Generatoren habe >> ich ausprobiert, leider ohne Erfolg, wahrscheinlich haben diese >> Generatoren nicht den Algorythmus der hier verwendet wurde. > > Unwahrscheinlich. Aber es gibt viele Optionen für CRC, Initialwert, > reflektiert, invertiert. > > Zeig uns deinen Datenblock und die originale CRC, dann können wir das > passende Polynom und Verfahren finden. Das wäre ja ne Mega Hilfe ! Hier der Datenblock: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 6D 02 63 CD 00 00 00 00 88 6D 02 63 CD 00 00 00 00 84 CD 01 CD 00 00 00 00 00 84 6D 01 63 00 00 00 00 00 88 CD 02 63 CD 00 00 00 00 00 00 00 00 00 00 00 00 00 24 37 30 9D 92 9D 92 ist die Checksumme. Als Info noch dazu, die 37 30 vor der Checksumme, es kann sein das das nicht mit in die Berechnung mit einbezogen wird.
Peter schrieb: > Wenn man bei Google "CRC Berechnung" eingibt, dann kommen eine Menge von > Seiten raus. Wo ist das Problem sich dort einzulesen? Genau so habe ich es gemacht und es hat auf Anhieb funktioniert. Klar ist das Generatorpolynom entscheidend und der Startwert Aber ich hatte den Eindruck, die Implementierungen sind eh alle gleich oder sehr ähnlich.
Gunnar F. schrieb: > Peter schrieb: >> Wenn man bei Google "CRC Berechnung" eingibt, dann kommen eine Menge von >> Seiten raus. Wo ist das Problem sich dort einzulesen? > > Genau so habe ich es gemacht und es hat auf Anhieb funktioniert. Klar > ist das Generatorpolynom entscheidend und der Startwert Aber ich hatte > den Eindruck, die Implementierungen sind eh alle gleich oder sehr > ähnlich. wie gesagt, ich bin damit in diesem Fall leider nicht weiter gekommen
Gunnar F. schrieb: > Genau so habe ich es gemacht und es hat auf Anhieb funktioniert. Was aht "funktioniert"? > Klar > ist das Generatorpolynom entscheidend und der Startwert Es gibt da noch einiges mehr. Die bitorder z.B. > Aber ich hatte > den Eindruck, die Implementierungen sind eh alle gleich oder sehr > ähnlich. Ähem, nö. Es gibt stets mindestens zwei grundlegende Implementierungen: bit-wise und crcwidth-wise. Und dann kann es noch besondere Spielarten geben, z.B. Implementierungen, die zwar nicht bitweise arbeiten, aber auch nicht in der Breite der CRC, sondern in der Verarbeitungsbreite einer bestimmten Maschine. Und das alles (außer bitwise) kann dann auch noch tabellenbasiert oder als spezifischer Code implementiert sein. Also nö: die Vielfalt möglicher Implementierungen ist definitiv überwältigend. Selbst wenn man nur ein einziges konkretes Polynom betrachtet. Das gilt natürlich insbesondere für häufig benutzte Polynome.
Wulf D. schrieb: > Jeder CRC Code wird mit einem Startwert initialisiert: den muss > man auch > kennen. Der kann 0x0000 sein, muss aber nicht. Ich denke das liegt eher > daran, und nicht am Algorithmus. Ich meine, dass bei Ethernet der Startwert von -1 bzw 0xffffffff genommen werden muss. Details habe ich auf der Arbeit, da komme ich erst morgen ran.
:
Bearbeitet durch User
Moin, Ob S. schrieb: > Ähem, nö. Es gibt stets mindestens zwei grundlegende Implementierungen Richtig, ist aber voellig egal. Selbst wenn ich ein Tarotblatt habe, was mit die richtige CRC legt. Die Implementierung muss wurscht sein. Sonst taucht die nix. reveng findet bei mir auf Anhieb nix mit den gegebenen Daten. So'n bissl mehr Info woher das kommt, etc. koennte evtl. helfen... Gruss WK
Karl schrieb: > Hier der Datenblock: > 9D 92 ist die Checksumme. hast Du noch ein paar weitere unterschiedliche Datenblöcke?
:
Bearbeitet durch User
Stephan D. schrieb: > Karl schrieb: >> Hier der Datenblock: >> 9D 92 ist die Checksumme. > > hast Du noch ein paar weitere unterschiedliche Datenblöcke? PN
Dergute W. schrieb: > Richtig, ist aber voellig egal. Selbst wenn ich ein Tarotblatt habe, was > mit die richtige CRC legt. Die Implementierung muss wurscht sein. Sonst > taucht die nix. Das ist korrekt. > reveng findet bei mir auf Anhieb nix mit den gegebenen Daten. Das könnte dann z.B. daran liegen, dass es eigentlich keine CRC (im engeren Sinne) ist. Es kann übrigens trotzdem durchaus eine "Prüfsumme" sein...
Häufig hilft es einfach mal die Doku zu lesen, bei CRC RevEng heißt es z.B. im Kapitel "SEARCHING FOR CRC MODELS": "In general at least four data points are needed, either as known parameters or as message-CRC pairs."
Du könntest die anderen Daten hier auch einstellen; das hilft sicherlich beim knobeln;) p.s. PN landet in Deiner eMail inbox.
ChatGPT liefert was, aber ich denke das ist es nicht. CRC würde ich fast ausschließen nach dieser Antwort. Kurzfassung: Mit deinem Datenblock (84 Bytes, endet auf … 24 37 30) und der angegebenen CRC 9D 92 passt keine der üblichen CRC-16-Varianten (IBM/Modbus, CCITT-FALSE, X25, XMODEM, KERMIT, DNP, USB, GENIBUS, AUG-CCITT, …). Was jedoch exakt passt (ohne Bit-Reflexion): CRC-16 (breit=16, poly=0xFEAB, init=0xFFFF, refin=False, refout=False, xorout=0xFFFF) ⇒ Ergebnis 0x9D92 (entspricht Bytes 9D 92). Alternativ (andere, ebenfalls ungewöhnliche Polynomwahl): CRC-16 (poly=0xBA2F, init=0xFFFF, refin=False, refout=False, xorout=0x0000) ⇒ Ergebnis 0x929D (Bytes 92 9D, also vertauschte Reihenfolge).
:
Bearbeitet durch User
Alles klar — mit CRC-16/CCITT-FALSE (Poly 0x1021, Init 0xFFFF, keine Bit-Reflektion, xorout 0x0000) passt deine Prüfsumme exakt. Der CRC bezieht sich nicht auf den ganzen Block, sondern nur auf die 3-Byte-Sequenz CD 02 63 (im Datenblock bei Offset 64–66, 0-basiert). CRC über CD 02 63 ergibt 0x929D → im Block als 9D 92 (little-endian) abgelegt Sagt chatgpt. Habe genauso viel Ahnung wie Karl :)
Andere, nicht CRC Prüsummen schließt chatgpt aus: Kurz: Für nicht-CRC-Checksummen passt 0x9D92 nicht zu deinem 84-Byte-Block. Ich habe typische Varianten geprüft (jeweils über den kompletten Block gerechnet): Byte-Summe mod 2¹⁶, 16-Bit-Wortsumme (LE/BE), 1’s-complement/Internet-Checksumme (bytes & words), 2’s-complement → kein Treffer. XOR (8-bit/16-bit), BSD/SysV-artige rotierende Summen → kein Treffer. Fletcher-16, Adler-32 (Low/High-16) → kein Treffer. Auch „Summe inkl. Checksumme ergibt 0/0xFFFF“ (LE/BE) trifft nicht.
Das Problem ist, der TE weiß so wenig von der Sache dass die gegebenen Infos vermutlich falsch sind und damit alles für die Katz.
Cyblord -. schrieb: > Andere, nicht CRC Prüsummen schließt chatgpt aus: > > Kurz: Für nicht-CRC-Checksummen passt 0x9D92 nicht zu deinem > 84-Byte-Block. > > Ich habe typische Varianten geprüft (jeweils über den kompletten Block > gerechnet): > > Byte-Summe mod 2¹⁶, 16-Bit-Wortsumme (LE/BE), Das klingt ja jetzt irre, was der Kollege inzwischen so kann! Angeblich ja immer nur das jetzt wahrscheinlichste Wort hinschreiben...
Gunnar F. schrieb: > Das klingt ja jetzt irre, was der Kollege inzwischen so kann! Angeblich > ja immer nur das jetzt wahrscheinlichste Wort hinschreiben... Genau das hat er doch getan? Effektiv hat er genau garnix herausbekommen. Das aber in einen geschmeidigen Text verpackt. Wie es halt Geschäftsführer, Markingleute und ähnliches Gelichter auch machen. Die könnte man also problemlos durch KI ersetzen.
Vielleicht solltest du mehr zur Aufgabenstellung sagen. Wofür brauchst du die crc? Modbus?
> Das Problem ist, der TE weiß so wenig von der Sache dass die gegebenen > Infos vermutlich falsch sind und damit alles für die Katz. Der Eindruck kann täuschen, sicher weiß der TO mehr als er schreiben will, bspw. zum Ursprung des Schnipsels. Sieht etwas ungewöhnlich aus: * "00 00 00 00 88 6D 02 63 CD" wird wiederholt * und auch so ist "CD" recht häufig. * Magic numbers für typische file-/packet- typen finden sich nicht, Vielleicht ist es ein wireshark Mitschnitt, vielleicht ein save-file eines Baller-Games, Lizenz-key für Kaufsoftware ...
:
Bearbeitet durch User
Bradward B. schrieb: > vielleicht ein ... Lizenz-key für Kaufsoftware Ihr sollt eben nicht wissen, bei welchem Hack ihr dem TO helft. So könnt ihr später dem Richter sagen "ich wusste nichts".
Kann jeder bessere Hex-Editor....
Karl schrieb: >> hast Du noch ein paar weitere unterschiedliche Datenblöcke? > > PN Schade! Ist ein Beitrag, den auch ich sehr interessant finde. Ich habe nämlich auch keinen blassen Schimmer davon.
Stephan D. schrieb: > Du könntest die anderen Daten hier auch einstellen; das hilft sicherlich > beim knobeln;) > > p.s. > PN landet in Deiner eMail inbox. 30 27 04 42 60 83 C9 00 00 30 47 04 22 60 83 C9 00 00 2C AB 03 60 83 C9 00 00 00 8C 61 03 63 84 CD 00 00 00 8C 61 03 63 84 CD 00 00 00 88 CD 02 CD 84 00 00 00 00 84 61 01 63 00 00 00 00 00 8C CD 03 63 84 CD 00 00 00 00 00 00 00 00 00 00 00 19 3F 36 37 B9 6D 30 27 04 42 60 83 C9 00 00 30 47 04 22 60 83 C9 00 00 2C AB 03 60 83 C9 00 00 00 8C 61 03 63 84 CD 00 00 00 8C 00 03 63 84 CD 00 00 00 00 00 00 00 00 00 00 00 00 84 61 01 63 00 00 00 00 00 8C 00 03 63 84 CD 00 00 00 00 00 00 00 00 00 00 00 19 3F 30 35 EB 07 Die 2 Bytes vor der Checksumme ( 36 37 und 30 35 ) werden nicht in die Berechnung mit einbezogen.
> Hier der Datenblock: > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 88 6D 02 63 CD 00 00 00 00 88 6D 02 63 CD 00 00 00 00 84 CD 01 > CD 00 00 00 00 00 84 6D 01 63 00 00 00 00 00 88 CD 02 63 CD 00 00 00 00 > 00 00 00 00 00 00 00 00 00 24 37 30 9D 92 Schaut ähnlich einem Ethernet-Frame aus bei dem die Präambel und SFD ge-nullt sind. "88 6D 02 63 CD 00 " würde dann die MAC-Addr o.ä. sein, da sendet also einer an sich selbst ein Paket. Anhand der oberen MAC, "88:6D:02", Kann man den Hersteller bestimmen, könnte hier intel sein. Die CRC erstreckt sich lt. Ethernet Standard "the FCS value is computed as a function of the protected MAC frame fields: source and destination address, length/type field, MAC client data and padding (that is, all fields except the FCS). Die führenden Nullen gehören also nicht dazu und das könnte hier das Hauptrpoblem sein, das nicht bekannt ist, wo die Daten für die CRC beginnen. https://en.wikipedia.org/wiki/Ethernet_frame https://ipcisco.com/lesson/ethernet-basics/ > Ihr sollt eben nicht wissen, bei welchem Hack ihr dem TO helft. So könnt > ihr später dem Richter sagen "ich wusste nichts". Naja, Beihilfe ist auch strafbar, erst recht wenn der Staatsschutz ermittelnd involviert ist.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.