So wie es aussieht müsste ich die Bereichskennung 0x01 an der Position, an der bei einer normalen S7-Adresse z.B. 0x84 für den Bereich Datenbausteine steht, ergänzen. Dort dürfte momentan "unknown area" angezeigt werden.
* Ich habe captures, welche _immer_ vor dem Trailer 32 Byte zufällige Wustdaten enthalten (unabhängig von der Funktion, und unabhängig davon, ob es Request/Response/Cyclic ist). Es deutet einiges
darauf hin, dass es sich dabei um eine Art Integritätsblock oder Signatur handelt, um Replay Attacken oder unauthorisierte Pakete zu verhindern. Grund für meine Annahme: diese Daten ändern sich
selbst dann, wenn der Rest des Pakets - welcher ja im Klartext übertragen wird - gleich bleibt.
Habt ihr solche Pakete auch schon mal beobachten können? Gibt es für die "neuen" S7er wohl eine Art "secure mode"?
Mein erster Ansatz war, über alle möglichen Permutationen eines Pakets Prüfsummen mit verschiedensten (auch sehr exotischen) Prüfsummenverfahren zu bilden, aber keines hat gematcht. Vielleicht
verwenden sie noch eine Art geheimen Salt um eine Art HMAC zur Authentisierung der Pakete zu verwenden? Mein nächster Ansatz wird sein, zu versuchen, ob eben diese 32 Byte einer Normalverteilung
entsprechen oder nicht - eventuell gibt das ja einen Anhaltspunkt, was sich da drin verbirgt....
* Thomas, du kommentierst in deinem Code, bei zyklischen Paketen käme bei den Feldern unknown1:unknown2 immer nur 0x1000:0x0400 vor. Eben diese captures, welche die 32-Byte Garbage am Ende
enthalten, haben 0x7000:0x0400 im unknown1:unknown2 field. Es scheint mir also so, als würde es sich bei unknown1 und unknown2 um eine Art Bitmaske handeln. Handelt es sich aber um Requests / Reads,
so bleibt unknown1:unknown2 auf 0x0000:0x0000.
* Ich konnte glaub ich (aber noch nicht wirklich sicher) eine Funktionen identifizieren: 0x04f2. Das kommt bei mir immer kurz vor einer Endsession, wenn cyclic packets subscribed sind. Nach dem
0x04f2 Request+Respone stoppt die PLC mit dem senden ihrer cyclic packets. Also vielleicht eine Art Cyclic Unsubscribe?
* In dem Dissector wird der Trailer genauso gehandelt wie der Header. Aber das DataLength field im Trailer ist _immer_ 0x0000. Ist es dann logisch, das datalength zu nennen? Was wollte Siemens
eigentlich mit dem Trailer bezwecken?
Ich sehe darin auch keinen Sinn, die Ersparnis an Bandbreite dürfte in niedrigen einstelligen Prozentbereich liegen.* Was haben sie sich nur mit den variable length quantities gedacht? Das ist so tierisch gefährlich. Warum nicht einfach ein Byte Länge und dann die sagen wir Integer-Daten in Big Endian übertragen?
Bei fixen Längen, wie z.B. der Symbolic-CRC ist es doch total idiotisch, Variable length quantities zu verwenden?! Noch idiotischer is es, das ganze nicht einmal konsequent durchzuziehen, wenn man
es schon macht.
Auch die Struktur der Read/Write Req/Res geht mir noch nicht ganz ein, bei meinen captures wird da im Moment noch relativ viel fehlinterpretiert, muss da mal genauer schauen, was da los ist.
Das habe ich erstmal so benannt, weil der Aufbau dann identisch mit dem Header ist. Warum sollte man unnütze 4 Bytes anhängen? Ich verstehe es auch nicht.
Wenn du einen großen Baustein hochlädst lässt sich damit eine Fragmentierung der PDU erkennen - zumindest bei der ersten. Den Trailer gibt es dann nur im letzten Teil der Serie. Dann liest der Partner so lange die Daten ein,
bis er einen Trailer sieht. Ob das zuverlässig ist weiß ich auch nicht. Eigentlich müsste man die 0x72 dann im Bytestrom entsprechend escapen. In Wireshark selber lässt sich die Erkennung glaube ich nicht zuverlässig realisieren, bzw. kann die Erkennung auch fehlschlagen, falls in den Fragmenten das erste Byte im Data-Teil einen bekanntem Code entspricht.
Die 0x72 braucht man nicht zu Escapen, da im Header bereits die Länge bis zum Trailer steht. Somit ist klar, dass jeder Wert 0x72 innerhalb dieser Länge zur Payload gehört.
Evtl. ist der "Trailer" als zukünftige Erweiterung gedacht, um direkt an ein Telegramm ein weiteres Anhängen zu können.
Gruß
Jürgi
Ja. Weil die Id bei den zyklischen Daten glücklicherweise einen Wert hat der alle 32 Bit benötigt, wie 0x1000006a. Und die Id kommt bei Start-Session von der SPS zurück, und wird auch beim Beenden der Session so verwendet. Darum bin ich überhaupt drauf gekommen dass es varuint32 ist, denn so eine Zahl hat in diesem Format verdächtig viele 8en in den Bytes ;-)Bist du dir bei der Cyclic Session ID sicher, dass sich die immer über 4 Byte erstreckt?
Wie ich oben schon mal erwähnt hab, glaub ich, dass es nicht Teil der Session ID ist, sondern eher eine Art Bitmaske (Ich konnte in dem Feld 0x1000 und 0x7000 beobachten, daher meine Vermutung auf ne Bitmaske).
Eventuell könnte man sogar Pakete immer konsequent in vier statt in drei Teile aufteilen:
Header -> Data Header -> Data -> Trailer
Über alle Pakete ist der Data Header im Prinzip immer der gleiche (Type of Data, Funktionsnummer (bzw. Cyclic Reference), bisschen was unbekanntes, Sequence Number).
Der Data Header bestimmt quasi, um welchen expliziten Typen es sich bei Data handelt.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?