Verschlüsselung von Delphi zu SPS

[Assarbad]

Zitat:

Zitat von Friday (Beitrag 1064868)

Nein den privaten Schlüssel hätte der Kunde in diesem Fall nicht. Ich würde bei mir die Zahl mit dem privaten Schlüssel verschlüsseln, die verschlüsselte Zahl inkl. öffentlichem Schlüssel in eine Datei packen, die die Delphi Anwendung beim Kunden liest, beide Informationen an die SPS sendet und diese entschlüsselt mit dem öffentlichen Key die Zahl. Das meinte ich mit meinem "Edit".

Klingt nach asymmetrischer Verschlüsselung. Die SPS entschlüsselt also mit privatem Schlüssel und nicht wie du hier behauptest dem öffentlichen Schlüssel die Nachricht. Es wird nur der öffentliche Schlüssel des Empfängers beim Verschlüsseln und der private beim Entschlüsseln benötigt. Erst beim (zusätzlichen) Signieren braucht man die kompletten beiden Schlüsselpaare (den privaten des Senders zum Unterschreiben auf Senderseite und den öffentlichen des Senders zum Überprüfen auf Empfängerseite).

Zitat:

Zitat von Friday (Beitrag 1064868)

Dabei gehst du davon aus, dass es einfacher ist den Schlüssel und das verwendete Verschlüsselungsverfahren im disassemblierten Code raus zu lesen als eine XOR verschlüsselung zu knacken.

Allerdings, denn es gibt Heuristiken dafür.

Zitat:

Zitat von Friday (Beitrag 1064868)

Man könnte den Schlüssel ja auch zur Laufzeit aus diversen Konstanten zusammenstellen/berechnen, was es nochmals einiges schwieriger machen sollte den Code zu lesen.

Naja, mich interessiert als Reverse Engineer was rauskommt, also halte ich mich nicht mit unwichtigen Details auf. Abgesehen davon würden Konstanten die du irgendwie zusammenwürfelst im kompilierten Code im Zweifelsfalls sehr RCE-freundlich optimiert ;)

Ja, ich bin da Pragmatiker. Die meisten Reverser sind das :zwinker: ... "jedes Mittel ist recht". Egal ob aus reiner Neugier (für privat), Gier nach Ruhm (sog. "Sicherheitsforscher") oder ob nun der böse Cracker der dein Programm unfreundlicherweise kostenlos an andere weitergibt.

Zitat:

Zitat von Friday (Beitrag 1064868)

Wobei es im Grunde wie im oberen Beispiel gar nicht zwingend notwendig ist dass die Delphi Anwendung den Aktivierungscode entschlüsselt, sondern kann ihn direkt verschlüsselt an die SPS senden (Natürlich kann auch dieses Kompilat wieder gelesen werden, aber da ist es schon schwieriger ran zu kommen).

In der Tat, einfach durchreichen (ich nehme mal an irgendeine Delphi-Client/Server-Anwendung?) macht sehr viel Sinn. Aber auf die SPS kommt doch der Kunde im Zweifelsfall auch, oder gibt es das Hardwarevorkehrungen? In dem Falle wäre der private Schlüssel in der SPS ja sicher. Immer dran denken ein Reverser wird immer den Weg des geringsten Widerstandes gehen.

[divBy0]

Wenn das eine S7 ist, dann les dir doch einfach per SZL einige Informationen raus (Seriennummer, Firmware, Ausgabestand, evtl. Produktionsdatum, usw). Da gibt es schon ein paar Infos, aber sicher bekommst du das ganze nicht, zumal man das Programm ja einfach aus der SPS zurücklesen kann. Bei der S7 fehlen zwar Kommentare und Symbole aber man wird den Schlüssel finden.

[Friday]

Zitat:

Zitat von Assarbad (Beitrag 1064897)

Die SPS entschlüsselt also mit privatem Schlüssel und nicht wie du hier behauptest dem öffentlichen Schlüssel die Nachricht.

Stimmt, das hab ich verwechselt. Wäre also auch keine bessere Lösung.

Das Zusammenstellen des Schlüssels zur Laufzeit klang schon beim tippen nicht sehr vielversprechend, das wär dann wohl so ungefähr bei der Haustür Tesa-Film vors Schloss kleben und sich sicher fühlen. Aber egal, das Problem ist ja keines wenn ich die verschlüsselte Zahl direkt weiter reiche (weiss gar nicht mehr warum ich die im Delphi Programm überhaupt entschlüsseln wollte).

Zitat:

Zitat von Assarbad (Beitrag 1064897)

(ich nehme mal an irgendeine Delphi-Client/Server-Anwendung?) macht sehr viel Sinn. Aber auf die SPS kommt doch der Kunde im Zweifelsfall auch

Das ist eher eine SPS-Fernsteuerung. Ich weiss nicht wie es bei der S7 ist, aber hierbei handelt es sich um eine Steuerung von Jetter, da liegt nur der kompilierte Code drin. Den kann man mit einem FTP Client zwar downloaden, aber der ftp Zugang ist Passwortgeschützt. Sollte ein cracker dennoch an das Kompilat gelangen und das lesen und verstehen können, dann ist es auch egal, weil dann kann er auch die Sprungadresse der Stelle an der die Aktivierung abgefragt wird einfach ändern, so dass der Schlüssel komplett wertlos wird. Aber das ein Kunde soviel Energie da rein steckt kann ich mir schlecht vorstellen.

Ausser er ist vielleicht auch ein Reverser aus Passion ;)

[Assarbad]

Zitat:

Zitat von Friday (Beitrag 1064907)

Das ist eher eine SPS-Fernsteuerung. Ich weiss nicht wie es bei der S7 ist, aber hierbei handelt es sich um eine Steuerung von Jetter, da liegt nur der kompilierte Code drin.

Keine Ahnung, kenne ich leider nicht. Damals haben wir mit S7 gearbeitet.

Zitat:

Zitat von Friday (Beitrag 1064907)

Den kann man mit einem FTP Client zwar downloaden, aber der ftp Zugang ist Passwortgeschützt.

Kleine Kostprobe meiner Denkweise als Reverser? FTP ist Klartext, also schalte ich meinen Sniffer an und lade nach Eingabe von Paßwort und Benutzernamen bequem das Kompilat runter ;)

... gut gut, dann muß ich auch noch CPU usw. kennen aber im Zweifelsfall habe ich die Software dafür ja schon zur Hand (weil ich ja bspw. zur Firma gehören würde).

Zitat:

Zitat von Friday (Beitrag 1064907)

Sollte ein cracker dennoch an das Kompilat gelangen und das lesen und verstehen können, dann ist es auch egal, weil dann kann er auch die Sprungadresse der Stelle an der die Aktivierung abgefragt wird einfach ändern, so dass der Schlüssel komplett wertlos wird. Aber das ein Kunde soviel Energie da rein steckt kann ich mir schlecht vorstellen.

In der Tat. Ich vermute mal, daß rechtliche Schritte in dem Falle ohnehin besser sind. Ich wollte auch nur klarmachen, daß der Aufwand ggf. umsonst ist, da der "Schutz" den die kompliziertere XTEA-Lösung bspw. im Vergleich zu XOR bietet nicht wirklich größer ist. Also lieber mit dem Produkt überzeugen und ggf. einen Kunden ablehnen wenn einem deren Arbeitsweise nicht geheuer ist.

Viel Erfolg! ;)

[Reinhard Kern]

Zitat:

Zitat von Friday (Beitrag 1064764)

Assarbad: Richtig, dabei handelt es sich um einen Kopierschutz. Um genauer zu sein soll die Delphi Applikation eine Datei einlesen die eine verschlüsselte Zahl enthält die auf jeder SPS einmalig ist. Diese verschlüsselte Zahl soll nun auf die SPS übertragen werden, damit diese sich dann frei schalten kann.

Hallo,

du übersiehst da noch eine Gefahr von einer ganz anderen Seite: wenn das heisst, bei einem beliebigen Fehler am PC (angeblich kommt das vor) läuft eine Maschine nicht mehr nur wegen eines Kopierschutzes, die ansonsten betriebsbereit wäre, bekommst du einen Schadensersatzprozess an den Hals, den du wirtschaftlich nicht überleben wirst. Und das zu Recht.

Da du für die Funktion des Kopierschutzes rechtlich geradestehen musst, wirst du auf nicht absehbare Zeit einen 24h-Service zur sofortigen Behebung entsprechender Probleme einrichten müssen. Der Kopierschutz dient ausschliesslich deinen Interessen, der Kunde muss daher einen dadurch bedingten Ausfall keineswegs als schicksalhaft hinnehmen.

Gruss Reinhard

[Assarbad]

Zitat:

Zitat von Reinhard Kern (Beitrag 1064933)

Der Kopierschutz dient ausschliesslich deinen Interessen, der Kunde muss daher einen dadurch bedingten Ausfall keineswegs als schicksalhaft hinnehmen.

In der Tat ein interessanter Aspekt. Bin mal gespannt auf die Antwort von "Friday" ;)

[Friday]

Zitat:

Zitat von Reinhard Kern (Beitrag 1064933)

wenn das heisst, bei einem beliebigen Fehler am PC (angeblich kommt das vor) läuft eine Maschine nicht mehr nur wegen eines Kopierschutzes, die ansonsten betriebsbereit wäre

Hallo, guter Punkt,
wenn dieser beliebige Fehler eine Verbindung zwischen PC und SPS verhindert, wäre ein Teil der Funktionalität deaktiviert, richtig, aber dieser Teil ist sowieso nur in Verbindung mit dem PC verwendbar (Fernwartung/Fernsteuerung). Die Maschine an sich funktioniert auch ohne Freischaltung. Die Aktivierung soll also nur dazu dienen dass die SPS nicht mit einer Software kommuniziert die keine gültige Lizenzdatei hat. Der Fall dass die Verbindung läuft, aber nur der Kopierschutz auf einmal nicht mehr frei geschalten wird, kann nur an einem (plötzlich) falschen Freischaltcode liegen, was nur passieren könnte wenn die Lizenzdatei korrupiert wird (Virus, Festplattenhardwarefehler, ...). Von daher sehe ich da kein Problem. Dass der Kunde eine Kopie der Lizenzdatei aufbewahren sollte eigentlich selbstverständlich sein, aber kann man ja dennoch in die AGB schreiben.

Zitat:

Zitat von Assarbad (Beitrag 1064933)

Kleine Kostprobe meiner Denkweise als Reverser? FTP ist Klartext, also schalte ich meinen Sniffer an und lade nach Eingabe von Paßwort und Benutzernamen bequem das Kompilat runter

Das hatte ich übrigens nicht ganz verstanden, was hilft dir der Sniffer wenn du mit einem ftp Client vergeblich versuchst auf einen ftp Server zuzugreifen von dem du das Passowrt nicht kennst (und Benutzername auch nicht). Der Server wird nur Antworten, dass die Autorisierung fehl schlug, aber keine Daten übertragen mit denen man auf das Passwort rück schließen könnte.

[divBy0]

Eigentlich suchst du eine Möglichkeit deine Software zu schützen. Das kannst du einfach über die Seriennummer der CPU machen oder du suchst dir was anderes für deine Software (z.B. einen Dongle, usw.).

[Assarbad]

Zitat:

Zitat von divBy0 (Beitrag 1064979)

(z.B. einen Dongle, usw.).

Dongles haben eine dumme Angewohnheit. Die sind Hardware und gehen kaputt, die älteren Modelle (LPT usw.) am liebsten. Wenn man nun bspw. auf die Nutzung einer mehrere tausend Euro teuren Software angewiesen ist, und auch ein Ausfall von einigen Tagen nicht okay ist, der Hersteller sich aber querstellt, muß man sich selber helfen. Das An- und Abstöpseln des Dongles um die Software auch im "Home Office" zu nutzen hilft bei der Haltbarkeit der Hardware auch nur wenig. (Ach ja, bevor hier die Kritiker kommen. Die Nutzung im Home Office war keinesfalls aufgrund der Lizenz oder so ausgeschlossen, sondern eben mit An- und Abstöpseln des Dongles verbunden.)

Habe das dann mal für den "Eigenbedarf" (computertechnisch weitgehend unbedarftes Familienmitglied aus dem engsten Familienkreis) gemacht (vor fünf bis sieben Jahren) und einen Dongle durch Software ersetzt. Die Software läuft heute (nach Umzug) auf einem Rechner der nichtmal einen LPT hat noch immer fröhlich. Zugegeben, der Hersteller hatte dann irgendwann einen USB-Dongle als Ersatz geschickt, aber natürlich nur gegen vorherige Herausgabe des alten LPT-Dongles. Das hätte unter anderen Umständen eine zweitägige Zwangspause bedeutet. :zwinker:

Übrigens war das Knacken nicht deswegen so einfach weil das Prinzip oder die Hardware fehlerhaft ist, sondern weil die meisten Entwickler faul sind und es nicht korrekt implementieren. Wenn ich eben nur einen Wert aus dem Dongle abfrage, ist das leicht knackbar. Aber erleichtert hat es mir auch der Donglehersteller doch auch, weil die Anbindung an den Dongle eben in Software passiert und glücklicherweise über eine DLL lief, statt über statisch gelinkten Code. Im letzteren Fall hätte man vermutlich schon einen Filtertreiber schreiben müssen (was ich zuerst auch gedacht hatte). Es wurde dann nur eine DLL. Ich mußte dazu nicht ein einziges Byte der "geschützten" Software ändern und dennoch ist der Dongle jetzt in Software implementiert und der echte liegt sicher in einem Tresor :stupid:

Zitat:

Zitat von Friday (Beitrag 1064977)

Das hatte ich übrigens nicht ganz verstanden, was hilft dir der Sniffer wenn du mit einem ftp Client vergeblich versuchst auf einen ftp Server zuzugreifen von dem du das Passowrt nicht kennst (und Benutzername auch nicht). Der Server wird nur Antworten, dass die Autorisierung fehl schlug, aber keine Daten übertragen mit denen man auf das Passwort rück schließen könnte.

Das verstehe ich nun wiederum nicht. Eine Übertragung wird also bspw. bei Wartung oder so nicht benötigt? Dann würde mein Ansatz natürlich fehlschlagen.

[divBy0]

Zitat:

Zitat von Assarbad (Beitrag 1065009)

Zitat:

Zitat von divBy0 (Beitrag 1064979)

(z.B. einen Dongle, usw.).

Dongles haben eine dumme Angewohnheit. Die sind Hardware und gehen kaputt, die älteren Modelle (LPT usw.) am liebsten. Wenn man nun bspw. auf die Nutzung einer mehrere tausend Euro teuren Software angewiesen ist, und auch ein Ausfall von einigen Tagen nicht okay ist, der Hersteller sich aber querstellt, muß man sich selber helfen. Das An- und Abstöpseln des Dongles um die Software auch im "Home Office" zu nutzen hilft bei der Haltbarkeit der Hardware auch nur wenig. (Ach ja, bevor hier die Kritiker kommen. Die Nutzung im Home Office war keinesfalls aufgrund der Lizenz oder so ausgeschlossen, sondern eben mit An- und Abstöpseln des Dongles verbunden.)

Deswegen war es nur ein Vorschlag. Am sinnvollsten wird für den Einsatz die Seriennummer, usw. der SPS sein. Wenn es ja eine Fernwartungssoftware ist, dann müsste eigentlich auch Zugang zum Internet bestehen, man könnte ja vielleicht auch die Seriennummer von Programm und SPS zu einem Server schicken und dort wird es mit der Lizenz geregelt.

Aber 100% Sicherheit gibt es nicht.