TIA KnowHow Schutz TIA WINCC

[razor]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe kürzlich eine Merkwürdigkeit mit dem KnowHow Schutz von WINCC Skripten im TIA Portal entdeckt:
Ich habe mein selbst geschriebenes Skript mit einem Passwortschutz versehen. Soweit hat das auch funktioniert. Ich kann ohne Passwort nicht mehr mit dem TIA Portal zugreifen.
Allerdings habe ich auch einen Debugger installiert (Visual Studio 2017; Debugging mit Windows Script Host). Der Debugger lässt sich trotz aktiviertem KnowHow Schutz noch wie gewohnt bedienen und zeigt meinen Quellcode im Klartext an. Ich kann ihn auch noch bequem rauskopieren.

Mein System:
- TIA Portal V14 SP1 Update 6
- WinCC Advanced V14 SP1 Update 6

Keine Ahnung ob das jetzt ein Bug ist, oder ob ich blos irgendwo ein Häckchen vergessen habe.
Es wäre schön, wenn mir jemand weiterhelfen könnte.

Zur info (bevor mich jemand in der Luft zerreist ): Ich habe die selbe Frage auch im Support Forum von Siemens gestellt aber bis jetzt noch keine Antwort erhalten. Ich müsste aber das Skript schnell ausliefern, deswegen hoffe ich hier schnellere Hilfe zu bekommen.


Vielen Dank

 

[Egon323]

Ich würde da Raten evtl ein Ticket beim Support aufzumachen um das weiter zu leiten

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

vielen Dank für den Tipp er wird sicherlich einigen Instandhaltern das Leben retten

Gruß.

 

[razor]

"vielen Dank für den Tipp :wink: er wird sicherlich einigen Instandhaltern das Leben retten :wink:"

Ich hatte ja ehrlich gesagt gehofft, dass ich einfach nur ein Häckchen vergessen habe und keine Tipps verbreite wie man den Schutz umgeht.
Es ist schon traurig wie schlampig Siemens den KnowHow Schutz umgesetzt hat.

 

[razor]

Falls es jemand interessiert, hier die Antwort von Siemens:

"Wenn Sie den Knowhow-Schutz für Skripte einrichten, dann können Sie den TIA-internen Skripteditor mit dem Skript nicht mehr starten.
Wenn das Passwort korrekt vergeben ist, dann kann man das Skript bearbeiten.
Die Funktion des Knowhow-Schutzes ist damit gegeben.

Allerdings ist es nun so, dass bei einem Fehler im Skript der Debugger (wenn korrekt eingerichtet!) automatisch startet und sich aus dem Runtime-Speicher das Skript lädt.
Und da greift kein Know-how-Schutz.
Da kann man im TIA nichts daran ändern, denn vbskript wird im Betriebssystem erkannt, in den Speicher geladen (in dem Moment, in dem das Skript aufgerufen wird) und da greift sich dann der Debugger den Source-Code ab.
Das ist Betriebssystem-Verhalten.
Und deshalb sollte auf dem Kundenrechner kein Visual Studio installiert sein."


Also ich habe in meinem Berufsleben schon viel Windows Programme programmiert und auch debuggt. Das der Debugger auf den Sourcecode zugreift und man dagegen nichts machen kann ist schlicht nicht wahr.


Vielen Dank für eure Hilfe
Grüße

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man da nichts machen kann, ist es ja schon sehr ungünstig.

Nehmen wir mal an, wir haben ein TIA Programm mit KnowHow Schutz auf den Skripten, wollen diese
aber unbedingt einsehen ( aus welchem Grund auch immer ), so ist der Weg dahin ja anscheinend relativ
einfach. Ein echter KnowHow Schutz ist dies also nicht, eher eine kleine Hürde.

 

[razor]

So ist es.
Für mich sieht die Lösung jetzt so aus:

Ich schreibe mein Skript jetzt als kleines C# .net Programm und nutze das VBScript in TIA nur noch dafür die Daten zu übergeben und das Programm aufzurufen.
Dann habe ich wenigstens einen KnowHow Schutz für den man schon mal 2 -3 Tage braucht um ihn zu knacken.

Das funktioniert zum Glück für meinen Anwendungsfall wird aber sicherlich nicht für alle funktionieren.


Viele Grüße

 

[PN/DP]

Wozu braucht man bei einem Visu-Skript einen KnowHow Schutz? Wird da jemand ausspioniert und das soll niemand finden?

Harald

 

[razor]

Zuviel Werbung?
-> Hier kostenlos registrieren

"Wird da jemand ausspioniert und das soll niemand finden?"

Ja klar natürlich.

Es gibt vielfältige Gründe den KnowHow-Schutz zu benutzen. Ich bin mir nicht so ganz sicher ob ich mich über die Unterstellung aufregen soll...

In meinem Fall geht es darum Betriebsdaten verschlüsselt über Netzwerk an einen Server zu schicken. Ich bin mir nicht sicher ob es toll ist, dass jeder dahergelaufene Provinzhacker mit einem simplem Debugger mein Passwort in Klartext auslesen können soll...

Für mich ist das Thema damit beendet.

Vielen Dank

 

[PN/DP]

Ich bin mir nicht so ganz sicher ob ich mich über die Unterstellung aufregen soll...

Das sollte keine Unterstellung sein sondern eine Frage mit nicht ernst gemeinter Antwortmöglichkeit (hab wohl den Zwinker-Smiley vergessen), weil ich kann mir halt nicht vorstellen was für einen hochintelligenten Bohai es in einem Visu-Skript geben könnte, der einen funktionierenden "KnowHow"-Schutz dem Name nach wirklich verdient. Den ein Fachmann nicht durch reines Beobachten verstehen und nachprogrammieren könnte. Nach meiner Erfahrung werden mit dem sogenannten KnowHow Schutz oft nur irgendwelche Stümpereien oder Schweinereien vor den Augen von Fachleuten versteckt. Was aber in der Regel nicht wirklich schützt ...

dass jeder dahergelaufene Provinzhacker mit einem simplem Debugger mein Passwort in Klartext auslesen können soll...

Anstatt Dein Password selber wirksam zu verstecken willst Du auf ein geheimes nicht kontrollierbares fremdes Verfahren zum Verstecken Deines Passwortes vertrauen?

Ich kann mir gerade lebhaft vorstellen, daß der Provinzhacker Dein Passwort womöglich überhaupt gar nicht braucht um den verschlüsselten Datenstrom zu knacken und Passwort/Schlüssel zu rekonstruieren ...

Harald

 

[ducati]

hmm, wenn jemand an dem HMI PC sitzt hat er je eh schon Zugriff auf die geheimen Betriebsdaten, auch ohne Debugger. Wenn er nur den Netzwerkverkehr "mithoeren" kann, dann hat er keinen Zugriff auf den Debugger. Wenn die Daten so geheim sind, warum dann nicht den Kommunikationsweg per VPN schuetzen?
Also ich verstehe es nicht ganz, aber das ist oft so bei den Passwortschutzthemen.
Hoffe Du verstehst auch die Sichtweise der Kunden/Instandhalter denen nach kurzer Zeit jegliche Diagnose und Erweiterungs und Aenderungsmoeglichkeit geraubt wird, weil der tolle Programmierer von damals laengst in ner anderen Firma arbeitet oder das Passwort einfach vergessen hat....

Gruss

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich schreibe mein Skript jetzt als kleines C# .net Programm und nutze das VBScript in TIA nur noch dafür die Daten zu übergeben und das Programm aufzurufen.
Dann habe ich wenigstens einen KnowHow Schutz für den man schon mal 2 -3 Tage braucht um ihn zu knacken.

Bei einem .Net Programm kann im handumdrehen jeder den Quellcode annähernd im Originalformat wiederherstellen, inklusive Variablenbezeichnungen.

VBSkript wird von der Microsoft Skript-Runtime interpretiert. Damit ein Interpreter etwas "interpretieren" kann, benötigt er einen Quellcode.
Bei den .Net Sprachen ist das ähnlich, nur liegt das Programm dort nicht direkt im Quellcode vor, sondern es wird beim Übersetzen ein weiterer Zwischencode (Bytecode) generiert der dann in der .Net CLR ausgeführt wird. Von VB.Net und C# wird der identische Bytecode erzeugt. Und dieser Bytecode lässt sich fast ohne Verluste bis auf Kommentare) in den Ursprungscode transferieren.

Wenn du schon mal etwas am Windows PC ein Programm debuggt haben willst, dann solltest du das eigentlich wissen. Ein .Net Programm kannst du nicht mit einem Binärdebugger wie z.B. OllyDbg analysieren.