Hallo, Ich habe hier ein 15 Jahre altes Gerät mit den ich per RS232 Kommunizieren kann. Die Nachricht die es verschickt ist immer gleich lang, nun gibt es da noch eine Prüfsumme die ich Umbedingt brauche. Hier mal ein Beispiel (Bytes): Folge 1: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 008 000 164 Folge 2: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 000 000 078 Das letzte ist die Prüfsumme, unterscheiden tun sie sich nur um das vorvor letzte Byte. Hab keine ahnung wie die berechnet wurde, währe sehr Glücklich wenn mir jemand dabei helfen könnte oder Tipps geben was man vor 15Jahren dafür benutzt hat.
Hallo, Möglichkeiten hibt es viele... Für einfache Sachen wurde auch da noch gern eine simple Addition ohne Berücksichtigung des Übertrags oder eine XOR-Verknüpfung genommen. Als Hex-Werte wäre es handhabbarer. Gruß aus Berlin Michael
Danke für deine Antwort. Mit Addition hab ich es schon probiert kommt aber nicht hin die Prüfsummen unterscheiden sich bei ein kleinen änderung ja schon enorm. Kenn mich mit XOR überhaupt nicht aus hab das nur mal gehört befrage gerade Google dazu aber so richtig komm ich da auch zu nichts. Hier nochmal als HEX: Folge 1: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 08 00 A4 Folge 2: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 00 00 4E
Ist Ascii Der Unterschied besteht hier nur darin, daß im ersten String ein Backspace hinter der Raute gesendet wird und beim zweiten String ein Leerzeichen. Dann kommt die Checksumme (?) CODE:..................................#BSNUL164 CODE:..................................#.NUL78 (Die Punkte repräsentieren Leerzeichen, 20h,32d)
Hallo zusammen, meine Vermutung ist, dass es sich um eine ganz simple Prüfsumme handelt. Mit dem folgenden Programm habe ich 58 bekanntere Prüfsummen von der ersten Folge erstellt. (Datei im Anhang) http://www.jonelo.de/java/jacksum/index_de.html
Das ist ja nicht so gut die können ja alles mögliche genommen haben. Die ersten 40 sind ASCII, dann ein byte für Leds, eins für Tastendruckbestätigung und dann eben die Prüfsumme. Vielleicht hat ja noch jemand eine Idee.
Wer sagt eigentlich das die Prüfsumme hier über ALLE Bytes gebildet wird? Vielleicht ja auch nur über die Daten ohne das "CODE:"?
Das ist sozusagen ein Serielles Terminal wenn man sein Code eingegeben hat dann gehts weiter durch Menüs und ich hab schon fast alle Bytes ausprobiert Prüfsumme ändert sich immer. Hab nochmal 2 Stück gemacht wo sich die letzten 2 Bytes diesmal geändert haben, mach nochmal alle rein: Byte Folge 1: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 008 000 164 Folge 2: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 000 000 078 Folge 3: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 000 068 057 Folge 4: 067 079 068 069 058 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032 035 032 008 068 211 Hex Folge 1: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 08 00 A4 Folge 2: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 00 00 4E Folge 3: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 00 44 39 Folge 4: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 23 20 08 44 D3 Wäre echt toll wenn das jemand knackt bin schon paarmal an diesen Gerät verzweifelt und würde ungern kurz vorm Ziel aufgeben.
Such mal Gesetzmässigkeiten und Abhängigkeiten, zum Beispiel ist die Prüfsumme immer ungerade, wenn das vorletzte Byte $44 ist - und so weiter. Diese Zusammenhänge mit vielen Beispielen überprüfen, und die richtigen zusammenfassen - was besseres weiss ich auch nicht.
Habe die ganze Nacht rumgerechnet aber noch zu nix gekommen, bin nur sicher das die einzelnen Bytes nicht addiert wurden weil kleinste änderungen schon eine ganz andere Prüfsumme ergeben. Das gerät hat ja auch kein riesigen Speicher das man da große Integer rechnungen anstellen kann, es kann trotzdem die Prüfsumme in weniger als 5ms haurrausfinden. Hab nochmal 2 Folgen diesmal hat sich nur eine Stelle um 1 erhöht: Folge 1: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 33 (<-hier) 20 20 23 20 00 00 EA Folge 2: 43 4F 44 45 3A 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 34 (<-hier) 20 20 23 20 00 00 9C
Hallo, kannst Du denn beliebige Werte vorgeben? Falls ja, dann mach doch mal alle Bytes 00, und nur immer eines 01. Vielleicht kommt man über die Gewichtung drauf. Dieter
Hallo, schau mal hier: http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung Ich vermute, dass die Prüfsumme nicht errechnet wird, sondern per Hardware-Schieberegister. Gruß Frank
Dein Beitrag von 21:55 ist interessant: Die Differenz zwischen den Prüfsummen der Folgen 1 und 2 ist eine andere als zwischen 3 und 4, obwohl in beiden Fällen dasselbe Bit geändert wurde. Das ist für die meisten einfachen Prüfsummenverfahren ungewöhnlich. Einfaches addieren, addieren mit Gewichtungen, shiften und XOR fallen damit raus. Denkbar wäre noch die Weiterverarbeitung des Additionsübertrages - dazu müsste man mal versuchen die Summe der Byte-Werte gering (<< 256) zu halten, was bei ASCII nicht unbedingt geht. Im Moment fällt mir nichts ein, außer wie bereits vorgeschlagen die Testreihe zu verlängern und Regelmäßigkeiten zu suchen. Insbesondere das Erhöhen eines Bytes um 1 ist sehr aufschlussreich. Auch die Prüfsumme von n identischen Bytes gibt gute Hinweise (speziell bei XOR). Sind die Prüfsummen immer identisch, wenn auch die Folge identisch ist? Nicht, dass das Byte was anderes bedeutet. Eventuell auch ein ECC Algorithmus, wobei ich denke, dass das zu viele Bits für ein Byte Korrekturdaten sind. Vielleicht ist auch nur ein Teil des letzten Bytes die Prüfsumme... grübel... @Frank Link >Ich vermute, dass die Prüfsumme nicht errechnet wird, sondern per >Hardware-Schieberegister. Fällt für mich auch unter die Kategorie "berechnen" ;) x << 1 == (x * 2) MOD 256 x >> 1 == ((x - x MOD 2) / 2) uns so halt... oder meintest du was anderes? Gruß Kai
Du wirst es zwar schon versucht haben, aber Fragen kostet nichts.
> 15 Jahre altes Gerät
Welches?
Vielleicht hat noch jemand Unterlagen dazu oder findet über
Google was raus.
Hallo Kai, wie der Beitrag beschreibt, kann man CRC-Checksummen sehr einfach mit Hardware erzeugen. Wenn die Maschine 15 Jahre alt ist, ist dies sehr wahrscheinlich. Ich glaube kaum, dass wir es hier mit einem aufwändigen Verfahren zu tun haben. Wenn ich heute Abend Zeit habe, werde ich das ganze mal in eine Software vom mir reinkippen, die wir früher genau für solche Zwecke gebaut haben. Wenn es ein CRC-Code ist, kann ich auch die Codierung ermittelt. Gruß Frank
Das ist ja Super das hier noch so viele vorschläge kommen. Ich lasse jetzt mal alle Posts ausser Dieters unbeantwortet weil er hat mich dazu angeregt. Zu den gerät gehört noch ein Bedientteil und wenn das die flasche Prüfsumme erhält dann sendet es ein E wie Error zurück. Zum glück besteht die Prüfsumme nur aus einen Byte, da hab ich kurz ein Programm geschrieben was das Prüfbyte von 0 bis 255 durchgeht und wenn kein Error zurückkommt hab ich die passende Prüfsumme zu jeder beliebigen Folge. Habe hier jetzt mal 5 Stück gemacht, schreibe nur das erste und die Prüfsumme, weil die anderen 41Stück auf 000 sind: 1. Erstes Byte: 000 Prüfsumme: 000 2. Erstes Byte: 001 Prüfsumme: 124 3. Erstes Byte: 003 Prüfsumme: 132 4. Erstes Byte: 004 Prüfsumme: 049 5. Erstes Byte: 005 Prüfsumme: 077 Wollte dann noch wissen was für Folgen ich prüfen sollte.
Ben, das würde ich noch mit anderen Bytes machen, also z. B. mit dem #01 und #02. Mal sehen, ob die Prüfsummen anders sind. Immer jeweils die restlichen Bytes wieder auf Null belassen. Dieter
Und bitte, bitte, bitte: Gewöhn dir den Unsinn mit den Dezimalzahlen wieder ab. Nimm Hex. Wenn es irgendwelche Bitzusammenhänge gibt, dann kann man die in Hex eventuell sehen, weil die Profis hier Hex in untr 2 Zehntel Sekunden in die binäre Schreibweise im Kopf umwandeln können. Mit Dezimalzahlen siehst du aber überhaupt nichts ohne zum Taschenrechner zu greifen.
Bei einer so breiten Streuung der Prüfwerte ist es wohl eine Hashfunktion. Die sind extra dafür ausgelegt, dass bei geringen Änderungen im Klartext eine möglichst grosse Variation in der Prüfsumme (Hash) auftritt. Wenn dein Gerät z.B. ein Zugangskontrollsystem ist, besteht eine grosse Chance, dass der Hashgenerator ein spezieller IC ist. So ähnlich wie ein Hashgenerator in einer Smartcard. Da kannst du dann lange analytisch rangehen. Vielleicht hilft eine Literaturrecherche zu Hashfunktionen, die als Ausgabe genau ein Byte liefern. Oder eine Literaturrecherche zu Geräten, die 33-Byte Klartext (plus 2 weitere Byte Nutzlast) haben. Im Bereich der Datenerfassungsgeräte gibt es da was. ABER, du hast ja, so wie ich sehe, die Möglichkeit eine Brute-Force Attacke zu reiten. Bastele deinen benötigten Klartext und probiere max. 256 Werte durch, bis die richtige Prüfsumme ermittelt ist. Im Mittel hast du in ca. 0,6s dein Prüfbyte für einen Klartext...
Hab jetzt schon eine Menge probiert und es gibt keine Muster die offensichtlich sind auch nicht in Bitcode. Hab mal die Bausteine angeschaut da wären: Der MC ist ein "M37450S1SP" http://www.datasheetcatalog.net/de/datasheets_pdf/M/3/7/4/M37450S1SP.shtml 2 Eproms http://www.datasheetcatalog.com/datasheets_pdf/X/2/8/H/X28HC256PI-15.shtml 1 CMOS GATE ARRAYS (Weiss nicht was das ist, Irgendein Speicher?) http://www.datasheetcatalog.com/datasheets_pdf/M/B/6/0/MB606XXX.shtml 2 USART 82C51A-2 http://www.datasheetcatalog.com/datasheets_pdf/8/2/C/5/82C51A.shtml 1 MSM82C55A-2 http://www.datasheetcatalog.com/datasheets_pdf/M/S/M/8/MSM82C55A.shtml 1x 256kbit SRAM Ne ganze menge Schieberegister und sonst keine wichtigen Chips mehr. Sieht mir nich so aus als wenn ein Hash in ein extra baustein erzeugt wird, bin echt Ratlos. Und so schnell geht das mit der Brute-Force nicht das dauert schon ein wenig bis ein Error zurückkommt dazu kommt noch das ein byte 013 oder 002 ist nix zurückkommt weil das die start ende anweisung ist.
Da-Ben wrote: > 1 CMOS GATE ARRAYS (Weiss nicht was das ist, Irgendein Speicher?) > http://www.datasheetcatalog.com/datasheets_pdf/M/B/6/0/MB606XXX.shtml Kein Speicher, sondern ein seltsamer Vorläufer eines CPLD oder FPGA oder ASIC. Im Unterschied zu einem CPLD oder FPGA kann ein User den IC nicht ohne den Hersteller programmieren (Bild Post-Design-Process im DB). Der User gibt ein "Logic Design" und ein "Test Data Design" ab und Fujitsu stellt die Innereien des IC ein. In dem Ding kann man logische Schaltungen basteln, die sonst viele schwarze Käfer auf der Platine erfordern. Das wäre eine Anwendung des Fujitsu-IC als eine IO-Anpassung zwischen dem µC und externer IO-Hardware. Ich halte es auch für möglich, mit dem Ding eine Hardware-Hashfunktion zu implementieren. Die Nutzung des Fujitsu-IC als Speicher wäre bei entsprechender Programmierung auch möglich, IMHO aber zu aufwendig. Da wäre ein 256kbit SRAM, wie er eh an Bord ist, wesentlich schlauer. Ein Wissens-/Nachbau-Schutz mit einem solchen IC besteht darin, dass es aufwändig ist, diesen IC zuerst analytisch oder brute-force zu verstehen und später dann nachzubilden. Wenn man es darauf anlegt, reicht es nicht zu schauen, was geht rein und was kommt raus - die Ausgabe ist u.U. von einer langen Latte von Eingaben in der korrekten Reihenfolge abhängig... Wenn es so ist, hängt es davon ab, wie gut der Rest entworfen wurde. Steht z.B. an einem Pin ein Pegel an, wenn die Prüfsumme richtig oder falsch ist? Wertet der µC nur diesen Pin aus oder braucht er das konkrete Ergebnis zum Weiterarbeiten (z.B. zum Sprung in bestimmte Programmteile).
Hm das ist nett das du mir den Baustein erklärst, weiss ich jetzt wenigstens was das ist. Was ich wohl vergessen habe zu schreiben das auf der anderen Seite eigentlich nur ein MC und ein paar Schieberegister sind. Hab den herrsteller mal eine E-Mail geschrieben glaube aber nicht das da was laufen wird ohne viel Geld. Ansonsten würde ich mich natürlich über alle möglichen Tipps freuen, habe ja schon soviele das ich mich bis zu mein Lebensende damit beschäftigen könnte :) aber kann ja sein das jemand noch "die" Idee hat.
Was gebraucht wird um das etwaige CRC-Polynom zu bestimmen sind Folgen dieser Art: 0x01 0x00 0x00 ... 0x02 0x00 0x00 ... 0x04 0x00 0x00 ... 0x08 0x00 0x00 ... 0x10 0x00 0x00 ... 0x20 0x00 0x00 ... 0x40 0x00 0x00 ... 0x80 0x00 0x00 ... und 0x01 0x00 0x00 ... 0x00 0x01 0x00 ... 0x00 0x00 0x01 ... usw...
Schau auch im Bedienteil nach, ob dort der gleiche IC drin ist.
Wenn ja, ist die Funktion des IC als Prüfbyteberechner
hochwahrscheinlich. Wenn nein, ist es eher ein IC für IO-Aufgaben und
Zoo für Logikgatter.
Hast du einen Logikanalyzer und kannst analysieren, ob und wann das
Rrüfbyte an den Ausgängen des IC (oder Eingängen des µC) erscheint?
Wenn du mit den Bitfolgen weitermachst:
Versuche auch herauszufinden, welches die Klartextbytes sind, d.h.
welche Bytes nicht in das Prüfbyte einfliessen bzw. statisch sind
("Code:"? "#").
Vielleicht kannst du auch auf den ASCII-Text verzichten und nur die
beiden Bytes nach dem # benutzen (LEDs und Tastendrücke). Da sind
wesentlich weniger mögliche Prüfbytes zu berechnen.
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.