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]

[Phoenix]

Also als Sinnlos würde ich die echt nicht bezeichnen.

Beispiel: Eine .exe liegt (komprimiert) auf einem Fileserver für den zentralen Zugriff für Clients in der Größenordnung von mindestens 50 Stück.

Das macht in Deinem Beispiel morgens früh wenn alle darauf zugreifen 50 * 0,7 MB = 35 Mb Netzwerkverkehr weniger. In unserer damaligen Produktivumgebung beim Kunden war die unkrompimierte .exe allerdings knapp 20 MB gross und die gepackte nur 4,5. Ergo: 775 MB weniger Daten zu schaufeln. Das macht morgens früh schon einiges aus - zumal ja auch noch anderer Netzwerkverkehr wie Datenbankzugriffe etc. pp. dort laufen.

Im übrigen war die komprimierung der .exen zwingend notwendig. Dank des bescheidenen opportunistic locking des Windows NT 4 Servers kam es bei mehrfachen zeitgleichen Zugriffen auf eine Datei unter Umständen dazu, das die Datei sogar für weitere lesezugriffe gesperrt wurde, weswegen dann viele Clients morgens auf das Timeout warten mussten um eine Fehlermeldung zu erhalten und es dann nochmal probieren durften.

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Ich gebe zu dies ist kein Fall der bei jedem alltäglich vorkommt. Aber es gibt eben auch für Exe-Packer Anwendungsbereiche die deutlichst Sinn machen.

[bigg]

durchschn. Zugriffszeit eines Speicherriegels: 1,6 - 60 ns
durchschn. Zugriffszeit einer Festplatte: 3 - 12 ms


Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version?



@olli:
Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

[Olli]

Zitat von jfheins:

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

56k-Modem. ISDN kommt frühestens im September (Danke T-Com!) und auch dann laufe ich weiterhin mit dem Analogmodem.

Zitat von jfheins:

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.

Im Vergleich sind es 2 MB zuviel.

1. 4 MB, davon 3 geladen ... und ungepackt -> 3 MB
2. 1 MB + 4 MB vom Entpacken -> 5 MB

Zitat von jfheins:

Es werden im Endeffekt vielleicht 0,4% des Arbeitsspeichers unnötig verbraucht - ein verschwindend geringer Nachteil im Vergleich zur Dateigröße.

Das muß jeder für sich entscheiden, ob das für ihn viel ist. IMO ist es das. Da beipielsweise eine VM im Gegensatz zu einem normalen Programm echten Speicher (weil im K-Mode) anfordert, ist jedes MB für mich wichtig. Da kann ich mir nicht einfach 2 MB leisten, die einfach verschwendet werden. Abgesehen davon halte ich Leute, die ihre Programme ungepackt ins Netz stellen (ob nun als Installer oder als RAR, 7Z, ZIP, GZ oder sonstwas gepackt ... mach keinen Unterschied) für doof. Also lade ich deren Programme nicht runter. Und wenn dein EXE-Packer die 5-MB-EXE auf 1 MB schrumpft, schafft der 7z-Packer zB 0,7 oder noch weniger. Also habe ich wieder alle Vorteile und keinen Nachteil (außer dem einmaligen Entpacken).

Zitat von jfheins:

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

Ich stelle mir gerade vor, wie aussähst, wenn die Toolbar-Hersteller genauso dächten (angenommen du arbeitest mit dem IE). Dort laufen nämlich oft mehrere Instanzen ... und bei COM-Objekten in gepackten DLLs nimmt das Chaos seinen Lauf.

Zitat von jfheins:

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

Das das klassische ZIP nicht mehr auf der Höhe der Zeit ist, mag sein. Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

[phXql]

Zitat von jfheins:

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

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

abgesehen davon versagt mein UPX irgendwie bei .NET-Assemblies

[jfheins]

Zitat von Oliver:

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat von phXql:

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

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ...

[Olli]

@Phoenix: Ungepackter Transfer übers Netz und schlechte Fileserver würde ich ungern als Argument für eine Sache gelten lassen, welche permanent einen Nachteil bringt. Hier könnte allein ein transparentes Kompressionsverfahren während der Übertragung Abhilfe schaffen.

Zitat von Phoenix:

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Jupp.

Zitat von Phoenix:

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Spätestens bei DLLs sind sie sinnlos.

Zitat von bigg:

Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version?

Dank fehlenden Nachteils dürfte NTFS-Komprimierung hier schneller und besser sein als ungepackt.

Zitat von bigg:

Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

Nein ... ich weiß aber auch nicht so recht, wie du auf die Idee kommst verlustbehaftete Kompressionsverfahren mit einem EXE-Packer zu vergleichen. Nur weil eine BMP RLE-kodiert ist, ist sie ja nicht gleich schlecht. Aber bei RLE, oder auch NTFS-Kompression sind Kompressionsrate und CPU-Last gut ausbalanciert.

Ach übrigens, wenn dank der Speicherverschwendung mit EXE-Packern das Speicherauslagern beginnt, dann hat euch das System aber einen Strich durch eure 12ns-Rechnung gemacht!

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

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

[phXql]

Zitat von jfheins:

Zitat von Oliver:

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat von phXql:

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

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ...

wenn du ein SFX-Archiv machst, dann können sie doch von jedem geöffnet werden...

[Olli]

Zitat von bigg:

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

was für ein Quatsch.

Abgesehen davon, daß ich "--force" benutzen mußte um UPX überhaupt zu überzeugen, komme ich bei UPX und WinDirStat 1.1.2 (Unicode) einer normalen Allerweltsanwendung auf einen Unterschied von etwa 270kB!

Zitat von bigg:

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

Und das auch nur einmal nach dem Transport.

@phXql: Das war ja gerade die Anforderung