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]

[bigg]

Welch einseitige Begründung.

Hast du auch mal Zeitmessungen durchgeführt, in wie weit Prozesse schneller geladen werden?
Festplattenzugriffe werden verkürzt.

PS: Das komprimierte Dateien mehr Speicher belegen ist nicht neu,
das ist ein Laster der Kompression.

[Olli]

Zitat von bigg:

Welch einseitige Begründung.

"*plonk*"?

Zitat von bigg:

Hast du auch mal Zeitmessungen durchgeführt, in wie weit Prozesse schneller geladen werden?
Festplattenzugriffe werden verkürzt.

Nein habe ich nicht. Die kannst du dann gern per NTFS-Komprimierung minimieren, deine Festplattenzugriffe. Die Nachteile sind eindeutig.

[marabu]

Hi Olli,

deine Darstellung des Sachverhaltes halte ich für didaktisch gelungen, aber

Zitat von Olli:

Die kannst du dann gern per NTFS-Komprimierung minimieren, deine Festplattenzugriffe. Die Nachteile sind eindeutig.

das steht jetzt so eng beieinander... Ich erwarte eigentlich, dass die Nutzung eines compressed file system nicht auf die von dir beschriebene Prozessebene durchschlägt - oder liege ich da falsch?

Grüße vom marabu

[bigg]

Zitat:

Welch einseitige Begründung.

Ironie!

[Olli]

Zitat von bigg:

Zitat:

Welch einseitige Begründung.

Ironie!

Nächstes Mal bitte markieren ...

Zitat von marabu:

das steht jetzt so eng beieinander... Ich erwarte eigentlich, dass die Nutzung eines compressed file system nicht auf die von dir beschriebene Prozessebene durchschlägt - oder liege ich da falsch?

Naja, ich ging davon aus, daß bigg von den Plattenzugriffen spricht, weil diese um Größenordnungen langsamer sind als Speicherzugriff oder gar CPU-Speicher-Transfers. In diesem Sinne hat auch bei komprimierten NTFS-Dateien die Festplatte weniger zu lesen und es wird schneller. Übrigens etwas, das Robert immer wieder anspricht.

Will heißen, unsere gepackte EXE aus dem Beispiel oben, mit 0,3 MB, wird (wahrscheinlich) viel schneller von Platte gelesen und entpackt (zusammen betrachten!!!) als die gleiche ungepackte EXE aus einer unkomprimierten Datei (Entpacken im Speicher fällt weg) oder auch die gleiche ungepackte EXE aus einer komprimierten Datei (zB 0,5 MB - NTFS-Kompression ist nicht perfekt ...) - dann aber auch ohne Entpacken im Speicher.

[Pr0g]

Was aber ist, wenn es nicht auf den Speicherverbrauch ankommt, sondern nur auf die Größe der Exe (wofür die Packer ja da sind) und das Programm eh nur in einer Instanz läuft. Bei den Dlls das gleiche. Wenn ich sie nur für mein Programm brauche, welches nur einmal gestartet wird, dann nützt mir die Optimierung seitens des Systems nicht viel, dass sich Prozesse die Kopie im Speicher teilen.

MfG Pr0g

[Olli]

Zitat von Pr0g:

Was aber ist, wenn es nicht auf den Speicherverbrauch ankommt,

Die Betrachtung leistest du dir auch nur, weil du im Usermode programmierst. Die Sichtweise könnte sich (dramatisch) ändern, wenn du auch Kernelmode-Sachen schreiben würdest. Aber das ist eine andere Geschichte.
Woher nun plötzlich diese Großzügigkeit in Sachen RAM rührt, bleibt mir auch ein Rätsel. Schließlich sind RAM-Riegel pro MB noch um ein Vielfaches teurer als Festplattenplatz. Schon von daher rechnet es sich wirtschaftlich nicht einen EXE-Packer einzusetzen! Laß es mal von deinem Lieblingsökonomen durchrechnen.

Zitat von Pr0g:

sondern nur auf die Größe der Exe (wofür die Packer ja da sind)

Packer <> EXE-Packer

Zitat von Pr0g:

und das Programm eh nur in einer Instanz läuft. Bei den Dlls das gleiche. Wenn ich sie nur für mein Programm brauche, welches nur einmal gestartet wird, dann nützt mir die Optimierung seitens des Systems nicht viel, dass sich Prozesse die Kopie im Speicher teilen.

Das ist richtig, dennoch läufst du auch in diesem Falle suboptimal, bis schlecht. Denn wenn wir obiges Beispiel mal annehmen, selbst wenn der PE-Loader die 1-MB-EXE komplett lädt, fährst du mit der gepackten schlechter. Sowohl in Hinsicht auf Speicher als auch auf CPU-Zeit (zum Entpacken bspw.).

Nachtrag:
Und nochmal auf den ökonomischen Nerv: wenn ich eine EXE und die DLLs transportiere (gepackt mit einem normalen Dateipacker), so habe ich den Nachteil (CPU-Last, RAM-Last) nur 2mal (Packen und Entpacken) - um den Vorteil eines kostengünstigen weil kleinen Transports. Wenn ich nun die Dateien mit einem PE-Packer gepackt habe, habe ich den Nachteil bei jedem Mal!

[jfheins]

Ich möchte hier trotz der CodeLib-Sparte meine Meinung sagen, und zwar ist die Nutzung von Exe-Packern für Exen durchaus von Vorteil.

Olli, du als ISDN-Nutzer kannst es dir sicher vorstellen:

Ohne Exe-Packer:
Du ziehst dir ein 4 MB Programm aus dem Netz und führst es aus, vielleicht werden dann auch nur 3 MB geladen.

Mit:
Du ziehst dir 1 MB, und dafür wird 0,2% des Arbeitsspeichers mit dem Exe-Packer "zugemüllt" und ausserdem 1 MB zuviel entpackt. Es werden im Endeffekt vielleicht 0,4% des Arbeitsspeichers unnötig verbraucht - ein verschwindend geringer Nachteil im Vergleich zur Dateigröße.

(Gerechnet mit 500 MB RAM und ohne Auslagerungsdatei)

Und für dlls, die nur von einem Programm (oder 2) verwendet werden, halte ich dieses Verfahren ebenfalls für annehmbar.

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

Test:

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

ohne Sfx o.ä

Ich bin übrigens DSL Nutzer ;-)

[Dax]

Wenn man aber eine Selbstextrahierende Archivdatei erstellt, die für das gegebene Programm die beste Kompressionsrate hat, oder besser: gleich einen Installer, ist der Vorteil PE-Packer effektiv nullifiziert