Wireshark Plugin für S7-Protokoll

Zuviel Werbung?
-> Hier kostenlos registrieren
Mit dem TIA Portal V14 sind auch neue Firmware Versionen herausgekommen.
Für die 1500 ist das V2.0.1 und für die 1200 V4.2. Vielleicht kann ja jemand der schon hochgerüstet hat mal ein Logfile erstellen. Mal sehen ob da wieder "geschraubt" wurde, oder ob das Protokoll an sich jetzt so stabil bleibt.
 
Unsere S7 1200 mit Firmware V4.2 arbeitet mit dem Tani OPC Server. Das betrifft auch die optimierten Bausteine. Alles arbeitet - Verbindungsaufbau, Browse der Symbole und der Datenzugriff.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe nochmal eine aktualisierte plugin-dll für das s7comm-plus Protokoll erstellt (v0.0.3)-
Damit das plugin funktioniert muss die Development-Version von Wireshark verwendet werden (v2.3), mit dem aktuellen Stable Release (2.2.3) ist das plugin nicht kompatibel.

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

Neben diversen Ergänzungen und Korrekturen, ist es jetzt möglich das "Reassemblieren" von Paketen zu deaktivieren. Das geschieht über Aufrufen des Kontextmenüs einer S7comm-plus Zeile über die Protocol Preferences. Bei großen Dateiübertragungen deren Pakete gesplittet wurden, nimmt das Reassembling nicht unerhebliche Mengen an Ram-Speicher in Anspruch.

Ein Dank geht an die Firma Tani GmbH (http://www.tanindustrie.de) für die Unterstützung mit Informationen, Logfiles, usw. Diese bieten auch einen entsprechenden Protokolltreiber für die 1200/1500 an.
 
INAT -> Tani

Tani inaT so wirklich verloren geht in der Branche offensichtlich kaum jemand ...
Nein, niemand geht verloren, bei der Tani sind alle Entwickler die bei INAT schon die Produkte erstellt haben. Die Produkte sind von Grund auf neu entwickelt, alle guten Dinge sind noch da und alle Altlasten und unschöne Designs weg. So geht die S7 1500 in allen Ausprägungen, und das arbeitet auch auf dem raspberry PI und ähnlichen Geräten. Es ist eben am Puls der Automatisierung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
s7comm-plus mit wireshark Sourcen synchron halten

Ich habe nochmal eine aktualisierte plugin-dll für das s7comm-plus Protokoll erstellt (v0.0.3)-
Damit das plugin funktioniert muss die Development-Version von Wireshark verwendet werden (v2.3), mit dem aktuellen Stable Release (2.2.3) ist das plugin nicht kompatibel.

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

Hallo,

um bequemer das Plugin mit den dazu passenden Wireshark-Sourcen bauen zu können, habe ich auf github folgendes Clones:
https://github.com/JuergenKosel/wireshark.git und https://github.com/JuergenKosel/s7commwireshark.
Das wireshark Repository bindet das s7comm-plus Repository als git-submodule ein. Unter Linux werden die Sourcen als symbolische Links an die richtigen Stellen im Wireshark-Source-Tree eingebunden.
Ob das unter Windows funktioniert, habe ich nicht ausprobiert.

Unter Linux kann dann Wireshark mit dem Plugin wie folgt gebaut werden:

git clone https://github.com/JuergenKosel/wireshark.git wireshark
cd wireshark
git checkout s7commwireshark
git submodule update --init
autoreconf --install
./configure
make -j`nproc`

Gruß
Juergi
 
Ich habe nochmal eine aktualisierte plugin-dll für das s7comm-plus Protokoll erstellt (v0.0.3)-
Damit das plugin funktioniert muss die Development-Version von Wireshark verwendet werden (v2.3), mit dem aktuellen Stable Release (2.2.3) ist das plugin nicht kompatibel.

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

Hallo,
ich habe das s7comm_plus x64 Plugin heruntergeladen und in den Plug-In-Ordner "C:\Program Files\Wireshark\plugins\2.3.0-2199-gec38330" kopiert. Vorher hatte ich die Delopment-Version 2.3.0-2199 64Bit heruntergeladen und unter meinem Windows 10 x64 installiert.
Beim Starten von Wireshark kommt nun die Fehlermeldung
"The procedure entry point tvb_new_subset could not be located in the dynamic lik library C:\Program Files\Wireshark\plugins\2.3.0-2199-gec38330\s7comm_plus.dll"
Danach kommt noch eine zweite Fehlermeldung: "Couldn`n load module C:\Program Files\Wireshark\plugins\2.3.0-2199-gec38330\s7comm_plus.dll Die angegebene Prozedur wurde nicht gefunden.

Könntet Ihr mir einen Tipp geben, was ich falsch gemacht habe?

Gruß yogi
 
Hi,

es wurde Anfang Januar an der Wireshark-Api etwas geändert, darum funktioniert die dll die ich damals erzeugt habe nicht mehr mit der letzten Version. Wenn du noch eine Version hast die ca. vor dem 10. Januar oder so erstellt wurde, dann müsstest du diese wieder installieren. Leider lassen sich auf der Wireshark Seite nur die Development Versionen der letzten paar Tage herunterladen.

Ich habe die Quellen schon dahingehend angepasst, aber noch nicht neu übersetzt. Kann natürlich immer wieder passieren dass etwas geändert wird, zumindest solange ich da im Entwicklungs-Zweig bin.
Wenn du bis heute Abend warten kannst, dann kann ich die dlls für die aktuellste Version erstellen.
 
Es gibt jetzt auf der Sourceforge-Seite eine Version 0.0.3.1 der s7comm_plus.dll die wieder mit der aktuellsten Version funktioniert.

Allerdings nicht mehr mit einer Version von vor 10. Jan 2017. Wahrscheinlich im Sommer wird die 2.3 von Wireshark zu 2.4, dann bleibe ich erst mal auf dieser Version. Bis dahin kann das gelegentlich vorkommen.
 
Hallo Thomas_v2.1,
ich habe das Plugin nun einmal ausprobieren können, es funktioniert jetzt prima.
Bei der Gelegenheit muss ich einfach einmal für die gute Arbeit Danke sagen, ich kann mir gut vorstellen, dass für die Analyse und Umsetzung viele viele Feierabende ins Land gingen.

Also von mir hast Du für dieses Tool den vollsten R E S P E K T :TOOL:

Grüße yogi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei der Gelegenheit muss ich einfach einmal für die gute Arbeit Danke sagen, ich kann mir gut vorstellen, dass für die Analyse und Umsetzung viele viele Feierabende ins Land gingen.

Sowas macht man Nachts ;-)
Aber hat auch Spaß gemacht. Wenn man mal lange Zeit absolut nicht weiterkommt, und dann hat man eine Idee, sozusagen den Stein von Rosetta und dann gehts weiter...

Das traurige ist allerdings auch wenn ich weiß wie es prinzipiell funktioniert, das Erstellen eines Treibers dafür immer noch ein nicht unerheblicher Aufwand ist. Zumindest ist das nicht mit einem Treiber für die S7-300/400 zu vergleichen, da liegen bestimmt 1-2 Größenordnungen gemessen an Codezeilen dazwischen. Eine Minimalversion für die 300er nur um Variablen über Ethernet zu lesen bekomme ich in C in ~100 Codezeilen hin. Für die 1500 würde ich da eher 5000-10000 Zeilen ansetzen, und das ohne die notwendigen Crypto-Bibliotheken. Das Problem ist, du kannst da nicht mit einer Minimalversion die nur Variablen lesen kann anfangen, sondern musst gleich "fast" alles verstehen.

Und aufgrund der Authentifizierungsmethode, würde ich das niemals nachverfolgbar unter meinem Namen veröffentlichen. Meiner Meinung nach ist das ist mit Absicht so konstruiert worden, dass es schwer sein dürfte zu behaupten an die Methode ohne Reverse-Engineering des Quellcodes gelangt zu sein. Den einzigen Ausweg den es da geben könnte, ist über das womögliche Monopol von Siemens in dem Bereich. Aber ich habe keine Lust mich in der Freizeit detailliert mit Rechtsangelegenheiten zu befassen.
 
Aufwand S7 1500 Treiber

Sowas macht man Nachts ;-)
Aber hat auch Spaß gemacht. Wenn man mal lange Zeit absolut nicht weiterkommt, und dann hat man eine Idee, sozusagen den Stein von Rosetta und dann gehts weiter...

Das traurige ist allerdings auch wenn ich weiß wie es prinzipiell funktioniert, das Erstellen eines Treibers dafür immer noch ein nicht unerheblicher Aufwand ist. Zumindest ist das nicht mit einem Treiber für die S7-300/400 zu vergleichen, da liegen bestimmt 1-2 Größenordnungen gemessen an Codezeilen dazwischen. Eine Minimalversion für die 300er nur um Variablen über Ethernet zu lesen bekomme ich in C in ~100 Codezeilen hin. Für die 1500 würde ich da eher 5000-10000 Zeilen ansetzen, und das ohne die notwendigen Crypto-Bibliotheken. Das Problem ist, du kannst da nicht mit einer Minimalversion die nur Variablen lesen kann anfangen, sondern musst gleich "fast" alles verstehen.

Und aufgrund der Authentifizierungsmethode, würde ich das niemals nachverfolgbar unter meinem Namen veröffentlichen. Meiner Meinung nach ist das ist mit Absicht so konstruiert worden, dass es schwer sein dürfte zu behaupten an die Methode ohne Reverse-Engineering des Quellcodes gelangt zu sein. Den einzigen Ausweg den es da geben könnte, ist über das womögliche Monopol von Siemens in dem Bereich. Aber ich habe keine Lust mich in der Freizeit detailliert mit Rechtsangelegenheiten zu befassen.

Das mit der Idee in der Nacht ist auch bei mir so. Aber sonst ist es viel Arbeit, oft in Details. Wissen über die interne Arbeistweise einer Steuerung ist notwendig.
Ein SPS Protokoll präsentiert immer die interne SPS, das war schon bei der 300er oder der S5 der Fall. Sichtbar ist das in den SZLs und beim Bausteinlesen - die Bausteinköpfe zeigen das. Hilfreich ist es auch mal eine Softsps erstellt zu haben bzw mit Leuten die das machen sich auszutauschen (IBH Softec, Process Informatik, ABCIT). Mit diesem Wissen ist ein Protokoll nachzubauen - ohne Disassemblieren irgendwelchen Codes.
Ein reiner S7 1500 Protokolltreiber hat ohne Cryptlib ca 5000 Zeilen. Mit Online Browsen sind es ca 8000. Mit kompletten SPS Stati, Hardwareausbau sind es ca 12000. Soll die S7 1500 auch programmiert werden so liegen im Protokoll und dem Datenmanegement ca 18000 Zeilen C Code. Dieser Code läuft dann aber über all, auch im Raspberry PI. Damit kann dann ein komplettes SPS Backup erstellt und wieder in die SPS zurückgespielt werden, oder es werden SPS Programme mit Codegeneratoren erstellt.
Das Gleiche für die Rockwell ControlLogix sieht gleich aus, und es hat auch die gleichen Funktionen. Rockwell ist zwar etwas offener mit Informationen, um die SPS zu programmieren hilft das aber nicht.
Zusätzlich hilft Wissen über FPGA und deren Programmierung. Vieles aus den SPS Protokollen bildet solche Hardwarebausteine ab.

So sind all die Tani SPS Treiber entstanden, und so sind seinerzeit auch die INAT Treiber gebaut worden.

Vielen Dank auch für die gute Unterstützung mit der ständigen Weiterentwicklung des S7 1500 Dissektors. Es ist das klassische Beispiel guter Zusammenarbeit. Jeder hilft dem Anderen.
 
Ein reiner S7 1500 Protokolltreiber hat ohne Cryptlib ca 5000 Zeilen. Mit Online Browsen sind es ca 8000. Mit kompletten SPS Stati, Hardwareausbau sind es ca 12000. Soll die S7 1500 auch programmiert werden so liegen im Protokoll und dem Datenmanegement ca 18000 Zeilen C Code. Dieser Code läuft dann aber über all, auch im Raspberry PI. Damit kann dann ein komplettes SPS Backup erstellt und wieder in die SPS zurückgespielt werden, oder es werden SPS Programme mit Codegeneratoren erstellt.

Hast du den Treiber schon gemacht? die Codenzeilenangaben von dir kommt mir reichlich kurz vor - für ein Stream-Protokoll, mit Fehlerprüfung usw.
und ein S7-Treiber (fuer ein Bus-Protokoll fixer Länge) hat dann nur noch 500 Zeilen oder was?
Wie kommst du auf die Zahlen?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, das Protokoll existiert - im Tani OPC Server oder der PLC Engine. Damit browsen wir die S7 1500 Familie, lesen und schreiben OPC Daten, lesen auch das SPS Programm und viele der internen Dinge der SPS die OPC Nutzer interessieren. Für bestimmte Anwender lesen wir das gesamte SPS Programm inclusive der Hardwarekonfiguration und all dem anderen Zeugs aus der SPS.
SPS Programmcodeschreiben vermarkten wir nicht, das dient nur dem Verständnis der SPS. FC oder OBs schreiben wir nur um unser Verstädnis zu testen, eine Programmiersoftware ist kein Markt. Zum Spielen und Verständnis erweitern ist das aber ideal.
Sie können die Programme testen, nach dem Start laufen sie ohne Lizenz nach jedem Start für drei Tage.
 
trotzdem ein bisschen wenig Code dafür - aber die Details sind auch nicht sooo wichtig

SPS Programmcodeschreiben vermarkten wir nicht, das dient nur dem Verständnis der SPS. FC oder OBs schreiben wir nur um unser Verstädnis zu testen, eine Programmiersoftware ist kein Markt. Zum Spielen und Verständnis erweitern ist das aber ideal.

vielleicht baut ihr ja mal ein Closed-Source-Tool/Lib mit dem Thomas 1200/1500 Programmblöcke lesen/schreiben kann
damals (Der S7-1200 unter den Rock geschaut) hat ihn ja die Verschluesselung ausgebremst :)
 
Thomas sein Knackpunkt ist das die "Verschlüsselung" nur mit einer über Anfrage/Antwort laufende Telegrammverfolgung arbeiten kann. Ein Wireshark Decoder enthält aber trotz Streamverfolgung normalerweise keine SPS State Machine - denn dann baut ja fast eine S7 1500 kompatible Softsps nach.

Ein Closed Source Stück Software zum SPS Programmcodeschreiben - auch wenn wir das haben - ist aus meiner Sicht zu gefährlich um das in die Wildnis zu entlassen. Anlagenhacking wollen wir nicht unterstützen.
Die einzige sichere Abwehr bei der 1500 dagegen ist es die SPSsen komplett mit Kennwort oder Zertifikaten zu schützen. Das funktioniert wunderbar, es macht aber dem Support und der Instandhaltung die Arbeit sehr schwer. Sicherheit ist in diesem Fall entweder kontraproduktiv (jede SPS hat ihr eigenes Kennwort, und das ändert sich auch nmanchmal, die Instandhaltung kann nichts instandhalten), oder unsicher (alle SPSsen gleich, alle Instandhalter und SPS Programmierer kennen das Kennwort oder haben das Zertifikat).
Thomas bekommt Unterstützung wenn er das braucht. So ist es auch in der Vergangenheit gelaufen. Er hilft uns, und wir helfen Thomas. Auf diesem Weg ist der 1500 Dissektor so geworden wie er heute ist. Und er wird ständig besser dank Austausch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bräuchte mal eine kreative Eingabe:
Es werden einige Objekte allem Anschein nach irgendwie komprimiert übertragen. Als einfachstes Beispiel zum Testen habe ich mir mal die Netzwerktitel herausgepickt, weil sich da recht einfach diverse Texte ausprobieren lassen.

Die Werte:
Code:
a           98000002787d845fc605c3081dfc919888ddb3002c70173a
aa          98000002787d845fc605c3081dfc91989888ddb70044a6179b
aaa         98000002787d845fc605c3081dfc9198989888ddbb005d3d17fc
aaaa        98000002787d845fc605c3081dfc91980804d8fd0b007635185d
aaaaa       98000002787d845fc605c3081dfc91980802d83d0c008f8e18be
aaaaaa      98000002787d845fc605c3081dfc91980806d87d0c00a948191f
aaaaaaa     98000002787d845fc605c3081dfc91980801d8bd0c00c3631980
aaaaaaaa    98000002787d845fc605c3081dfc91980805d8fd0c00dddf19e1
aaaaaaaaa   98000002787d845fc605c3081dfc91980803d83d0d00f8bc1a42
aaaaaaaaaa  98000002787d845fc605c3081dfc91980807d87d0d0014091aa3
aaaaaaaaaa  98000002787d845fc605c3081dfc91980807d87d0d0014091aa3
bbbbbbbbbb  98000002787d845fc605c3081dfc91980407d87d0d00151c1aad
cccccccccc  98000002787d845fc605c3081dfc91980c07d87d0d00162f1ab7
ab          98000002787d845fc605c3081dfc91989884ddb70044bd179c
abc         98000002787d845fc605c3081dfc919898948cddbb005d8317ff
abcd        98000002787d845fc605c3081dfc919898948cc3bf0076c31863
abcde       98000002787d845fc605c3081dfc919898949c928addc300907e18c8
abcdef      98000002787d845fc605c3081dfc919898949c929a86ddc700aab5192e
abcdefg     98000002787d845fc605c3081dfc919898949c929a968eddcb00c5691995
abcdefgh    98000002787d845fc605c3081dfc919898949c929a969e81ddcf00e09b19fd
Da mehrfaches Verwenden des gleichen Zeichens die Daten nicht länger werden lassen, gehe ich mal davon aus dass es komprimiert wurde.

Ein bekannter Header von gzip findet sich auf den ersten Blick nicht wieder. Ich habe auch schon mal verglichen welche Werte ich erhalten wenn ich die Texte mit gzip oder deflate komprimiere, aber da komme ich auch auf kein Ergebnis.

Die ersten 5 Bytes mit 9800000278 werden so auch von anderen Objekten übertragen.
 
zip

Es ist Zip mit Dictionary. Wenn die Dictionaries bekannt sind kann das entpackt werden. Es gibt viele Dictionaries, bei den vielen XML macht das auch Sinn. Die Dictionaries ausprobieren ist mit wem Wissen das es XML ist zwar Arbeit aber wir haben es geschafft. Später mehr. Rockwell macht das ähnlich
 
Ok, dann ist 0x787d wohl doch der zlib Header. Ohne Wörterbuch kann dann ja bei mir auch nichts rauskommen.

CM (Compression method) = 8 = deflate
CINFO (Compression info) = 7 = indicates a 32K window size

FCHECK (check bits for CMF and FLG) = 0xd
FDICT (preset dictionary) = true
FLEVEL (compression level) = 1 = compressor used fast algorithm
 
Zurück
Oben