Warum PE-Packer sehr fragwürdig sind ...

[Olli]

Da ja immer wieder versucht wird Leuten zu erklären wieso PE-Packer sehr fragwürdig sind, habe ich mich dazu entschlossen dies mal in anschauliche Form zu bringen. In dieser kurzen Abhandlung wird PE und EXE synonym verwendet. Es basiert auf einem fiktiven Beispiel um anhand von jeweiligen Rechnungen des Speicherverbrauchs vor der Ausführung der eigentlichen Datei (oder im gepackten Fall, Ursprungsdatei) die Nachteile zu verdeutlichen. Es ist völlig egal ob hier EXE-Packer oder EXe-Crypter besprochen werden, sie nehmen sich nichts!

Betrachtung für EXEs (PE)

Nehmen wir mal folgendes Szenario an. Wir haben eine 1 MB große EXE-Datei. Wir betrachten nur die Datei und nicht den Speicher, den der Prozess (im gepackten Fall, nach dem Entpacken) belegt!

Die Datei liegt einmal gepackt (0,3 MB) und einmal ungepackt (1 MB) vor. Nun wird sie vom PE-Loader jeweils einmal geladen.

Die ungepackte EXE enthält Segmente, die der PE-Loader ignoriert und nicht in den RAM lädt, sondern auf der Platte beläßt. Also lädt der PE-Loader 0,2 MB weniger -> das lauffähige Image der EXE im Speicher ist also 0,8 MB groß.

Nun die gepackte EXE. Da wir alles vor dem Entpacken besprechen, bitte ich zu beachten, daß sich die Allozierung im folgenden eben darauf bezieht!!! Die gepackte EXE wird also vom PE-Loader geladen. Da der Packer alles bestens ausnutzt, wird die EXE komplett in den Speicher geladen -> 0,3 MB.
Danach beginnt der enthaltene Entpacker Speicher in Größer der ursprünglichen Datei zu allozieren und die ursprüngliche EXE im Speicher dorthin zu entpacken -> 1 MB.
Macht summa summarum 1,3 MB.

Vergleich in meinem Beispiel -> 0,8 MB vs. 1,3 MB.

Wenn man das jetzt auf andere Dateigrößen hochrechnet wird's böse ...

Ich hoffe der Unterschied wird nun etwas deutlicher. Bei EXE-Cryptern ist es analog!!!

Betrachtung für DLLs

Und jetzt besprechen wir das Ganze nochmal für DLLs. Eine DLL ist immer eine Datei, deren Code im Kontext von einem Prozess ausgeführt wird. Nun ist es gerade so, daß sich unter NT alle Prozesse dieselbe Kopie einer DLL teilen, es sei denn, ein Prozess verändert Speicherseiten innerhalb dieser DLL (also innerhalb des gemappten Images). In diesem Fall (Copy-on-Write) wird die entsprechende Speicherseite für den entsprechenden Prozess kopiert und sie gehört nur ihm (er teilt sie sich also nicht mit anderen Prozessen!).

Wenn wir also einen Prozeß haben, der eine 0,5 MB große DLL benutzt, wird die DLL (xyz.dll) im schlechtesten Fall 0,5 MB Speicherplatz belegen. Wenn wir einhundert Prozesse haben, die die xyz.dll benutzen, wird der Speicherverbrauch im besten Fall bei 0,5 MB liegen (wenn man mal nur die DLL betrachtet!!!), statt bei 100 * 0,5 MB. Sollte verständlich und klar sein.
Fazit: summa summarum 0,5 MB

Nun ist es aber so, daß die DLL-Entpackroutine (analog zu der im oben besprochenen Fall einer EXE) Speicher (innerhalb des Prozesses - also unabhängig vom gemappten Image) reserviert um dorthin die DLL zu entpacken. Soweit so gut. Nun nehmen wir einmal an, ein beliebiger Packer hätte uns unsere xyz.dll auf 0,2 MB geschrumpft. Aufgrunddessen, daß Entpacker meist selbstmodifizierenden Code benutzen, ist es normal anzunehmen, daß die kompletten 0,2 MB im jeweiligen Prozess beschrieben werden und so ebenfalls pro Prozess benutzt werden. Aber lassen wir diese Betrachtung erstmal außen vor. Nehmen wir also an, daß geladene Image in der Größe von 0,2 MB wird in allen Prozessen gleichermaßen benutzt (also ohne Dopplungen), dann tut sich nun aber folgendes Problem auf.
Der Entpacker alloziert wie gesagt Speicher um das Orginal-Image in den Speicher zu entpacken. Dies geschieht auf einer Pro-Prozeß-Basis. Dieses entpackte Image teilen sich also nciht X Prozesse, sondern jeder der X Prozesse kommt hat seine eigene Kopie davon. Rechnen wir das mit unseren 100 Prozessen, welche die gepackte DLL xyz.dll benutzen also nochmal nach:
Gepacktes Image einmalig + Entpacktes Image Xmal
Macht summa summarum 50,2MB!

Ich hoffe, daß durch diesen Riesenunterschied noch deutlicher wird, wo's hakt. Das heißt, während man sich bei EXE-Dateien "nur" drauf einläßt einen jeweils an Größe der Datei und Packrate festzumachenden Nachteil zu bekommen, wird der Nachteil bei DLLs unermeßlich groß!

[edit=alcaeus]Titel auf Wunsch von Olli angepasst: "sinnlos" in "sehr fragwürdig" geaendert, um "eine Debatte um Worthülsen" (Zitat Olli) zu vermeiden. Mfg, alcaeus[/edit]

[phXql]

Zitat von bigg:

Zitat:

dann nimm 7z und mach ein SFX-Archiv draus...

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

PS: 7Zip benötigt min. 36 MB zum Entpacken bei höchster Stufe.

hab ich. 7z is um 24 KB kleiner, bei einer EXE-Größe von 1,32 MB. Wenn dus nich glaubst, dann kann ich die beiden Dateien gerne hochladen.

und wegen speicherverbrauch: das bei 7z is einmalig, bei den PE-Packern nicht!

[jfheins]

Zitat von bigg:

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

Ich habe menen Test jetzt noch auf 7ZIP erweitert:

Test:

Orginal: 3,38 MB
ZIP: 1,07 MB
UPX: 977 KB
ACE: 934 KB
RAR: 930 KB
7ZIP: 819 KB

ohne Sfx o.ä

Als Testobjekt diente Webweaver.exe in Version 1.68

[phXql]

Zitat von Olli:

@phXql: Das war ja gerade die Anforderung

jetz bin ich verwirrt

[Olli]

Zitat von phXql:

jetz bin ich verwirrt

Es war als Zustimmung gedacht. Denn oben wurde ja gesagt, daß man keine (normalen) Packer benutzen könne, weil die nicht jeder auf seinem System hat.

Nachtrag: @bigg: Ich weiß nicht, woher du die Zahl mit 36 MB nimmst, aber in der höchsten Stufe ist es bei mir nicht mehr ausführbar. Es wird deutlich die Größe des vorhandenen Speichers + Swap überschritten. Also höchste Stufe bei Dictionary und Kompression auf Ultra.

[bigg]

Okay, ich habe es selbst getestet und komme zu den gleichen Ergebnissen.
Allerdings fehlt dort der Entpacker und man benötigt nun 34 MB um die Daten wieder entpacken zu können.

/edit:
Bild angehängt.

[jfheins]

Ich könnte jetzt ja mal versuchen, aus diesem kontroversen Thema eine Bilanz zu ziehen ... Also:

PE-Packer, wie z.B. UPX, sind sinvoll, wenn man Exe-Dateien oder einfach benutzte dlls mit einer für den Endanwender einfachen Methode komprimieren möchte.
Sie sind nicht sinnvoll, wenn es auf maximale Kompression ankommt, oder auf einen geringen ständigen Speicherverbrauch der Anwendung. Weiterhin sind sie für mehrmals genutzte dlls ineffizient, da dann die dll jedesmal erneut geladen wird, und somit der Speicherverbrauch mit zunehmender Nutzung im Gegensatz zu einer unkomprimierten dll wächst.

einfach benutzte dlls = dlls, die nur von einem Prozess genutzt werden.

Richtig ? Noch Einwände ?

[Phoenix]

Zitat von Robert_G:

Zitat von Phoenix:

die unkrompimierte .exe allerdings knapp 20 MB gross

20MB?
Wäre es nicht schon 18MB früher an der Zeit gewesen, alles mögleich an Klassen in Packages auszulagern?
So hätten morgens nur Packages mit neuerer Revision gesaugt werden müssen... (Welches sich wohl meistens auf 0MB oder ein paar KB belaufen hätte...)
Kann ich irgendwie nicht als Vorteil von ExePackern sehen, eher als ineffiziente Herangehensweise...

Das war aus diversen Gründen nicht möglich und auch nicht gewollt.

Das Hauptproblem war, das einige Anwendungen mit der zum Teil gleichen Codebasis nicht den gleichen Releasezyklus haben / hatten als andere. Will heissen Anwendung 1 hätte Package A in Version 2.0 gebraucht, Anwendung 2 hätte Package A aber (weil noch nicht neu released) noch in Version 1.9 benötigt.

Und dann verwalte mal 8 - 12 Anwendungen die ggf. verschiedene Package-Versionen benötigen sinnvoll und effizient in einem Kundensystem. - Ohne das Pro Anwendung wieder alle Packages im Anwendungsverzeichnis liegen und die somit zig mal dort liegen würden. Und dann lass bei einem Update denjenigen der das zusammenstellt mal ein Package in der neuen Version vergessen. Und dann Suche diesen Fehler mal...

Zudem hatte ich keinen Einfluss auf die Handhabung der Versionen, ich musste mich nur mit der Problematik des lockings beschäftigen das einen Kunden zeitweise unproduktiv gehalten hat. Ich hätte da einiges geändert... aber ich war ja 'nur' BA-Student und hatte ja keine Ahnung... :-/

Aber back to topic:

Olli: Stimmt, wenn das System das Swappen anfängt ist eh alles zu spät.

Zur Sache mit der Transfermenge im Internet: UPX komprimiert .exen einfach genial klein. Ich kenne spontan keinen Packer der eine ähnliche Rate erzielt.

Allerdings lassen sich UPX'te exen aber auch wieder entpacken. Von daher kann man UPX als einen Download-Verkleinerer durchaus sinnvoll nutzen - sofern es nur um die reine .exe geht die Übertragen werden muss. Hinterher wieder entpacken und man hat den Memory-Overhead beim ausführen auch nicht mehr.

[Olli]

Zitat von jfheins:

Richtig ? Noch Einwände ?

Statt "sinnvoll" würde ich "vertretbar" sagen, aber ansonsten durchaus. Wobei man sich fragen sollte, welche DLL existert denn um nur in einen Prozess geladen zu werden? Ab 2 Instanzen des gleichen Programms wird's nämlich schon wieder unschön.

Zitat von Phoenix:

Olli: Stimmt, wenn das System das Swappen anfängt ist eh alles zu spät.

Wenn ein Server richtig skaliert ist, läuft er aber oft unter Volllast (sowohl Speicher als auch CPU). Daher meine Einwände. Denn auch die niedlichen kleinen Utilities werden auf Servern manchmal genutzt.

Zitat von Phoenix:

Zur Sache mit der Transfermenge im Internet: UPX komprimiert .exen einfach genial klein. Ich kenne spontan keinen Packer der eine ähnliche Rate erzielt.

...keinen ähnlichen Executable-Packer? Ansonsten wüßte ich eine Menge

Zitat von Phoenix:

Allerdings lassen sich UPX'te exen aber auch wieder entpacken. Von daher kann man UPX als einen Download-Verkleinerer durchaus sinnvoll nutzen - sofern es nur um die reine .exe geht die Übertragen werden muss. Hinterher wieder entpacken und man hat den Memory-Overhead beim ausführen auch nicht mehr.

So gesehen hast du recht. Aber sei dir bewußt, daß die wiederhergestellte EXE nicht identisch ist mit der vorher. UPX legt nämlich fest, daß bestimmte Sachen "einfach nicht benötigt" werden ... und entfernt sie für dich auf Nimmerwiedersehen (Vgl. verlustbehaftete Kompression ).

/Edit:/ falsch zitiert, danke Julius!

[TeronG]

Zitat von Olli:

Woher nun plötzlich diese Großzügigkeit in Sachen RAM rührt, bleibt mir auch ein Rätsel.

Früher: war der Speicher soo klein/knapp, daß z.B. Programmierer von Spielen Programm-Code in Grafiken "versteckt" haben ...

Heute:
aber wenn man "nur" kleine Windows-Tools (für Einzelanwender) macht ist das nicht so wild .. wenn ich aber Größere oder auf kleinenren Systremen Anwendungen schreiben müsste würde ich mir das mit dem Packern lieber genauer anschauen.
Wo investiere ich lieber Recourcen Arbeitsspeicher/CPU-last oder Festplatte/ladezeit .... naja muss wohl jeder für sich entscheiden