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.
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
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...
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.
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.
