www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie wird die Prüfsumme berechnet ?


Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleicht Crc8?

Autor: Esko (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer sagt eigentlich das die Prüfsumme hier über ALLE Bytes gebildet 
wird?
Vielleicht ja auch nur über die Daten ohne das "CODE:"?

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter Stotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter Stotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

2 Eproms
http://www.datasheetcatalog.com/datasheets_pdf/X/2...

1 CMOS GATE ARRAYS (Weiss nicht was das ist, Irgendein Speicher?)
http://www.datasheetcatalog.com/datasheets_pdf/M/B...

2 USART 82C51A-2
http://www.datasheetcatalog.com/datasheets_pdf/8/2...

1 MSM82C55A-2
http://www.datasheetcatalog.com/datasheets_pdf/M/S...

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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da-Ben wrote:
> 1 CMOS GATE ARRAYS (Weiss nicht was das ist, Irgendein Speicher?)
> http://www.datasheetcatalog.com/datasheets_pdf/M/B...

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

Autor: Da-Ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Decoder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.