Wireshark Plugin für S7-Protokoll

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich habe mal etwas Zeit gefunden um ein Wireshark Plugin für das S7-Protokoll zu schreiben.

Die entsprechende s7comm.dll befindet sich im Anhang.
Diese muss ich das plugin Verzeichnis von Wireshark kopiert werden. Im Normalfall ist das
C:\Programme\Wireshark\plugins\
und dann die Versionsnummer (aktuell ist 1.0.8).

Über eine Heuristik versucht das Plugin in den Nutzdaten des überlagerten COTP (ISO 8073) Protokolls ein S7-Telegramm zu erkennen.

Das Telegramm wird dann in Header, Parameter und Data-Teil zerlegt.

Der Datenaustausch über Read-Request/Response und Write-Request/Response wird noch weiter bis hin zu den
SPS-Adressen aufgeschlüsselt. Die SPS-Adressen werden wie ein ANY-Pointer in Step 7 dargestellt (z.B. DB5.DBX0.0 BYTE 5).

Dies ist die Kommunikation die üblicherweise zwischen Visualisierung und der SPS
abläuft. Diese wird mehr oder weniger komplett aufgeschlüsselt.

Ein paar Teile konnte ich noch nicht entschlüsseln, wie:
- Header: Bytes 3,4 Reserve?
- Parameter bei "Negotioate PDU Length", Bytes 2-6


Eine große Frage stellt sich mir bei User-Data PDUs.
Da es hier eine schier unendliche Anzahl an Telegrammen zu geben scheint, habe ich es erstmal dabei
belassen nur in Header/Paramater/Data aufzusplitten.
Man könnte die bekannten Teile sicher noch in Details auflösen, aber ich weiß nicht ob das wirklich Sinn macht.
Oder es gibt dort eine Struktur die ich noch nicht erkannt habe.


Wenn jemand die Quellen haben möchte bitte PN an mich.
Mit diesen sollte sich das Plugin auch für Wireshark unter Linux erstellen lassen (kann ich leider nicht testen, ein entsprechendes makefile
ist aber enthalten).

Gruß
Thomas

 

[Thomas_v2.1]

Hüst, ich komm mit meinen VMs noch durcheinander. Im Anhang die letzte Version.

 

[Human]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

hab mir das mal heruntergeladen und in den Ordner C:\Programme\Wireshark\plugins\1.0.8\ kopiert.

Nach dem Starten von Wireshark bekomme ich immer die Meldung:

Could'nt load module C:\Programme\Wireshark\plugins\1.0.8\s7comm.dll: Das angegebene Modul wurde nicht gefunden.

Muss ich da noch irgendwo was einstellen?

 

[Thomas_v2.1]

Hi,

hab mir das mal heruntergeladen und in den Ordner C:\Programme\Wireshark\plugins\1.0.8\ kopiert.

Nach dem Starten von Wireshark bekomme ich immer die Meldung:

Could'nt load module C:\Programme\Wireshark\plugins\1.0.8\s7comm.dll: Das angegebene Modul wurde nicht gefunden.

Muss ich da noch irgendwo was einstellen?

Ja, leider :-(

Das Problem ist, dass das offizielle Wireshark Release mit VC6 erstellt wurde, ich die dll aber mit VC2008 erstellt habe. Auf meinen Testrechnern mit Windows 2000 funktionierte das klaglos, auf einem XP-Rechner hatte ich aber die gleiche Meldung.

Lösung:
- Es muss das Redistributable Package von Microsoft installiert werden.
http://www.microsoft.com/downloads/...34-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en
In der angehängten s7comm.dll habe ich diese Manifest Informationen integriert.

Damit funktioniert es.

Vielleicht lässt sich noch jemand mit VC6 auftreiben der die dll damit erstellt.

Dll-Hell sozusagen....

 

[Zottel]

Ich probiere es gerade mal aus.
Hinter den Daten erscheint folgende Fehlermeldung:
[Dissector bug, protocol S7COMM: proto.c:1378: failed assertion "hfinfo->type == FT_BYTES"]
Mein Wireshark ist möglicherweise etwas alt: Version 0.99.6a (SVN Rev 22276)

 

[Zottel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und weiter:
Ich lasse 5 "Items" lesen. (Libnodave-Benchmark Teil 3).
Es erscheint richtig unter Parameter:
Funtion read (4)
Item count: 5
Danach wird aber nur das 1. Item aufgeführt.
In diesem werden wiederum 6 Bytes Daten aufgeführt (richtig), aber nur die ersten beiden Bytes werden im Hex-Dump markiert.

 

[Thomas_v2.1]

Und weiter:
Ich lasse 5 "Items" lesen. (Libnodave-Benchmark Teil 3).
Es erscheint richtig unter Parameter:
Funtion read (4)
Item count: 5
Danach wird aber nur das 1. Item aufgeführt.
In diesem werden wiederum 6 Bytes Daten aufgeführt (richtig), aber nur die ersten beiden Bytes werden im Hex-Dump markiert.

Hallo,
meinst du mit Benchmark "testISO_TCP.exe -b"?
Das habe ich bei mir mal durchlaufen lassen (übrigens gut zum testen, habe ich garnicht dran gedacht) und bei mir sieht soweit alles OK aus. Ab Sequenz-Nr. 202 fängt der Test mit 5 Items an, und da passt es eigentlich beim Request und beim Response.

Gibts es Siemens intern einen anderen Namen für meine "Items"?

 

[Jochen Kühner]

an Wireshark schicken??

Ist es nicht möglich das Plugin direkt an die Wireshark entwickler zu schicken, so ist's beim nächsten Release gleich dabei??

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist es nicht möglich das Plugin direkt an die Wireshark entwickler zu schicken, so ist's beim nächsten Release gleich dabei??

Da die S7-Kommunikation ja kein offenes/dokumentiertes Protokoll ist glaube ich nicht dass die sich da was von annehmen.
In einem offiziellen Wireshark-Release sollten mMn nur wirklich 100% vollständige Protokolle vorhanden sein.
Aber vielleicht lässt sich die Vollständigkeit bei diesem Plugin ja noch etwas erhöhen.

 

[Thomas_v2.1]

So, ich konnte doch noch einen Visual C++ 6.0 Compilier auftreiben.
Jetzt lässt sich das Plugin auch ohne das Redistributable Package in der aktuellen Wireshark Version verwenden.
Also einfach die s7comm.dll in das plugin Verzeichnis kopieren und lüppt

Zusätzlich habe ich die Userdata-Telegramme etwas weiter aufgeschlüsselt. Bei SZL Anfragen werden die angefragte ID und der Index angezeigt. Zumindest beim Request - ein Response hat eine etwas andere Struktur.

Bei der Darstellung der Daten in den Userdata war auch noch ein Fehler wie Zottel schon schrieb.

So ein paar "unbekannte" Größen sind jedoch noch vorhanden, vielleicht lassen sich diese mit der Zeit noch auflösen.

Im Anhang einmal die reine dll und die Quellen (src) zum Plugin selberbacken.

 

[Thomas_v2.1]

Ich habe mal versucht in die Userdata-Telegramme eine Struktur "hineinzuinterpretieren".
Gerade diese Telegramme sind eigentlich recht interessant weil hierüber die ganzen PG-Funktionen abgewickelt werden.

Ein Request hat immer 8 Bytes Parameter-Länge, ein Response immer 12 Bytes Parameter-Länge.
Meine Beschreibung wäre soweit:

00 01 12 xx 1x xy xx xx .. .. .. ..
 |  |  |  |  |  |  |  |  |  |  |  |
 |  |  |  |  |  |  |  |  Sind immer Null, nur bei 12 Byte Telegrammen vorhanden
 |  |  |  |  |  |  |  xx -> Subnummer, oder fortlaufende Numerierung der Pakete?
 |  |  |  |  |  |  xx -> Sub-Funktionsnummer (abhängig von Funktionsgruppe)
 |  |  |  |  |  x=0 Folgetelegramm?, x=4 -> Request, x=8 -> Response, anscheinend immer
 |  |  |  |  |  y= Funktionsgruppe? 1=Programmier Kommandos (Force/Erase), 3=Block Funktionen, 4=SZL-Kommandos
 |  |  |  |  |  5=Security? (CPU-Passwort), 7=Zeit Funktionen,
 |  |  |  |  x=1-> Request, x=2 -> Response, außer bei Programmer commands
 |  |  |  Länge der folgenden restlichen Parameter (4 oder 8)
 |  |  Konstant 12
 |  Konstant 01
 Konstant 00

Eigentlich sieht diese Unterteilung in Funktionsgruppen und Unterfunktionen ganz schlüssig aus, kann aber auch sein dass sich die Siemensianer was ganz anderes dabei gedacht haben.

Ich habe das in das plugin schon soweit integriert, im Anhang ein Screenshot wie das dann aussehen würde.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der angehängten Version werden noch mehr Daten aufgeschlüsselt, wie z.B. SZL Anfragen, Block Informationen, CPU Befehle und Uhrzeit stellen/lesen.

Viele Stellen sind zwar weiterhin unklar, aber das meiste was ich von PG aus an Befehlen machen konnte wird zumindest ohne Fehler aufgelistet.
Die Info-Zeile ist bei manchen Funktionen jetzt etwas lang geworden, aber Breitbild ist ja in Mode.

Was mir seltsam vorkommt, dass es so viele verschiedene Formate in dem Protokoll gibt.
Mal wird eine Blocknummer als ASCII, mal als Word übertragen. Dann gibt es mindestens zwei verschiedene Arten einen Zeitstempel zu übertragen. Warum man sowas macht ist mir schleierhaft. Oder das sind noch Leichen aus alten S5-Zeiten.

 

[cboerm]

Ich habe das Plugin angewendet, alles läuft super.
Beim analysieren der Daten ist mir ein Problem aufgetreten.
Ich habe laufend Anforderungen (Request) und Antworten (Response) die Wireshark aufzeichnet. In der Anforderung steht immer z.B. (DB2.DBX12.0 BYTE120). In den Antworten steht das aber nicht mehr. Woher weiß ich, welche der vielen Antworten zu einer bestimmten Anforderung gehört? Ich hoffe jemand kann mir helfen!!

 

[Rainer Hönle]

Einfach nach der passenden sequence number schauen.

 

[cboerm]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die sequence number ist bei mir aber immer eins oder null. Gibt es da noch eine andere Möglichkeit?

Im Anhang befindet sich die Wiresharkdatei. In dem Filter muss man folgendes eingeben:
ip.addr == 192.168.157.192 && s7comm

Vorraussetzung ist natürlich, das man das S7-Plugin installiert hat.

 

[Rainer Hönle]

Wie es aussieht, sind nie mehr als zwei Pakete unterwegs. Diese haben dann unterschiedliche sequence numbers. Das Response-Paket mit 0 gehört immer zum vorigen Request mit 0, das Response-Paket mit 1 gehört immer zum vorigen Request mit 1. Die Zuordnung ist somit eindeutig.
Nur ne Frage am Rande: welche Software kommuniziert da? Wie sieht der Connection Request / Connection Confirm aus?

 

[cboerm]

Danke für deine Hilfe.

Zu deiner Frage, die Kommunikation findet zwischen einer SPS (192.168.157.192) und einer über eine VMWare (192.168.157.245) laufende Visualisierung (Wonderware) statt.

 

[cboerm]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe nach dem ich weiß, welche Anfrage zu welcher Antwort gehört,noch eine Frage.

Und zwar ist es möglich aus der Antwort (Response) den Ursprung der Daten zu erkennen?

Bsp.ie Anfrage möchte Daten aus dem DB2.DBX 222.0 Byte 202 haben. Es folgt eine Antwort mit den angeforderten Daten. Kann man hieraus erkennen, aus welchem DB(Quelle) die Daten geschickt wurden?

 

[Rainer Hönle]

Nein, das sieht man nur aus der Anfrage.

 

[shotar]

Tolle Sache! Ich habe auf der Arbeit allerdings nur Ethereal.. morgen mal gucken obs damit auch geht..

Mal grundsätzlichen Fragen:
Wenn ich alles richtig verstehe nutzen Programme wie z.B. Libnodave ein geheimes Siemens Protokoll? Ich dachte den Aufbau ISO on TCP (RFC 1006) Telegrammen kann man offen nachlesen? Ich vertehe das nicht so ganz...

Also wie läuft die Kommunikation zw. Libnodave und SPS genau ab? Ist das ähnlich wie TCPIP über Handshake usw?