UPX-Packer ja oder nein?

[mensch72]

wir verwenden quasi unseren eigenen "Installer", das ist ein einmal mit echtem Zertifikat signiertes Programm, was durch alle Virentests durchgeht und auch im Sicherheitsbereich von Banken&Kraftwerken bisher immer die Freigabe bekam.

Erstaunlicher Weise erben auch ausfürbare Dateien die von diesem Prozess abgepeichert werden oft selbst lokale Rechte, mindestens aber bekommen sie nie das Flag "aus dem Inet oder von Wechselmedium heruntergeladen"... damit können wir z.B. unsere Softwareupdates relativ ungestört realisieren. Nebenbei Packen(zuerst) und verschlüsseln(dannach) wir unsere Distributionen, weil wir es bevorzugen auf allen Kundeninstallation möglichst immer die Komplettsoftware aufzuspielen. Je nach Lizenz lässt sich eben nicht alles entpacken und nutzen, aber wenn es sein muss hat unser Support Remote immer gleich alles per Codeeingabe selbst zur Verfügung (einfach hin kopieren ginge eh nicht, weil der Installer in die Programmfiles an passenden Stellen einen lokalen Systemhash einsetzt)

Standard-RunTime EXE Packer/Entpacker wie Upx nutzen wir nicht. Auf eigene/spezielle Programme, welche direkt selbst nach expand/decrypt dann per WinApi einen Speicherbereicht als "ausführbar" deglarieren und dort was anspringen, reagieren viele Sicherheitstools und Security Verantwortliche sehr allergisch.

[bra]

Zitat:

Zitat von Uwe Raabe (Beitrag 1369774)

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Das bringt aber nichts, wenn die Anwendung auch noch DLLs u.ä. aus dem Netzlaufwerk benötigt bzw. nachladen muss. Dann müsste man die ja auch alle mit lokal kopieren.

[a.def]

Zitat:

Zitat von nahpets (Beitrag 1369730)

Danke.

Kenn' ich auch nicht anders.

Mein Test zeigt

ungepackt
- Abeitsspeicher: 14,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

gepackt
- Abeitsspeicher: 23,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

[bra]

Ich habe das mal mit unserer Anwendung getestet und da ist der Unterschied deutlich zu sehen:


Ungepackt (exe 47 MB)
Max. Arbeitssatz (Speicher): 104.468K
Arbeitsspeicher (privater Arbeitssatz): 61.520K

Mit UPX gepackt (exe 18 MB)
Max. Arbeitssatz (Speicher): 137.900K
Arbeitsspeicher (privater Arbeitssatz): : 107.880K

[a.def]

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

[nahpets]

Interessant, da scheint es ja dann auch Abhängigkeiten von Programm zu Programm geben.

Bei meinen Programmen ist mir sowas bisher noch nicht aufgefallen, allerdings nutze ich UPX auch nicht mehr wirklich.

Es war interessant, als USB-Sticks noch nicht im GB-Bereich waren und vor allem zu Zeiten, als Disketten durchaus noch ein üblicher Datenträger für Rettungssysteme waren.

Aber das passt dann wohl doch besser zu diesem Thema: http://www.delphipraxis.net/192506-m...wird-wenn.html ;-)

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1369807)

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

Diese Frage bei StackOverflow gibt, trotz immer noch fehlender Antworten, einen Einblick in die dahinter steckende Komplexität: Size of exe file vs available memory

Demnach müsste der Effekt z.B. schon unterschiedlich sein, je nachdem ob Debug-Info in der EXE enthalten ist oder nicht.

[himitsu]

EXE/DLL/BPL sind standardmäßig als MMF mit CopyOnWrite in den Arbeitsspeicher gemapt. (jede der benötigten PE-Sectionen hintereinander)

Sie können also ausgelagert werden und belegen im Prozess nur den virtuellen Speicher, aber im realen Speicher sind sie vernachlässigbar.
Erst wenn ein Prozess an den gemapten Daten im RAM was ändert, bekommt er für jeweils den umgebenen 4KB-Block eine eigene Kopie.

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.
Stell dir mal vor jeder der 10000 aktiven Prozesse müsste seine eigenen Kopieen der System-DLLs in den Speicher laden.
Bei nur 1000 Prozessen wären das alleine 1,5 GB für die ntdll.dll .

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1369815)

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.

Und wenn die Exe bzw. DLL nicht mit UPX gepackt ist. Ansonsten würde jedesmal ein neuer Speicherbereich reserviert werden...

[himitsu]

Jupp, UND.

Bei UPX wird der Speicher vom Loader reserviert, beschrieben und Windows weiß nichts davon, selbst wenn ein anderes Programm das gleiche macht.
Sowas wie UPX könnte man ja nicht nur auf die EXE, sondern auch auf DLLs anwenden.