UPX - Wer hat aktuelle Erfahrungen damit?

[Luckie]

Welche Art von Ressourcen sollen denn geschützt werden? Wenn ich eine Grafik Ressource schützen will, darf ich sie auch nicht anzeigen und dann brauche ich sie auch nicht in das Kompilat packen.

[musicman56]

Hallo Michael,

da hat du natürlich recht, bei einer Grafik macht das keinen Sinn. Wir haben ja auch von sensibleren Daten wie z.B. dem FTP-Zugang für das Online-Update gesprochen. Bleiben wir mal bei diesem Beispiel. Das FTP-Passwort muss ja irgendwann mal zur Laufzeit zugewiesen werden. Das einfachste und dümmste wäre, es gleich im Klartext in der Komponente abzulegen.

Zitat von Zacherl:

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases? Da hilft dir weder ASProtect oder noch schwereres Geschütz wie VMProtect. Ebenso unnütz ist die Verschlüsselung, da sich der Schlüssel ja wohl oder übel auch im Code befindet.

Auf meine Frage hierzu, wie man es sonst machen sollte/kann, kam leider bisher noch nichts. Wir sind uns einig, dass es keinen Schutz gibt, der nicht zu knacken ist. Es geht letztendlich nur darum, dem Angreifer das Leben ein bischen schwerer zu machen und nicht gleich das komplette Menü auf einem silbernen Tablett zu servieren. Man nimmt dem armen Hund ja sonst sein Erfolgserlebnis.

Also speichert man das Passwort verschlüsselt. Der Schlüssel für die Verschlüsselung ist natürlich auch irgendwo gespeichert. Und vielleicht noch ein Hash zur Kontrolle. Und vielleicht noch die Exe mit UPX komprimiert, oder mit AsProtect, oder was und wie auch immer, irgendwann landet das Passwort im Klartext in der Indie-Komponente (wenn man mal im einfachsten Fall von den Indie's ausgeht).

Mit jedem popeligen Debugger also kein großes Problem. Nichts verhindert eben....nur ein bischen schwerer gemacht. Womit wir vielleicht wieder ein bischen beim Sinn und Unsinn von UPX wären.

[Back2Code]

Zitat von musicman56:

Hallo Michael,

da hat du natürlich recht, bei einer Grafik macht das keinen Sinn. Wir haben ja auch von sensibleren Daten wie z.B. dem FTP-Zugang für das Online-Update gesprochen. Bleiben wir mal bei diesem Beispiel. Das FTP-Passwort muss ja irgendwann mal zur Laufzeit zugewiesen werden. Das einfachste und dümmste wäre, es gleich im Klartext in der Komponente abzulegen.

Zitat von Zacherl:

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases? Da hilft dir weder ASProtect oder noch schwereres Geschütz wie VMProtect. Ebenso unnütz ist die Verschlüsselung, da sich der Schlüssel ja wohl oder übel auch im Code befindet.

Auf meine Frage hierzu, wie man es sonst machen sollte/kann, kam leider bisher noch nichts. Wir sind uns einig, dass es keinen Schutz gibt, der nicht zu knacken ist. Es geht letztendlich nur darum, dem Angreifer das Leben ein bischen schwerer zu machen und nicht gleich das komplette Menü auf einem silbernen Tablett zu servieren. Man nimmt dem armen Hund ja sonst sein Erfolgserlebnis.

Also speichert man das Passwort verschlüsselt. Der Schlüssel für die Verschlüsselung ist natürlich auch irgendwo gespeichert. Und vielleicht noch ein Hash zur Kontrolle. Und vielleicht noch die Exe mit UPX komprimiert, oder mit AsProtect, oder was und wie auch immer, irgendwann landet das Passwort im Klartext in der Indie-Komponente (wenn man mal im einfachsten Fall von den Indie's ausgeht).

Mit jedem popeligen Debugger also kein großes Problem. Nichts verhindert eben....nur ein bischen schwerer gemacht. Womit wir vielleicht wieder ein bischen beim Sinn und Unsinn von UPX wären.

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM
- Anti Sniff
- MD5 Checksum Überprüfung
- Strings im Quelltext (Fehlermeldungen / Pfade etc verschlüsseln)

[Lemmy]

Zitat von Back2Code:

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM

Super.. genau so stelle ich mir das vor. Sobald das Programm läuft und ich in Delphi was Debuggen will springt das Teil an und blockiert mir den Rechner, weil ich meine Entwicklungsumgebung in einer VM laufen habe. Aber gut - i.d.R. gibt es ausreichend Alternativen....

Grüße

[Back2Code]

Zitat von Lemmy:

Zitat von Back2Code:

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM

Super.. genau so stelle ich mir das vor. Sobald das Programm läuft und ich in Delphi was Debuggen will springt das Teil an und blockiert mir den Rechner, weil ich meine Entwicklungsumgebung in einer VM laufen habe. Aber gut - i.d.R. gibt es ausreichend Alternativen....

Grüße

Das war eher auf Debugger wie IDA & OllyDBG bezogen ...

[Lemmy]

Zitat von Back2Code:

Das war eher auf Debugger wie IDA & OllyDBG bezogen ...

das war mir schon klar nur sollte man halt beachten, dass man mit jeder weitere Einschränkung ggf. Kunden ausschließt, die halt z.B. eine virtuelle Maschine nutzen, was aktuell immer mehr zunimmt. Und Debugger-Detection sollte dann halt nicht unbedingt ne Entwickler IDE zerschießen wenn man ein Produkt für Entwickler bereit stellt

[musicman56]

Zitat von Daniel:

Nun, wir sollten zur Ausgangsfrage zurück kommen. Es scheint mit UPX heute im Allgemeinen wohl eher keine Probleme mehr zu geben.

Den Eindruck habe ich auch, denn so richtig Stress gibt es (zumindest aktuell) wohl nicht mit UPX. Also könnte man das Thema eigentlich abhaken, wenn sich nicht noch jemand mit gravierenden neuen Erkenntnissen meldet.

Zitat von Daniel:

Welche Maßnahmen man zum Software-Schutz ergreifen kann, ist in der Tat spannend und ich bin just in diesem Moment an dieser Fragestellung in einem Projekt dran, aber das sollten wir - wenn überhaupt - separat besprechen.

Mich interessiert das Thema schon. Es gab hier (oder war es woanders, ich weiß und findes es nicht mehr) mal einen Thread der sich ausgiebig damit beschäftigt hat. Im Endeffekt läuft es wohl darauf hinaus, dass man das Debuggen so schwer wie möglich machen muss, weil nahezu alle anderen Möglichkeiten ins Leere laufen.

Als kleines Beispiel mal die Standardvorgehensweise, ein Passwort nicht inhaltlich, sondern dessen Hash zu speichern. Bei der Eingabe vergleicht man dann den Hash des Passwortes mit dem gespeicherten (womöglich verschlüsselten) Hash. Man glaubt, dass das sicher ist, weil der Hash nicht zurückberechnet werden kann. Einen Angreifer kümmert das gar nicht. Der biegt entweder die Funktion in der Echse um (dauert etwa 1 Minute und wird bei "lokal orientierten Cracks" gerne gemacht), oder nimmt einen Passwort-Pool von den meisten sagen wir mal 20 Millionen Passwörtern, generiert daraus die Hashes und schaut dann nach, welcher zum Hash passt. Das eigentliche Passwort braucht er dann gar nicht mehr. Dieser Mehraufwand wird dann praktiziert, wenn mehrere Leute in den Genuss des Zugangs kommen sollen.

Die Generierung von effektiven Schutzmechanismen nützt also nur was, wenn man genau weiß, wie Cracker/Hacker/Angreifer denken und arbeiten. Den schlimmsten Fehler den man machen kann ist glaube ich zu denken, dass man eine "sichere" Methode gefunden hat, Angreifer abzuwehren. Auch davon (oder darüber) könnte ich einige Lieder singen. Vor Jahren hatte ich z.B. mal sensible Daten in einer verschlüsselten Nexus-Datenbank gespeichert. Der Hersteller hat mir vorgerechnet, wieviel Jahre ein Angreifer über BruteForce brauchen würde, die Datenbank zu knacken. Ich glaubte mich in Sicherheit. Dann habe ich die Datenbank einem Bekannten aus England zur Überprüfung per E-Mail geschickt. Eine Viertelstunde später war die Datenbank geknackt. Die logische Erklärung warum das so schnell geht, und warum die Aussage des Herstellers nicht mal das Papier auf dem sie gedruckt war wert ist, hat mich auf den Boden der Tatsachen zurückgeholt.

Aber, das wäre dann jetzt wirklich ein eigenes Thema

[musicman56]

Zitat von Back2Code:

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM
- Anti Sniff
- MD5 Checksum Überprüfung
- Strings im Quelltext (Fehlermeldungen / Pfade etc verschlüsseln)

Absolut richtig, aber wie du schon sagst, es sind nur "Maßnahmen", also kein echter Schutz, weil es den nicht gibt

[Daniel]

Nun, wir sollten zur Ausgangsfrage zurück kommen. Es scheint mit UPX heute im Allgemeinen wohl eher keine Probleme mehr zu geben.
Welche Maßnahmen man zum Software-Schutz ergreifen kann, ist in der Tat spannend und ich bin just in diesem Moment an dieser Fragestellung in einem Projekt dran, aber das sollten wir - wenn überhaupt - separat besprechen.

[jaenicke]

Zitat von musicman56:

Also speichert man das Passwort verschlüsselt.

Ich habe das einmal (neben weiteren Maßnahmen) so gemacht, dass ein Passwort oder ähnliches an sich nicht ausreicht. Der Client ruft ein Skript auf dem Server auf und bekommt von dort Bytecode, der zur Verschlüsselung der Anforderung dient. Dieser Bytecode wird von einem kleinen Interpreter ausgeführt und ist auch nur für die nächste Anfrage gültig.
Auf diese Weise müsste ein Angreifer sehr viel Aufwand betreiben. Da der Bytecode serverseitig dynamisch generiert wird, aber clientseitig ausgeführt wird, reicht es auch nicht aus einmalig herauszufinden was der macht. Man müsste den Interpreter nachbauen und dann noch herausfinden was dort wie an Daten hereinkommt und welche davon benötigt werden.

Das war ursprünglich nur eine kleine Übung. Und für mich reichte das aus, denn wer das knacken kann, der schafft es auch alles andere zu knacken.