Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 21 von 27 ErsteErste ... 111920212223 ... LetzteLetzte
Ergebnis 201 bis 210 von 262

Thema: Wireshark Plugin für S7-Protokoll

  1. #201
    Registriert seit
    08.12.2004
    Beiträge
    94
    Danke
    2
    Erhielt 16 Danke für 14 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Das Hochladen mit dem Plugin ist ja ganz schön eigenartig.

    @Thomas_v2.1,
    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.
    Ja, Thomas, genau da steht unknown Area.
    Diese Kennung 0x01 kommt einfach statt der Kennung 0b10000zzz im Bereichsübergreifenden zeiger. Damit wird dieser Zeiger zu einem "Zeiger" auf einen datensatz. Anzahl Bytes (bzw. Char) und Datensatznummer stehen weiter oben.

    Fortsetzung folgt gleich.

    mfG. klaly
    Angehängte Dateien Angehängte Dateien
    Zitieren Zitieren Anhang2 Wireshark Aufzeichnung zu DS-Read  

  2. #202
    Registriert seit
    08.12.2004
    Beiträge
    94
    Danke
    2
    Erhielt 16 Danke für 14 Beiträge

    Standard

    @Thomas_v2.1,

    eine Anwendung zum DS-Schreiben ist u.a. Firmwareupdate für z.B. den CP341.
    Dafür brauchst du die Projektiersoftware CP341 und eine passente Firmware.

    Mitschnitt folgt.

    Auch Firmwareupdate für Profibus und Profinet koppler erfolgen über DS-schreiben/lesen.
    Allerdings macht es Step7 anders, wenn das PG direkt am Profinet hängt, dann werden direkt "Profinet Telegramme" zu den Devices geschickt.
    Wenn es aber über MPI, oder über einen TCP/IP CP geht, dann gehts es auch über Datensatz lesen/schreiben.

    In wie weit diese s7comm Erweiterung für andere nützlich ist kann ich dir nicht sagen.
    Ich jedenfalls treffe hin und wieder darauf.

    Wenn noch Fragen sind, einfach melden.

    mfg. klaly
    Angehängte Dateien Angehängte Dateien

  3. Folgender Benutzer sagt Danke zu klaly für den nützlichen Beitrag:

    Thomas_v2.1 (23.10.2014)

  4. #203
    Avatar von Thomas_v2.1
    Thomas_v2.1 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    29.03.2004
    Beiträge
    5.077
    Danke
    128
    Erhielt 1.477 Danke für 1.088 Beiträge

    Standard

    Ich habe es jetzt mit der Bezeichnung "Dataset" für den Bereich eingebaut, siehe Screenshot.
    Aber wenn es auch möglich ist darüber ein Firmwareupdate aufzuspielen, entspricht es vlt. eher dem Bereich "Systemdaten"?

    Naja, exotisch ist es schon etwas. Aber wenn die Funktion bekannt ist kann man es auch einbauen.
    Angehängte Grafiken Angehängte Grafiken

  5. #204
    Registriert seit
    08.12.2004
    Beiträge
    94
    Danke
    2
    Erhielt 16 Danke für 14 Beiträge

    Standard

    @Thomas_v2.1,

    schön, aber ich denke die Bezeichnungen sind so noch nicht ganz stimmig.
    Da muss ich morgen auf der Arbeit mal schaun, wie die Bezeichnungen bei Profibus u. Profinet dafür sind.
    So solltest du es dann auch bezeichnen.

    Die Sache mit Firmwareupdate ist eher ein Sonderfall.
    Mit den Datensätzen kannst du Diagnose machen und auch Module, z.B. Analogmodule zur laufzeit umparametrieren.
    Dies geschieht normalerweise aus dem SPS-Programm heraus.
    Aber es geht auch über die PG-Kommunikation.

    mfg. klaly

  6. #205
    Registriert seit
    21.10.2014
    Beiträge
    9
    Danke
    1
    Erhielt 1 Danke für 1 Beitrag

    Idee

    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
    Geändert von foo (27.10.2014 um 13:50 Uhr)

  7. #206
    Avatar von Thomas_v2.1
    Thomas_v2.1 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    29.03.2004
    Beiträge
    5.077
    Danke
    128
    Erhielt 1.477 Danke für 1.088 Beiträge

    Standard

    Zitat Zitat von foo Beitrag anzeigen
    * 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"?
    Das habe ich bisher nur bei der 1500er gesehen. Alleine von den Werten her sieht es mir auch nach einer Signatur oder sowas in der Art aus.
    Kritik an möglichen Replay-Angriffen beim alten S7-Protokoll gab es zu genüge, da würde ich davon ausgehen dass Siemens da etwas eingebaut hat.
    Die Session-Id alleine ist aufgrund des begrenzten Wertebereiches von einem Byte (das andere ist ja immer 0x03) dafür nur bedingt tauglich. Die hat man schnell durchprobiert.

    Zitat Zitat von foo Beitrag anzeigen
    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....
    In sowas habe ich selber keine Erfahrung. Ich habe aber mit Interesse verfolgt, wie ein paar Leute das Meteo-Time-Protokoll in DCF77 auseinandergenommen haben. Da war der erste Ansatz, eine größe Menge an Logfiles zu sammeln.
    Sinnvoll wäre es, bei sowas zumindest die ersten beiden Telegramme (StartSession und das erste Write) mitzuprotokollieren. Denn erst danach werden die Bytes ergänzt. Und für irgendetwas müssen die ganzen Strings die an die SPS geschickt werden ja gut sein.

    Zitat Zitat von foo Beitrag anzeigen
    * 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 teste immer noch nur mit einer 1200, und bei der fehlt der "Garbage" / die "Signatur" auch bei den zyklischen Daten. Daher kommen die Werte im Kommentar.

    Zitat Zitat von foo Beitrag anzeigen
    * 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?
    Das sieht so aus. Zumindest findet sich dort die Referenznummer wieder. Das Anmelden der Variablen geschieht so wie es aussieht über die Funktion 0x04ca-Block, welche auch beim Upload von Bausteinen verwendet wird.
    Da bin ich aber gerade dabei, ich denke mal das wird noch rauszufinden sein.

    Zitat Zitat von foo Beitrag anzeigen
    * 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?
    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.

    Zitat Zitat von foo Beitrag anzeigen
    * 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.
    Ich sehe darin auch keinen Sinn, die Ersparnis an Bandbreite dürfte in niedrigen einstelligen Prozentbereich liegen.
    Wenn es wenigstens einheitlich wäre, sodass alles >=32 Bit als variable Länge übertragen wird. Aber nicht mal das.

    Das "mal so mal so" nervt vor allem Dingen beim Reverse-Engineeren, weil man erst erkennen kann ob es eine variable Länge ist wenn die Werte entsprechend groß werden.

    Dagegen hatte das alte S7-Protokoll eine glasklare Struktur.

  8. #207
    Registriert seit
    21.10.2014
    Beiträge
    9
    Danke
    1
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Ich hab hier leider kein Testsystem, sondern bekomme lediglich die captures. Das ist mein großes Problem, denn ich weis nur grob, was während den captures vor sich geht. Sonst könnte ich da selbst etwas mehr rumspielen und Testpakete erzeugen.

    Hab mir heute die letzten 32 Byte genauer angesehen: Es ist wohl diskret gleichverteilt. Und gleiche Pakete erhalten unterschiedliche Signaturen, was das ganze schwer macht. Es gibt mir aber auch gewisse weitere Information, dass vermutlich alte Paketinformationen in irgendeiner Art und Weise einfließen. Weist du zufälligerweise ob man die (ich nenns einfach mal so ab jetzt, weil alles darauf hindeutet) Integrität abschalten kann, sprich, ist es optional? Ich bin mal gespannt, ob ich da noch dahinter komm...

    Interessant wäre zu wissen, ob zwei StartConnections von einer 1500er die gleiche "initiale" Integrität hätten, dann könnte man versuchen weiter drauf loszugehen.

    Bei dem Trailer bin ich auch absolut bei dir - ergibt keinen Sinn.

    Auch mit dem Varint erst am >32 Bit bin ich voll bei dir! Evtl. ist es aber absicht. Security by obscurity und so, um eben Reverse Engineering hart (aber nicht unmöglich) zu machen. Selbst wenn es eine Ersparnis bringt, hebt sich die durch die (wenn auch geringe) Rechenlast beim Umrechnen wieder auf... und wie gesagt - ich finds gefährlich...

    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.

    Schönen Abend!

  9. #208
    Avatar von Thomas_v2.1
    Thomas_v2.1 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    29.03.2004
    Beiträge
    5.077
    Danke
    128
    Erhielt 1.477 Danke für 1.088 Beiträge

    Standard

    Zitat Zitat von foo Beitrag anzeigen
    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.
    Du meinst mit Anzeige als "malformed packet"? Bei den Telegrammen bei denen wirklich Variablenwerte gelesen / geschrieben werden sollte das eigentlich passen. Bis auf die Erkennung der Fehlercodes wenn z.B. die CRC oder die LID nicht mit dem SPS-Programm übereinstimmen.
    Es gibt noch andere Read/Write Telegramme die ein mir bis jetzt unbekanntes Datenformat nutzen, dann schlägt die Erkennung fehl und es wird sozusagen "Schrott" erkannt und ggf. übers Paketende hinaus eingelesen, das würgt Wireshark dann mit "malformed packet" ab.

    Ich kann ja noch ein paar Telegramme mit zyklischen Daten einer 1200 ins Repository hochladen, für eine 1500 habe ich aber auch nicht mehr.

  10. #209
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.645
    Danke
    208
    Erhielt 409 Danke für 328 Beiträge

    Standard

    Also falls Interesse besteht mit einer 1500er rumzuexperimentieren, Ich kann eine an mein Netz hängen und dir übers Internet zugänglich machen... Ich komm im Moment einfach nicht dazu mich näher mit der 1500er zu beschäftigen, sonst würde Ich gern auch in die Protokollanalyse mit einsteigen...
    ---------------------------------------------
    Jochen Kühner
    http://jfk-solutions.de/ - Softwareentwicklung, Programmierung, ...
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    IPhoneS7 - Inbetriebnahme Tool fürs IPhone (VarTab, Baustein-, PLC-Status)

  11. #210
    Registriert seit
    25.09.2014
    Beiträge
    4
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen

    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

Ähnliche Themen

  1. Wireshark Auszüge von Onlinebeobachtungen
    Von Jochen Kühner im Forum Simatic
    Antworten: 40
    Letzter Beitrag: 25.01.2011, 15:44
  2. Wireshark 1.2.0 ohne AMS.ADS?
    Von Neals im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 08.07.2009, 21:29
  3. Wireshark als Sender
    Von Tapio Bearking im Forum PC- und Netzwerktechnik
    Antworten: 2
    Letzter Beitrag: 08.07.2008, 11:47
  4. AK- Protokoll
    Von borromeus im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 27.02.2007, 17:30
  5. S7-Protokoll 2
    Von Zapot im Forum Feldbusse
    Antworten: 1
    Letzter Beitrag: 21.08.2006, 09:37

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •