Wireshark Plugin für S7-Protokoll

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine Challenge/Response ist:
e8c952612362b63222c725c400c6b6c47b6204e5 // 5501bdf9a628dc618f00f9e48836ae8e8313d3be

Und dein Passwort lautete test

Fazit: Man sollte beim TIA-Portal ein starkes Passwort verwenden wenn es was bringen soll.

 

[foo]

Ich glaub ich konnte den Unknown 3B Type entziffern.

Der hat nicht wie angenommen immer nur 3B, sonder ist eher ein Byte-Vector und verhält sich ähnlich wie ein String.

Er besteht aus 2Byte length indication und wird dann gefolgt von genau dieser Länge an Bytes.
Das geht sich perfekt in einer meiner Captures aus:

a39505 00 14 0005 0102030405
          ^^ ^^^^      5 Byte Daten
           |    5 Byte Längenindikator
       "3B" Type

Viele Grüße!

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da musste ich erstmal ein Logfile suchen bei denen in der Längenangabe ein Wert ungleich 0 steht, bei der HMI-Kommunikation steht dort als Länge fast immer eine 0.
Aber die Daten einer Variablentabelle werden in so einem Blob (so hab ich das jetzt genannt) verpackt.

Ich verstehe es eh nicht warum so viele Arrays und Strings mit Länge Null durch die Gegend geschickt werden, für mich ergibt das keinen Sinn.

 

[Thomas_v2.1]

Worin ich auch noch kein Schema sehe, ist das immer gleich aussehende "Anhängel" am Datenteil das es bei vielen Telegrammen gibt. Vor allem ist das mal 25, 26 oder 27 Bytes lang. Am Ende hängt immer eine unterschiedliche Anzahl 0-Bytes. Es wird auf jeden Fall nicht der Datenteil auf eine gerade oder ungerade Anzahl an Bytes aufgefüllt. Sehr seltsam.

1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:00:00:00:72
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:01:00:00:00:00:72	-> bei 0x0586 Request
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:00:00:00:72
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:01:00:00:00:00:72
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:00:00:00:00:72	-> bei Modify session
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:00:00:00:72
04:e8:89:69:00:12:00:00:00:00:89:6a:00:13:00:89:6b:00:04:00:00:00:00:00:00:00:72

 

[Thomas_v2.1]

Für den interessierten Mitleser habe ich vom aktuellen Stand des s7comm-plus plugins kompilierte dlls für 32 und 64 Bit veröffentlicht. Die kann unter:
http://sourceforge.net/projects/s7commwireshark/files/s7comm-plus-dev/
heruntergeladen werden.

Es gibt zwar noch einige weiße Flecken auf der Landkarte, aber ich würde sagen dass ca. 80% vom Protokoll erkannt werden.

Theoretisch könnte man sich mit den Informationen schon daran machen einen Treiber für die symbolische Anbindung einer 1200/1500 zu schreiben. Als Basis für den TCP/ISO-Stack wäre Snap7 sicher nicht die schlechteste Wahl. Das wäre doch mal was, wenn es zuerst eine Open-Source Lösung gäbe

Bei der 1500 kommt aber noch das Problem der Integritätsinformationen hinzu die jedem Telegramm anhängen. Wobei da zu prüfen ist, ob diese bei entsprechendem Verbindungsaufbau evtl. auch entfallen können.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe nochmal eine aktuelle Version veröffentlicht. Die Bezeichnungen der Funktionen wurden geändert, sodass sich ein schlüssiges Bild über das ergibt was dort abläuft.
Alle Telegramme die ich mit meiner 1200er erzeugen konnte werden erkannt. Alle die mir für eine 1500er vorliegen ebenfalls, zumindest gibt es mit diesen keinen Dissector-Fehler. Was mir noch fehlt wären Telegramme einer 1500er bei denen Alarme von der SPS an ein HMI übertragen werden. Bei der 1200 ist diese Funktion nicht vorhanden.

Alles was ein HMI zum Lesen und Schreiben benötigt, wie auch das Auslesen der Variableninformationen aus der SPS wird erkannt. Es lässt sich dabei auch erkennen wie intern die "optimierte" Speicherablage funktioniert, d.h. die absoluten Speicheradressen, welche vom TIA-Portal bei "optimierten" Bausteinen nicht angezeigt werden.

https://sourceforge.net/projects/s7commwireshark/files/s7comm-plus-0-0-1/

 

[Jochen Kühner]

Was ist den jetzt mit der integration von S7Comm direkt in Wireshark? Dachte die hätten das schon gemerged?

 

[Thomas_v2.1]

Ist bisher nur in der Development Version, die kann man auch separat herunterladen, z.B. in der 1.99.2 sollte es enthalten sein.
In die 1.12er Reihe kommen keine neuen Protokolle mehr. Glaub die Entwickler sind stark mit der Umstellung von GTK auf Qt beschäftigt. Bisher haut mich die Qt Version noch nicht vom Hocker, ist aber vielleicht nur Gewöhnungssache.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist bisher nur in der Development Version, die kann man auch separat herunterladen, z.B. in der 1.99.2 sollte es enthalten sein.
In die 1.12er Reihe kommen keine neuen Protokolle mehr. Glaub die Entwickler sind stark mit der Umstellung von GTK auf Qt beschäftigt. Bisher haut mich die Qt Version noch nicht vom Hocker, ist aber vielleicht nur Gewöhnungssache.

Ok, danke für die Info!

 

[Thomas_v2.1]

Hat jemand die Möglichkeit, mit TIA V13+SP1 ein paar Logfiles zu erstellen wenn er mit einer S7-1500 kommuniziert? Am Besten nur ein paar Mal die Verbindung zur CPU verbinden und trennen. Mich würde mal interessieren was Siemens da mit dem SP1 geändert hat, bezüglich:

Vulnerability 1 (CVE-2015-1601)
Attackers with access to the network path between client and server could possibly
intercept or modify Siemens industrial communications at port 102/tcp and conduct a
Man-in-the-Middle attack.

aus:
http://www.siemens.com/innovation/pool/de/forschungsfelder/siemens_security_advisory_ssa-315836.pdf

Evtl. kann man anhand der Änderungen auf einige Funktionsweisen schließen.

 

[Kall]

Ich habe das S7Comm-Plus Plugin mal ausprobiert (CPU S7-1500 <-> HMI TP700, Symbolischer Zugriff auf Variablen im DB und kein optimierter Datenbaustein, TIAv12 SP1).
Kann man mit Hilfe der Item reference number feststellen wie der Variablenname im Projekt heißt?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe das S7Comm-Plus Plugin mal ausprobiert (CPU S7-1500 <-> HMI TP700, Symbolischer Zugriff auf Variablen im DB und kein optimierter Datenbaustein, TIAv12 SP1).
Kann man mit Hilfe der Item reference number feststellen wie der Variablenname im Projekt heißt?

Theoretisch ja, praktisch so naja ;-)
Die Nummern und die zugehörigen Symbole sind in der TIA-Projektdatei wie auch in der SPS gespeichert. Nur gibt es im TIA-Portal keine (offizielle) Möglichkeit an diese IDs heranzukommen. Ich weiß nicht in wie weit Jochen Kühners Programm die TIA-Projektdatei einlesen kann, um an diese Informationen heranzukommen.

Nur über Wireshark funktioniert das nicht. Aber es gibt eine Möglichkeit die Symbolik der SPS zu browsen (z.B. mit WinCC V7.3), dort bekommt man dann den kompletten Symbolhaushalt mit IDs auch in Wireshark zu Gesicht.

 

[Kall]

Theoretisch ja, praktisch so naja ;-)
Die Nummern und die zugehörigen Symbole sind in der TIA-Projektdatei wie auch in der SPS gespeichert. Nur gibt es im TIA-Portal keine (offizielle) Möglichkeit an diese IDs heranzukommen. Ich weiß nicht in wie weit Jochen Kühners Programm die TIA-Projektdatei einlesen kann, um an diese Informationen heranzukommen.

Nur über Wireshark funktioniert das nicht. Aber es gibt eine Möglichkeit die Symbolik der SPS zu browsen (z.B. mit WinCC V7.3), dort bekommt man dann den kompletten Symbolhaushalt mit IDs auch in Wireshark zu Gesicht.

Vielen Dank für die schnelle Antwort.
Ich habe in der Zwischenzeit mal versucht mit einem Hexeditor (Ultraedit) die Item reference number im Projektfile (.pfl) zu finden. Es gibt sie dort mehrmals aber leider ist dort weit und breit der Variablenname nicht in Sicht. Der Asciiname der Variable ist auch mehrmals im File vorhanden. Da ich auf Grund der angezeigten Variablenwerte in Wireshark weiß um welchen es sich handelt ist die Zuordnung klar.
Wenn ich die Adressierungsart von symbloisch auf absolut stellen würde, würde man dann die DB Number usw. im Telegramm sehen?
Mir ist aufgefallen dass Stringvariablen als USINT-Arrays übertragen werden und dann vorne 2 Felder mehr besitzen.
Die erste Ziffer gibt die Feldlänge an und die 2. Ziffer die Anzahl der belegten Felder. Sehe ich das richtig?

 

[Thomas_v2.1]

Wenn ich die Adressierungsart von symbloisch auf absolut stellen würde, würde man dann die DB Number usw. im Telegramm sehen?

Das hängt davon ab wie der Partner auf die Daten in der SPS zugreift. Den Zugriff über LID/CRC beherrscht momentan ja nur Siemens. D.h. bei allen Nicht-Siemens-Kommunikationspartnern musst auf Absolutadressierung bzw. "nicht-optimierten Zugriff" in Siemens-Sprech wechseln. Dann wird das übliche s7comm (ohne plus) Protokoll verwendet.

Ich vermute aber mal, dass auch auf "nicht-optimierte" Bereiche über LID/CRC zugegriffen werden kann. Und dass Siemens-HMIs zum Beispiel wenn integriert immer darüber auf die SPS-Daten zugreifen werden. Ich habe das aber noch nicht getestet, kannst du ja mal machen. Was hast du denn für ein Kommunikationspartner / HMI-Software?

Mir ist aufgefallen dass Stringvariablen als USINT-Arrays übertragen werden und dann vorne 2 Felder mehr besitzen.
Die erste Ziffer gibt die Feldlänge an und die 2. Ziffer die Anzahl der belegten Felder. Sehe ich das richtig?

Beim Variablentyp String ist das so, ja. Der Aufbau ist identisch mit den Strings aus der S7-300/400er Welt.

Mit der V13 ist der Datentyp WString hinzugekommen. Hab mir das zwar noch nicht live auf dem Draht ansehen können, aber es gibt jetzt schon einen entsprechenden Datentyp bei dem diese Strings dann UTF8-codiert übertragen werden.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank für die schnelle Antwort.
Ich habe in der Zwischenzeit mal versucht mit einem Hexeditor (Ultraedit) die Item reference number im Projektfile (.pfl) zu finden. Es gibt sie dort mehrmals aber leider ist dort weit und breit der Variablenname nicht in Sicht. Der Asciiname der Variable ist auch mehrmals im File vorhanden. Da ich auf Grund der angezeigten Variablenwerte in Wireshark weiß um welchen es sich handelt ist die Zuordnung klar.
Wenn ich die Adressierungsart von symbloisch auf absolut stellen würde, würde man dann die DB Number usw. im Telegramm sehen?
Mir ist aufgefallen dass Stringvariablen als USINT-Arrays übertragen werden und dann vorne 2 Felder mehr besitzen.
Die erste Ziffer gibt die Feldlänge an und die 2. Ziffer die Anzahl der belegten Felder. Sehe ich das richtig?

Falls du dich weiter mit dem TIA File format beschäftigen willst: in dem Thread siehst du was Ich schon weiss: https://www.sps-forum.de/hochsprach...fileanalyse-tia-file-format-grammar-file.html

 

[Kall]

Das hängt davon ab wie der Partner auf die Daten in der SPS zugreift. Den Zugriff über LID/CRC beherrscht momentan ja nur Siemens. D.h. bei allen Nicht-Siemens-Kommunikationspartnern musst auf Absolutadressierung bzw. "nicht-optimierten Zugriff" in Siemens-Sprech wechseln. Dann wird das übliche s7comm (ohne plus) Protokoll verwendet.

Ich vermute aber mal, dass auch auf "nicht-optimierte" Bereiche über LID/CRC zugegriffen werden kann. Und dass Siemens-HMIs zum Beispiel wenn integriert immer darüber auf die SPS-Daten zugreifen werden. Ich habe das aber noch nicht getestet, kannst du ja mal machen. Was hast du denn für ein Kommunikationspartner / HMI-Software?

Die S7-1513-1 kommuniziert mit der HMI TP700 Comfort. Das HMI-Projekt wurde WinCC Advanced V12 SP1 erstellt.
Ich kann das gerade nicht testen werd's die Tage mal versuchen.

Bei der Kommunikation zwischen einer HMI und einer LOGO 0BA7 sieht man schön wie die HMI ein Telegramm zur Logo schickt und dort Variablen lesen will. Die Logo antwortet dann der HMI und schickt ihr die Variablenwerte.

Bei der S7Comm-Plus Kommunikation kann ich das so mit meiner Aufzeichung nicht feststellen.
Für mich sieht es so aus als ob die CPU in gewissen Abständen der HMI ein Notifikation Telegramm mit Variablenwerten schickt ohne dass die HMI das angefordert hat.
Es kommt vor dass die HMI ein Request -Funktion - Set Variable - Telegramm verschickt auf das die CPU mit einem Responce - Funktion - Set Variabe - Telegramm antwortet das wars dann schon. Hat sich da was geändert?


Ich schicke mit den S7-Kommunikationsbausteinen BSEND / BREV Daten zwischen der S7-1513-1 und der S7-1516-3 hin und her.
Wenn die S7-1513-1 mit BSend sendet erscheint das Telegramm ROSCTR:[Userdata] Function:[Request] ->:[Unknown function: 0x06]
Warum steht bei Function Request ? Die andere CPU hat das senden nicht angefordert.
S7COMM 87 ROSCTR:[Userdata] Function:[Response] ->:[Unknown function: 0x06]

 

[Thomas_v2.1]

Bei der S7Comm-Plus Kommunikation kann ich das so mit meiner Aufzeichung nicht feststellen.
Für mich sieht es so aus als ob die CPU in gewissen Abständen der HMI ein Notifikation Telegramm mit Variablenwerten schickt ohne dass die HMI das angefordert hat.
Es kommt vor dass die HMI ein Request -Funktion - Set Variable - Telegramm verschickt auf das die CPU mit einem Responce - Funktion - Set Variabe - Telegramm antwortet das wars dann schon. Hat sich da was geändert?

Das sind zyklische Variablendienste, welche es auch schon bei der S7-300/400 gab. Es gibt dabei ein Telegramm bei dem der Client bei der SPS Variablen für die zyklische Aktualisierung anmeldet. Die SPS bestätigt dieses, und schickt dann von sich aus z.B. im angeforderten Aktualisierungsintervall den Datensatz mit den Variablenwerten. Um die Zugehörigkeit festzustellen gibt es in jedem Telegramm eine Referenznummer. Um zu wissen welche Variablen in diesem Telegramm sind, muss das Telegramm gefunden werden bei dem die zyklischen Dienste für diese Referenznummer initialisiert werden.

Ich schicke mit den S7-Kommunikationsbausteinen BSEND / BREV Daten zwischen der S7-1513-1 und der S7-1516-3 hin und her.
Wenn die S7-1513-1 mit BSend sendet erscheint das Telegramm ROSCTR:[Userdata] Function:[Request] ->:[Unknown function: 0x06]
Warum steht bei Function Request ? Die andere CPU hat das senden nicht angefordert.
S7COMM 87 ROSCTR:[Userdata] Function:[Response] ->:[Unknown function: 0x06]

BSEND/BRECV ist das alte s7comm Protokoll. Die Erkennung der BSEND/BRECV-Telegramme habe ich erst vor 2 Wochen eingebaut. Ist z.Zt. nur im SVN-Repository vorhanden und noch nicht in der kompilierten dll (evtl. schon im nightly build vom offiziellen Wireshark vorhanden). Ich habe das bisher nie benötigt, darum habe ich das nicht eingebaut. Außerdem habe ich auch nicht für alle Exoten die passende Hardware zum Testen da.

 

[Kall]

Zuviel Werbung?
-> Hier kostenlos registrieren

BSEND/BRECV ist das alte s7comm Protokoll. Die Erkennung der BSEND/BRECV-Telegramme habe ich erst vor 2 Wochen eingebaut. Ist z.Zt. nur im SVN-Repository vorhanden und noch nicht in der kompilierten dll (evtl. schon im nightly build vom offiziellen Wireshark vorhanden). Ich habe das bisher nie benötigt, darum habe ich das nicht eingebaut. Außerdem habe ich auch nicht für alle Exoten die passende Hardware zum Testen da.

Ich habe gerade mal die neuste nightly ausprobiert und dort funktioniert es. Parameter: (Request) ->(PBC BSEND/BRECV) ! Super!

 

[Thomas_v2.1]

Ich bin gerade dabei die Bausteinmeldungen zu ergänzen. Nur fehlt mit zur Zeit mangels Hardware die Möglichkeit die symbolbezogenen Meldungen (SCAN) zu testen. Hat jemand evtl. ein Wireshark Log in dem diese Meldungen auftauchen?

Sonst gibt es ja so weit ich weiß nur die Varianten AlarmS (S7-300) und Alarm8 (S7-400).

 

[SiemensUser]

Ich habe gerade die aktuelle Version vom s7comm-plus plugin (s7comm-plus-0-0-2) ausprobiert. Sieht soweit gut aus.

Ich habe aber noch zwei Punkte, die ich beim 72er-Protokoll nicht verstehe:

1. Die SYM-CRC-Berechnung der symbolischen Adressen bei einer 1500er:
   Die in Jochens DotNetSiemensPLCToolBoxLibrary verwendetet Funktion zum Berechnen der CRC funktioniert nur bei 1200er Symbolen. Bei 1500er Symbolen wird eine andere Checksumme gebildet.
   Im WireShark-Mitschnitt Anhang anzeigen S7-1500-HMI_DB10_Sym.zip wird die symbolische Adresse "Variable" aus dem DB10 gelesen. Mit der ToolBox-CRC-Funktion ergibt sich der Wert "0xf7355bd6" und WireShark zeigt "0xd577798b" an.
   Hat einer von euch eine Idee, wie die CRC bei einer 1500 berechnet wird?
2. In vielen 72er-Paketen ist ein Integrity part-Paket vorhanden.
   Hier gibt es eine ID, die scheinbar immer hochgezählt wird und eine 32 Byte langes Paket ("Packet Digest")
   Was ist dies genau für ein Packet? Kann man das irgendwie berechnen?