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]