UPX - Wer hat aktuelle Erfahrungen damit?

[jaenicke]

Wofür braucht man für ein Update einen FTP-Zugang? Da reicht schlicht HTTP, ggf. mit Skripten (so ist es bei uns). Die Prüfung kann man dann über das Skript machen, je nachdem was du wie schützen willst. (Den Dateizugriff?)

[musicman56]

Hallo,

HTTP ist offen wie ein Scheunentor. Es gibt Leute wie mich, die müssen mit Updates Geld verdienen.

[Daniel]

Zitat von musicman56:

HTTP ist offen wie ein Scheunentor.

Das müsstest Du - wenn Du magst - vielleicht mal näher erläutern. HTTP(S) ist alleine für sich ja nur ein Vehikel - wie man die Daten verschlüsselt und auch server-seitig mit Requests umgeht, ist doch ein ganz anderes Thema.

Und im punto Sicherheit geben sich FTP und HTTP auf unterster Ebene nicht so furchbar viel. Eigentlich gar nichts - denn bei beiden kommt es darauf an, wie man sie nutzt.

[musicman56]

Hallo Daniel,

ich dachte hier auch weniger an das "Vehikel" - also den Transporteur - sondern an die Steuerung und Kontrolle der Zugangsberechtigungen. Derzeit verwende ich noch Filezilla (teilweise mit SSL/TLS), und da kann ich halt sehr schnell und flexibel agieren und auch reagieren, weil es mein eigener WEB-Server ist. Mit einfachen Mitteln auf der Serverseite steuern, wer was darf, Zugriff hat usw. Der Client muss nur die Zugangsdaten kennen, sonst nichts. Die Rechte vergebe ich auf dem Server, und das ist der Punkt. Und wenn ein Kunde ein neues Update gekauft und bezahlt hat, dann bekommt er in seinem Akkount eine kleine Änderung und das war's dann. Mit HTTP (und Scripts) würde das wesentlich umfangreicher, komplizierter und unsicherer. Sagt zumindest mein Sicherheitsexperte. Ich kenn mich da nicht so gut aus.

Auch mit der Protokollierung und dem Logging (wer hat wann/was runtergeladen) hab ich mit FTP eine Standard-Lösung die es mir erlaubt, die Logfiles automatisiert auszuwerten und Angriffe oder nicht autorisierte Login-Versuche schnell zu erkennen. Mit HTTP wesentlich aufwändiger.

Abgesehen davon ist meine derzeit noch praktizierte FTP-Lösung in Kürze schon Schnee von gestern. Ab 2014 laufen meine Updates über eine direkte Datenbank-Anbindung an meinen Web-Server. Dann brauche ich kein "Vehikel" mehr, dann läuft es direkt über eine mit Blowfish gesicherte und verschlüsselte TCP/IP-Verbindung. Der große Bruder muss nicht alles wissen. Aber das ist jetzt endgültog OT, oder?

[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

[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.