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]

[Olli]

Hallo Martin,

das Kompliment trifft auch auf dich zu

Zitat von mschaefer:

Und jetzt kommt das letztlich auch etwas willkürliche: Die Vergabe der Noten in den Schnittpunkten.

Willkürlich ist gut ... außer daß ich dieses System nicht nachvollziehen kann (es ist nur additiv), bin ich leicht anderer Meinung, weil wir vielleicht mal nicht von Entwickler-PCs ausgehen sollten (wie du übrigens in einem anderen Thema selbst bemerktest). Warum Entwickler-PCs? Wenn ich deine Wertung richtig verstehe, so ist diese gerade bei RAM und HDD auch auf einem Endkundensystem nicht mit dem übereinstimmend (leider nichtmal annähernd) mit meiner Bewertung der Lage. RAM ist eben ungleich teurer als HDDs.

Wie gesagt, gerade bei (kleineren!!!) EXE-Dateien halte ich es noch für vertretbar - unabhängig vom Zielsystem. Bei DLLs absolut nicht! Kleinere deshalb, weil es sonst aus der Balance gerät. In Ausnahmesituationen (siehe Phoenix) mag der EXE-Packer auch bei größeren Dateien seine Bewandnis haben, ansonsten eher nicht.

Wir reden doch hier aus Entwicklersicht, oder irre ich? Wenn wir aus dieser Sicht reden, sollten wir auch vorrangig aus dieser Sicht argumentieren. Hier hat meiner Meinung nach ein Installationsprogramm (egal mit welchem System erstellt) eindeutig Vorrang vor gepackten EXE-Dateien (ganz zu schweigen DLL-Dateien) - sagt ja auch MS so. Ansonsten muß sich der Entwickler dann eben Gedanken machen, wo seine Programme ausgeführt werden sollen. Wenn ein Server in Betracht kommt, sollte schon deshalb auf einen EXE-Packer verzichtet werden - oder soll der Serveradmin dann auch noch jedes Programm einzeln (überprüfen und) entpacken? Zumal ja nicht jeder solche Admin auch Erfahrung mit einem EXE-Packer haben muß. Ganz zu schweigen von den proprietären Kollegen von UPX.

[mschaefer]

Guten Morgen

also ich bin nicht Bagwahn und will auch keinen zu meiner Auffassung bekehren, aber die Gelegenheit mal zu zeigen wie das in der Ökonomie zerlegt wird war einfach da. Letzlich führt das dazu dass man die einzelnen Aspekte betrachtet und ihnen einen zahlenmäßigen Maßstab gibt...

Werde jetzt mal wieder in die Beobachterrolle schlüpfen und bin mal gespannt wo der Thread heute abend steht...

Viele Grüße // Martin

[brechi]

Ich persönlich habe nichts gegen irgendwelche Packer wenn sie halt "richtig" eingesetzt werden.
Und "richtig" versuh ich jetzt mal an einem Beispiel zu erklären.

Hat man zum Beispiel ein Programm wovon man üblicherweise mehrere Instanzen laufen hat (Internet Explorer) dann würde ich das Porgramm nicht packen. Die Speicherbenutzung summiert sich halt auf. Im Fall des Internet Explorers wäre das aber nicht weiter tragisch da die exe gerade mal 60kb groß ist (weiß net welche Version). Die wirkliche Speichernutzung für den Internet Explorer liegt aber nicht im Bereich des Porgrammcodes, dieser würde gepackt vielleicht gerade mal 200kb Speicher belegen. Der größte Teil wird durch die Bilder/Texte usw. belegt wenn man eine Seite besucht (11mb bei delphi-praxis). Der belgete speicher für den Programmcode ist Prozentual (2%) so klein, das man ruhig überlegen kann die exe zu packen. Aber da der IExplorer unzählige dlls benutzt, fällt der gewonnene Festplattenspeicher durch die packung nicht wirklich ins Gewicht.
Nehmen wir mal den Firefox, die exe ist 6MB groß, durch Packung kann man hier einiges einsparen. Und gewöhnlich hat man auch nur eine Instalz laufen. Durch bischen surfen im Netz und diesem Post schreiben hab ich jetzt schon 50mb Speichernutzung. Immerhin wäre der Programmcode dann ~10% vom ganzen Speicher. Hier ist es auch fraglich ob man die exe Packen sollte oder nicht.
Also perönlich würde ich daraus schließen das man unter 5% des Porgrammcodes im Speicher im Verhältnis zur ganzen Speichernutzung ruhig einen Packer benutzen _kann_.
Selber benutze ich eigentlich fast nie einen EXE-Packer es sei denn ich teste etwas. Weil ich sehe noch einen 3. Faktor neben RAM/Fesplatten - Speicherkosten. Und zwar die Zeit beim testen (übers Internet). Wenn man jemanden hat der halt nicht so fitt im Umgang mit dem PC ist, aber er halt Probleme mit der Software hat, dann mach ich das eigentlich so das ich halt - wenn ich meine ich hätte den Fehler behoben - ich ihm die neu kompilierte und gepackte exe schicke und er die alte ersetzen soll.
In dem Moment wo es nur ums testen geht, interessiert micht die Speichernutzung eigentlich relativ wenig. Ich will halt nicht übers inetnet 10MB verschicken, und auch dem Benutzer nicht zumuten erst ne zip zu entpacken. Da erfüllen UPX bzw jeder andere Packer sehr wohl ihren Zweck. Und zwar die Datei zu erkleinern damit ich nicht ewig daten durchs internet schicken muss.
Ob man nun "fertige" Programme packen muss, hängt halt immer von dem Programm ab. Ne Datenbankanwensung die z.b 1MB groß ist und mit Datenbanken arbeitet die mehrere 100mb groß sind, und diese voll in den Speicher lädt, dann ist der zusätliche 1MB mehr im speicher für die gepackte Exe nicht wirklich ein Nachteil. Sofern das Programm nicht üblicherweise über mehrere Instanzen läuft.

[barf00s]

uall,
wo kann ich _dieses_ _manifest_ unterschreiben?

[Olli]

Zitat von mschaefer:

also ich bin nicht Bagwahn und will auch keinen zu meiner Auffassung bekehren, aber die Gelegenheit mal zu zeigen wie das in der Ökonomie zerlegt wird war einfach da. Letzlich führt das dazu dass man die einzelnen Aspekte betrachtet und ihnen einen zahlenmäßigen Maßstab gibt

... durch Zufall habe ich gestern mal in dein Profil gelunscht und festgestellt, was da unter Beruf angegeben ist. Was sehe ich da nun?
Nun ist mir ja aus meinen VWL- und BWL-Vorlesungen bewußt, daß ihr Ökonomen manchmal eigenartige Wertungen vornehmt (denn um die dicken Formeln zu benutzen muß man ja erstmal alles in Zahlen packen). Die Diskrepanz zwischen Wertungen von Ökonomen und Fachleuten anderer Richtungen wird in meinem Fachgebiet (Environmental and Resource Management) besonders deutlich. Daher meine Fragen:
- Wie kamst du auf deine Wertungen?
- Wieso gibt es nicht Wertungen -5..5 zu vergeben?
- Wie garantiert ein Ökonom "relative" Objektivität in der Betrachtung?

(Notfalls ein neues Thema aufmachen und von hier darauf verweisen)

[mschaefer]

Hallo Olli,

sorry habe mir wohl etwas viel Zeit gelassen, aber meine Zeiteinteilung war in letzter Zeit rivial inökonomisch.
Im Zuge des Gefechts sind die Wertungen hier sicherlich jetzt von mir auch mit etwas Eigensinn gewählt.

Welche Scala nimmt man: Zur -5,+5 Scala.

Die Anzahl Scalenelemente soll so bemessen sein, daß man für jeden Punkt eine bewertete Benennung geben kann.
Die Lage der Scala soll dabei so liegen, dass sie möglichst verständlich ist. Dabei ist es von der Technik her
egal wie Du diese auf dem Zahlenstrahl verschiebst. Allerdings, wenn man mit Optimerungsprogrammen arbeitet, dann
ist es Vorteilhaft alles von 1 ausgehend im positiven Bereich zu halten, das ist aber eher Handwerkszeug.

Wie garantiert man relative Objectivität

Ja das wird Dich freuen. Man kann das durch Anwenderumfragen machen, wenn es eher untechnische und meinungsbezogenen
Auffassungen geht oder wenn es komplexer ist durch die sogenannte "Delphi-Methode". Das ist übrigbens etwas ziemlich
banales und hat nichts mit programmieren zu tun. Es geht dabei um eine mehrmalige Befragung von Spezialisten auf einem
Fachgebiet. Diese werden dann mit den gegensätzlichen Auffassungen andere Spezialisten konfrontiert und sie müssssssen
dann ihre eigenen Auffassung unter diesen Aspekten neu begründen und Bewerten. Aus den Antworten und Bewertungen wird
dann versucht eine Matrix im obigen Stil aufzubauen. Der Ökonom soll dabei eigentlich eher der Sammler und Sortierer sein.



Environmental and Resource Management (mir würde da gerade Wasser und Öl einfallen) ist letztlich doch ein recht komplexes
Thema. Dafür bräuchte es eigentlich mehr gemeinsame Arbeit an Projekten. Das deutsche Universitätssystem schein aber eher
auf der Konkurrenzdoptrie aufzubauen. Das bringt zwar oft gute Einzelkämpfer, aber ob es wirklich gute Wissenschaftlerteams
bildet, da habe ich doch leise Zweifel. Letzlich ist es aber auch so, dass sehr hoch spezialisierte Menschen sich die Lebensgrundlage nehmen, wenn Sie ernsthafte Fehler auf ihrem Gebiet einräumen müssen. Bewerten fällt da oft schwer.

Grüße // Martin