Hi hätte mal eine Frage: Es gibt ja online Tools um Checksummen zu berechnen etc. Hab hier ne SPS und ein Testgerät mit Fuji µc die mittels RS232 mit einander kommunizieren. Dabei sendet die SPS (Programm auslesen ist nicht möglich) immer 4 Bytes im Hex Format an das Testgerät und das weiß dann, was für eine Antwort die SPS erwartet. Wohl eine Art Schutz damit die Steuerbefehle nicht durch x-beliebige Terminal Programme gesendet werden können. Nun die Frage: Gibt es online fertige Tools bei denen man möglichst viele Anfragen und Antworten dieser Art eingibt und das Tool versucht dann den "Rechenweg" zu finden? Damit man sich dann selbst was schreiben kann um mit eigener Software korrekt auf die Anfrage antworten zu können (sonst sperrt die SPS einen aus). Ich hätte auch andere Wege...da sich die Anfragen immer mal wieder wiederholen könnte man die alle manuell einbauen aber das wäre ziemlich aufwendig und keine elegante Lösung. Weiß da jemand was?
reverser schrieb: > Es gibt ja online Tools um Checksummen zu berechnen etc. Hunderte. > Dabei sendet die SPS (Programm auslesen ist nicht möglich) immer 4 Bytes > im Hex Format an das Testgerät und das weiß dann, was für eine Antwort > die SPS erwartet. OK. Das läßt aber noch vieles offen. Und das geht weit über einfache Checksummen hinaus. > Wohl eine Art Schutz damit die Steuerbefehle nicht > durch x-beliebige Terminal Programme gesendet werden können. Davon ist auszugehen, ja. > Nun die Frage: Gibt es online fertige Tools bei denen man möglichst > viele Anfragen und Antworten dieser Art eingibt und das Tool versucht > dann den "Rechenweg" zu finden? Nicht das ich wüßte. > Weiß da jemand was? Ja: das Feld der Möglichkeiten ist ziemlich groß. Rein maschinelle Auswertung nicht zielführend, jedenfalls nicht in akzeptabler Zeit. Hier hilft nur menschliche Intelligenz und Intuition. Die Maschine kann aber natürlich wertvolle Unterstützung liefern, insbesondere, wenn es anfangs darum geht, ganze Klassen von Möglichkeiten der Codierung auszuschließen. Nur muss halt der Benutzer wissen, was er tut. Der "Do what I want"-Button is nich...
reverser schrieb: > 4 Bytes im Hex Format Dann zeig die doch mal her. Bisher hast du nicht mal geschrieben, dass sich diese Bytes jedes Mal ändern. Nimm mal viele solche 4 Bytes auf, dann kann man sehen was sich ändert. Und wie oft. Ob es Muster gibt, ...
interessant wäre auch der Kontext zu den 4 gesendeten Byte (z.B. Auswirkung). Bzgl. "4 Bytes im Hex Format" ... 4 Byte ja, aber das Hex Format machst du bzw. das Tooling. Vielleicht sind es auch 4 ASCII characters oder ein anderer Zeichensatz ... oder, oder ... warum sind es eigentlich nicht 4 Byte dezimal?
reverser schrieb: > > Hab hier ne SPS und ein Testgerät mit Fuji µc die mittels RS232 mit > einander kommunizieren. > Gibt es von der SPS oder dem Testgerät die Firmware? Dann hat man eventuell eine Chance den Challenge-Response Algorithmus in der Firmware zu finden (aber auch nur wenn die Firmware nicht z.B. verschlüsselt ist). Ansonsten ist die Chance den verwendeten Algorithmus manuell oder automatisch zu finden eher gering, zumindest wenn es nicht nur eine trivial Rechenvorschrift ist.
reverser schrieb: > mit einander kommunizieren. Du meintest sicherlich "mit ein Ander" , so schreibt man das richtig !
reverser schrieb: > Weiß da jemand was? Bei 4 bytes gibt das 64k kombinationen. Das passt in eine tabelle. Du musst den code nicht mal entschlüsseln, nur lange genug zuhören.
Pepe T. schrieb: > > Bei 4 bytes gibt das 64k kombinationen. Das passt in eine tabelle. Du > musst den code nicht mal entschlüsseln, nur lange genug zuhören. 32 Bit sind immer noch 4 GByte Möglichkeiten.
Das sind 3 verschiedene Dinge: a) Aufbau und Inhalt des Telegramms (Daten, Kennung, Chks, ...) b) Berechnung der Chks (macht nur Sinn, wenn man den Aufbau kennt. Sonst sind das einfach 4-Byte-Muster c) sinnvolle Antworten (nachdem man a und b kennt) Überlicherweise liest man ein paar Hundert Telegramme mit und versucht Muster je Stelle zu erkennen - immer gleiche Zeichen (z.B. Start-Stopkennung) - fortlaufende Zeichen (z.B. ein Sequenz-Counter) - häufige Zeichen (z.B. 7 dedizierte Telegrammkennungen, die quer durcheinander kommen) - Komplementäre Bereiche (wenn die ersten 2 Zeichen gleich sind, sind es auch die letzten --> große Chance für 2 Byte Checksumme) Danach versucht man das gleiche mit Anfrage/Antwort. Also wenn in der Anfrage das erste Byte 0x09 ist, ist das in der Antwort immer 0x89. Sowas. Für uns fehlen hier halt 100 Telegramm-Paare.
Pepe T. schrieb: > Dieter schrieb: >> 32 Bit sind immer noch 4 GByte > > Huch. Hab ich falsch gerechnet. Nicht nur das. Du hast völlig außer Betracht gelassen, das es relativ einfache Möglichkeiten gibt, die Kommunikation gegen Replay-Attacken zu schützen. Eine temporale Komponente läßt die Möglichkeiten auf weit jenseits der 4G-Genze explodieren. Und selbst so eine Kommunikation wäre aus kryptographischer Sicht immer noch eher schwach gesichert (schließlich muss es entweder einen IV als shared secret geben oder eine Nachricht zu dessen Übermittlung), aber das herauszufinden, ist mit ein bissel dümmlicher Bit-Daddelei schon kaum noch möglich. Da müssten Profis anrücken und den Traffic sehr lange beobachten. Das kann der TO sicher nicht bezahlen...
Ja, solche Tools gibt's. Aber nicht online. Alleine um ein unbekanntes CRC-Polynom aus einem Strom ermitteln benötigt man gehörig Brute-Force und je nach Bitbreite entsprechend geloggte Daten. Wenn das System anhand eines Pseudozufallsgenerators noch nonces erzeugt und man die Datenfelder nicht kennt, ist ein "Erraten" etwa so zwecklos wie bei einem TAN-Generator. Also: Die SPS oder den uC-Peer auslesen ist definitiv zielführender. Trotzdem kannst du ja mal versuchen, einen "Replay" einer Sequenz zu machen. Solange dich der uC nicht irreversibel aussperrt, kann man mit FPGA-Power in relativ kurzer Zeit "schlechte" Polynome finden. Da solches Knowhow aber einen hohen Marktwert hat, wird dich da kaum einer in die Karten gucken lassen.
A. S. schrieb: > Überlicherweise liest man ein paar Hundert Telegramme mit und versucht > Muster je Stelle zu erkennen > - immer gleiche Zeichen (z.B. Start-Stopkennung) > - fortlaufende Zeichen (z.B. ein Sequenz-Counter) > - häufige Zeichen (z.B. 7 dedizierte Telegrammkennungen, die quer > durcheinander kommen) > - Komplementäre Bereiche (wenn die ersten 2 Zeichen gleich sind, sind es > auch die letzten --> große Chance für 2 Byte Checksumme) Ich zitiere das mal, aber die Antwort betrifft einige Beiträge: Ich hab das ganze natürlich schon analysiert und hier entsprechend nur die Bytes erwähnt, die die Challenge-Response Sache betreffen. Es sind immer 4 Zeichen...z.B. 99 9c. Wenn ich richtig liege, wären das 2x 255 Möglichkeiten... geht ja nur von 0-9 und a-f. Das Testgerät ist nicht gegen Replay-Attacken o.ä. geschützt, sondern ich kann mich als SPS "ausgeben" und bekomme entsprechend die Antwort. Vermutlich wäre es einfacher einen Skript zu schreiben der mit 00 01 beginnt, 00 02 etc. (falls das erste Byte überhaupt 00 sein kann, sonst sind es noch ein paar weniger mögliche Kombinationen) und dann entsprechend alle möglichen Kombis an das Testgerät schickt, und die Antworten verarbeitet. Dann kann man ein relativ einfaches Programm schreiben, Buttons mit den Steuerbefehlen belegen, Feld für Anzeige der Daten und im Hintergrund wartet das Programm auf die Anfrage der SPS und sucht entsprechend in einer DB die richtige Antwort raus... (Falls Anfrage 82 a5...dann...erwartete Antwort für 82 a5 in der DB suchen und senden...) Denke ich zu einfach?
reverser schrieb: > Es sind immer 4 Zeichen...z.B. 99 9c. > Wenn ich richtig liege, wären das 2x 255 Möglichkeiten... geht ja nur > von 0-9 und a-f. FacePalm! Also wenn Du nicht einfach echte Mitschnitte lieferst (ohne sinnentstellende Begriffe), wird Dir hier vermutlich keiner mehr sinnvoll antworten.
reverser schrieb: > Es sind immer 4 Zeichen...z.B. 99 9c. > Wenn ich richtig liege, wären das 2x 255 Möglichkeiten. Also 1 "zeichen" von 0 bis F sind 4 bits. HEX schreibweise. Du hast insgesamt 4 zeichen, also 16 bits? Das sind 256x256, 64k kombinationen. Durchaus möglich sowas mir einer liste zu machen.
reverser schrieb: > Wenn ich richtig liege, wären das 2x 255 Möglichkeiten... geht ja nur > von 0-9 und a-f. Du liegst nicht richtig. Geh nochmal über die Bücher, und beim nächsten Mal: Bitte gleich die volle Geschichte, bevor 20 Irrlichter entfacht werden.
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.