Hallo,
ich bin auch gerade damit beschäfigt, das s7comm-plus Protokoll zu entwirren. Was hat Siemens da nur verbrochen...
Erst mal allen voran: Vielen Dank für eure hervorragende Leistung was das bisherige Reverse Engineering und den Dissector angeht! Ich bin sehr verwundert, wie fürchterlich Siemens dieses Protokoll designed hat, aber noch mehr überrascht es mich daher was ihr bisher rausfinden konntet.
Nun zu dem, was ich noch rausfinden konnte:
* 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?
* 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.
Es ist also echt gefährlich, wie Siemens das Protokoll aufbaut. Wegen der Variable-length Quantities braucht man keine Längenfelder, was das ganze meiner Ansicht nach zu einer hochexplosiven Mischung macht: Ein kleinster Parserfehler, und das ganze fliegt einem um die Ohren. Selbst wenn der Parser passt, und man stellt sich vor, man möchte ein fragmentiertes Telegramm übermittelt und dummerweise ist genau das viertletzte Byte eine 0x72.
- Hmm, haben wir jetzt einen Trailer oder gehört es noch zu den Nutzdaten?
Sehr gefährlich.
So far, so good.
Investigative Grüße
