UPX-Packer ja oder nein?

[a.def]

Ich habe gerade aus Spaß mal einen UPX-Packer über eine meiner Exe-Dateien fahren lassen.
Aus 8,5 MB wurden so 2,3 MB.
Wie kann das sein?

Und

benutzt ihr UPX-Packer oder ist das in der heutigen Zeit etwas, was kein Mensch mehr braucht?

[EWeiss]

Zitat:

benutzt ihr UPX-Packer oder ist das in der heutigen Zeit etwas, was kein Mensch mehr braucht?

Ich benutze den immer aber brauchen tut man ihn nicht.

gruss

[a.def]

Ich finde es unglaublich interessant wie der aus 8 MB 2 MB macht.
ZIP-Archive kennt man ja und die Vorgehensweise mit dem Dictionary usw. Aber ist das bei UPX auch so? Finde nichts Genaues darüber.
Weil eine Exe-Datei hat ja auch ein bestimmtes Format.

[nahpets]

Überblick und Download: https://upx.github.io/

Quelltexte: https://github.com/upx/upx

Doku siehe hier: https://en.wikipedia.org/wiki/UPX

[jaenicke]

Zitat:

Zitat von a.def (Beitrag 1369691)

benutzt ihr UPX-Packer oder ist das in der heutigen Zeit etwas, was kein Mensch mehr braucht?

Erstens spielt es bei den heutigen Festplatten keine Rolle mehr, wenn die Anwendungen etwas größer sind.

Zweitens verhindert man damit ein besseres Packen durch 7zip, wenn man mehrere Exen oder DLLs packt.

Drittens komprimiert 7zip besser, so dass es für eine Übertragung im Internet mehr Sinn macht damit zu packen und wieder zu entpacken.

Und viertens werden gepackte Exen oft als verdächtig von Virenscannern erkannt, z.B. von Avira.

[a.def]

Zitat:

z.B. von Avira.

Ich würde sagen speziell von Avira. Denn die haben es bis heute nicht hinbekommen ein anständiges und konkurrenzfähiges AV-Programm zu entwickeln wie ich finde.

[Uwe Raabe]

Jordan Russel (InnoSetup) hat da mal was zu geschrieben: Why not use an EXE compressor?

Zitat:

Why not use an EXE compressor?

Some have asked why I made StripReloc when there are EXE compression programs such as ASPack and UPX that will trim more bytes off of executables than StripReloc ever could.

The reason is there are downsides to using EXE compressors. Most notably:

• Upon startup of a compressed EXE/DLL, all of the code is decompressed from the disk image into memory in one pass, which can cause disk thrashing if the system is low on memory and is forced to access the swap file. In contrast, with uncompressed EXE/DLLs, the OS allocates memory for code pages on demand (i.e. when they are executed).
• Multiple instances of a compressed EXE/DLL create multiple instances of the code in memory. If you have a compressed EXE that contains 1 MB of code (before compression) and the user starts 5 instances of it, approximately 4 MB of memory is wasted. Likewise, if you have a DLL that is 1 MB and it is used by 5 running applications, approximately 4 MB of memory is wasted. With uncompressed EXE/DLLs, code is only stored in memory once and is shared between instances.
• Some older virus scanners flag compressed EXE/DLLs as being virus-infected. (This is this reason I stopped compressing Inno Setup's EXEs.)
  Update: In fairness, this was written several years ago. This very well may no longer be an issue today.

[EWeiss]

Zitat:

Jordan Russel (InnoSetup) hat da mal was zu geschrieben: Why not use an EXE compressor?

Jeder will etwas zu sagen haben.

Fakt ist jedoch es muss jeder selber wissen was er tut.
Ich hatte noch nie irgendwelche Probleme mit meinen Dateien.
Oder hat irgendwer von mir schon mal ne Virus Meldung bekommen?

gruss

[nahpets]

@EWeiss

könntest Du bitte mal schauen, ob die obige Aussage, dass mit EXE-Packern "verarbeitete" Programme mehr Speicher verbrauchen, bei Deinen Programmen zutrifft?

Bei meinen Programmen kann ich einen derartigen Effekt nicht feststellen.

[EWeiss]

Zitat:

Zitat von nahpets (Beitrag 1369716)

@EWeiss

könntest Du bitte mal schauen, ob die obige Aussage, dass mit EXE-Packern "verarbeitete" Programme mehr Speicher verbrauchen, bei Deinen Programmen zutrifft?

Bei meinen Programmen kann ich einen derartigen Effekt nicht feststellen.

Nein keine Anwendung von mir verbraucht mehr Speicher als gewöhnlich. (Ungepackt)

bsp.
AnimatePNG benötigt 34MB gepackt und genau so viel wenn sie nicht mit UPX gepackt ist.

gepackt 333KB ungepackt 900KB.
Fast bei jeder Datei so ein Faktor von 3 also 3x mal kleiner.

gruss

[nahpets]

Danke.

Kenn' ich auch nicht anders.

[EWeiss]

Zitat:

Zitat von nahpets (Beitrag 1369730)

Danke.

Kenn' ich auch nicht anders.

Jo wie ich sagte Mundpropaganda ist geduldig.. erzählen kann man viel.
Die Fakten hingegen sagen etwas anderes.
Und ja wir leben in einer verschwenderischen Zeit.

gruss

[hoika]

Haloo,
lade die komprimierte Exe doch mal auf Virustotal.com hoch.

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1369729)

Nein keine Anwendung von mir verbraucht mehr Speicher als gewöhnlich. (Ungepackt)

bsp.
AnimatePNG benötigt 34MB gepackt und genau so viel wenn sie nicht mit UPX gepackt ist.

Das hat in der Form auch niemand behauptet. Wenn du noch einmal nachliest, wirst du sehen, dass der SpeicherVerbrauch nur dann als höher angegeben ist, wenn du das Programm mehrfach startest, besondere bei Nutzung von DLLs.

Und da kann ich bei mir durchaus feststellen dass der Speicherverbrauch deutlich höher ist. Nicht so viel höher, wie die Größe der Exe oder DLL, aber der Unterschied ist trotzdem deutlich.

[Hobbycoder]

Was dafür spricht ist sicherlich die Größe der Datei hinterher.

Bei einigen Projekten lade ich Dateien direkt bei einem oder mehreren Kunden hoch. Mit D7 war das noch gut machbar. Jetzt bei Berlin sind die Exe-Dateien um einiges gewachsen, was die Uploadzeit doch um einiges verlängert, was nicht sehr schön ist.

Was aber dagegen spricht ist, den Kunden immer wieder erklären zu müssen, dass es sich bei dem Programm nicht um eine Virus handelt und es virenfrei ist. Und bei den vielen verschiedenen Virenscannern kommt man dagegen gar nicht mehr an. Und noch viel schlimmer ist der Imageverlust, den man sich einhandelt, wenn sich herumspricht, dass von xxx virenverseuchte Dateien kommen (auch wenn's dann gar nicht stimmt). Solche Aussagen halten sich hartnackig, und die dann zu widerlegen wird schwer.

[Sherlock]

Man kann die Diskussion ziemlich kurz zur allgemeinen Zufriedenheit auflösen: UPX taugt nicht für kommerzielle Software. Für den Heimgebrauch jedoch ist es eine nette wenn auch nicht mehr allzu sinnvolle Sache.

Wer Platz bei der Auslieferung sparen will, der packt seine Dateien in ein Inno-Setup oder ähnliches. Bei mir ist das Installationspaket (verpackt sind 32-Bit und 64-Bit Exen) kleiner als auch nur eine der ausführbaren Dateien.

Sherlock

[Codehunter]

Also ich habe ein (wenn auch seltenes) Szenario wo UPX durchaus Sinn ergibt:

Einige unserer Business-Programme werden direkt vom Netzlaufwerk gestartet. Filialen hängen per VPN über DSL da drauf. Hier hat es durchaus Vorteile, die Binaries mit UPX zu packen. Es verkürzt die Ladezeiten ungemein.

[bra]

Ich würde auch von UPX abraten. Ich nutze es hier nur, um unseren Installer zu testen, indem ich die Dateien für den Installer vorher komprimiere und die Installerkomprimierung selbst deaktiviere. Damit geht das Erstellen des Installerpakets deutlich schneller. Beim Kunden würde ich aber keine UPX-Dateien ausliefern, weil die immer mal wieder von Virenscannern angemeckert werden.

Den einzigen sinnvollen Nutzen bei halbwegs aktuellen Rechner sehe ich bei dem Szenario von Codehunter, wo ein lahmes Netzwerk entlastet werden soll.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1369757)

Einige unserer Business-Programme werden direkt vom Netzlaufwerk gestartet. Filialen hängen per VPN über DSL da drauf. Hier hat es durchaus Vorteile, die Binaries mit UPX zu packen. Es verkürzt die Ladezeiten ungemein.

Ich kenne auch Fälle, wo dieses Verfahren zur Anwendung kommt (was nicht heißt, das ich das befürworte).

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Alternativ könnte man die EXE auf einen simplen Package-Loader reduzieren, der dynamisch die benötigten Packages lädt (im Extremfall ist das nur eins). Die Packages kann er dann vorher bei Bedarf (wenn es ein neueres gibt) in gepackter Form herunterladen und entpacken. Da in dem Fall nur veränderte Packages gepackt über die Leitung gehen, sollte das potentiell performanter sein. Die System-Packages (RTL, VCL,...) müssen ja nur bei einem Wechsel der Delphi-Version aktualisiert werden.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1369774)

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Letztendlich ist das eine Frage von Aufwand und Nutzen. Unser Virenscanner schlägt bei UPXen jedenfalls nicht an, daher Ruhe zumindest an der Front. Mit einer Umstellung auf Builds mit Runtime-Packages wäre bei vorhandenen Projekten ein größerer Aufriss verbunden, für den es aus Sicht der Entscheider keine schlagenden Argumente gibt. Und vom Anspruch eines eleganten Softwaredesigns musste ich mich schon vor längerer Zeit verabschieden...

[mensch72]

wir verwenden quasi unseren eigenen "Installer", das ist ein einmal mit echtem Zertifikat signiertes Programm, was durch alle Virentests durchgeht und auch im Sicherheitsbereich von Banken&Kraftwerken bisher immer die Freigabe bekam.

Erstaunlicher Weise erben auch ausfürbare Dateien die von diesem Prozess abgepeichert werden oft selbst lokale Rechte, mindestens aber bekommen sie nie das Flag "aus dem Inet oder von Wechselmedium heruntergeladen"... damit können wir z.B. unsere Softwareupdates relativ ungestört realisieren. Nebenbei Packen(zuerst) und verschlüsseln(dannach) wir unsere Distributionen, weil wir es bevorzugen auf allen Kundeninstallation möglichst immer die Komplettsoftware aufzuspielen. Je nach Lizenz lässt sich eben nicht alles entpacken und nutzen, aber wenn es sein muss hat unser Support Remote immer gleich alles per Codeeingabe selbst zur Verfügung (einfach hin kopieren ginge eh nicht, weil der Installer in die Programmfiles an passenden Stellen einen lokalen Systemhash einsetzt)

Standard-RunTime EXE Packer/Entpacker wie Upx nutzen wir nicht. Auf eigene/spezielle Programme, welche direkt selbst nach expand/decrypt dann per WinApi einen Speicherbereicht als "ausführbar" deglarieren und dort was anspringen, reagieren viele Sicherheitstools und Security Verantwortliche sehr allergisch.

[bra]

Zitat:

Zitat von Uwe Raabe (Beitrag 1369774)

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Das bringt aber nichts, wenn die Anwendung auch noch DLLs u.ä. aus dem Netzlaufwerk benötigt bzw. nachladen muss. Dann müsste man die ja auch alle mit lokal kopieren.

[a.def]

Zitat:

Zitat von nahpets (Beitrag 1369730)

Danke.

Kenn' ich auch nicht anders.

Mein Test zeigt

ungepackt
- Abeitsspeicher: 14,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

gepackt
- Abeitsspeicher: 23,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

[bra]

Ich habe das mal mit unserer Anwendung getestet und da ist der Unterschied deutlich zu sehen:


Ungepackt (exe 47 MB)
Max. Arbeitssatz (Speicher): 104.468K
Arbeitsspeicher (privater Arbeitssatz): 61.520K

Mit UPX gepackt (exe 18 MB)
Max. Arbeitssatz (Speicher): 137.900K
Arbeitsspeicher (privater Arbeitssatz): : 107.880K

[a.def]

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

[nahpets]

Interessant, da scheint es ja dann auch Abhängigkeiten von Programm zu Programm geben.

Bei meinen Programmen ist mir sowas bisher noch nicht aufgefallen, allerdings nutze ich UPX auch nicht mehr wirklich.

Es war interessant, als USB-Sticks noch nicht im GB-Bereich waren und vor allem zu Zeiten, als Disketten durchaus noch ein üblicher Datenträger für Rettungssysteme waren.

Aber das passt dann wohl doch besser zu diesem Thema: http://www.delphipraxis.net/192506-m...wird-wenn.html ;-)

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1369807)

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

Diese Frage bei StackOverflow gibt, trotz immer noch fehlender Antworten, einen Einblick in die dahinter steckende Komplexität: Size of exe file vs available memory

Demnach müsste der Effekt z.B. schon unterschiedlich sein, je nachdem ob Debug-Info in der EXE enthalten ist oder nicht.

[himitsu]

EXE/DLL/BPL sind standardmäßig als MMF mit CopyOnWrite in den Arbeitsspeicher gemapt. (jede der benötigten PE-Sectionen hintereinander)

Sie können also ausgelagert werden und belegen im Prozess nur den virtuellen Speicher, aber im realen Speicher sind sie vernachlässigbar.
Erst wenn ein Prozess an den gemapten Daten im RAM was ändert, bekommt er für jeweils den umgebenen 4KB-Block eine eigene Kopie.

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.
Stell dir mal vor jeder der 10000 aktiven Prozesse müsste seine eigenen Kopieen der System-DLLs in den Speicher laden.
Bei nur 1000 Prozessen wären das alleine 1,5 GB für die ntdll.dll .

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1369815)

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.

Und wenn die Exe bzw. DLL nicht mit UPX gepackt ist. Ansonsten würde jedesmal ein neuer Speicherbereich reserviert werden...

[himitsu]

Jupp, UND.

Bei UPX wird der Speicher vom Loader reserviert, beschrieben und Windows weiß nichts davon, selbst wenn ein anderes Programm das gleiche macht.
Sowas wie UPX könnte man ja nicht nur auf die EXE, sondern auch auf DLLs anwenden.

[EWeiss]

Wenn der Entwickler von Delphi in der Lage wäre vernünftige Kompilate zu erstellen bräuchte man so etwas, UPX oder vergleichbare Packer überhaupt nicht.
Das man unnötige Dinge in einer EXE komprimieren bzw. erst gar nicht einbinden muss beweisen unter anderem ResourceHacker und UPX.

Der gleiche Code in D6 und letztendlich Kompiliert mit der letzten Delphi Version sind vom Größen Unterschied schon beträchtlich.
Aber gut das hatten wir im anderen Thread schon diskutiert.

[IronieOn]Aber wir wissen ja alle Delphi ist perfekt. LOL.[/IronieOff]

gruss

[himitsu]

Komisch, wenn ich UPX auf ein perfektes C++-Kompilat los lasse, dann wird das auch Kleiner.

Gut, .NET und VisualBasic-Programme sind ja auch viel kleiner. (wenn man die Laufzeitbibliotheken ignoriert)

[Daniel]

Klar wird es kleiner - ein Compiler soll auch nicht komprimieren. UPX entscheidet zudem auch nicht über die Notwendigkeit der Inhalte einer Datei.

[bra]

In Zeiten, wo Windows-Updates gleich mal mehrere hundert MB oder sogar GB groß sind, spielt es ja nun wirklich kaum noch eine Rolle, ob eine exe 5, 15 oder 50 MB groß ist.

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1369829)

Wenn der Entwickler von Delphi in der Lage wäre vernünftige Kompilate zu erstellen bräuchte man so etwas, UPX oder vergleichbare Packer überhaupt nicht.
Das man unnötige Dinge in einer EXE komprimieren bzw. erst gar nicht einbinden muss beweisen unter anderem ResourceHacker und UPX.

Das widerspricht aber eben der Funktionsweise von Windows. Unter Windows werden DLLs von Windows automatisch in Speicherbereiche der Exen, die sie laden, eingeblendet, damit sie nicht mehrfach im Speicher liegen müssen, so wie himitsu schon geschrieben hat. Wenn Delphi selbst das durch Komprimieren umgehen würde, wäre das ein Nogo, weil das den Arbeitsspeicher vollmüllen würde sobald eine solche Anwendung mehrfach läuft usw.

Zudem ist es eben auch hoch bedenklich, wenn eine Anwendung Speicher schreibt und den dann ausführbar macht. Es ist schon absolut korrekt, wenn solche Anwendungen erst einmal verdächtig sind.

Vernünftig hat jedenfalls nichts mit ultraklein zu tun, weil das für 99% der Fälle nicht relevant ist. Und unnötig sind die Daten ja nicht, die werden ja durchaus verwendet. Nur eben nicht durch jeden.
Deshalb wäre es durchaus wünschenswert, wenn man die RTTI Informationen z.B. komplett herauslassen könnte usw.
Wenn dann die Anwendung auch nicht mehr wie gewünscht funktioniert, wäre das ja egal, weil das ja durch den Entwickler so eingestellt wurde.
Aber ob das wirklich wichtiger als Bugfixes und neue Features ist... sehe ich zumindest nicht so.

[a.def]

Ist zwar OT aber
ich wäre mal für einen Bugfix, und das ziemlich schnell, der das vom Benutzer eingestellte Layout korrekt speichert und lädt!
Ist nämlich ziemlich nervig, wenn die linke Spalte im Objektinspektor nach jedem Neustart der IDE nur noch 10% breit ist und die linke 90%, obwohl man doch 50/50 eingestellt hat.
Das Problem gibt es übrigens schon seit XE2 ;)
OT-Ende.

[EWeiss]

Zitat:

Vernünftig hat jedenfalls nichts mit ultraklein zu tun, weil das für 99% der Fälle nicht relevant ist.

Gebe ich dir recht.
Aber einen faden Beigeschmack hat es trotzdem. "Wir sind eine Verschwender und Wegwerfgesellschaft"
Das spiegelt sich nicht nur hier wieder sondern in allen Lebensbereichen.

Ach ja was spielt das für eine Rolle hab ja Terrabyte Festplatten.
NUR! Das man den eingesparten Bereich für andere Dinge nutzen könnte kommt niemandem in den sinn.

Letztendlich muss es jeder selber wissen persönlich hatte ich noch nie Probleme damit.

gruss

[nahpets]

[OT]

Zitat:

Zitat von EWeiss

Ach ja was spielt das für eine Rolle hab ja Terrabyte Festplatten.

Festplatten Terrabytebereich:

Hab' mir da letztlich so 'ne USB-Platte mit 3 Stück Terradingens zugelegt.

Angestöpselt und ging.

Diverse kleinere Datei (jeweils deutlich < 10 kb aber seeeeehr vieeeeele) darauf kopiert.

Die Platte wurde sichtbar schnell voll.

Warum?

Formatiert mit 'ner Clustergröße von "nur" 256 KB.

Da ist der "Verschnitt" dann schnell gigantisch.

Alles zurückkopiert und neu formatiert.

Komisch: Die Platte will und will nicht voll werden ;-)
[/OT]

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1369839)

ich wäre mal für einen Bugfix, und das ziemlich schnell, der das vom Benutzer eingestellte Layout korrekt speichert und lädt!
Ist nämlich ziemlich nervig, wenn die linke Spalte im Objektinspektor nach jedem Neustart der IDE nur noch 10% breit ist und die linke 90%, obwohl man doch 50/50 eingestellt hat.

Also bei mir funktionier das! Man muss nach der Änderung nur das aktuelle Layout gezielt abspeichern.

[EWeiss]

Zitat:

Komisch: Die Platte will und will nicht voll werden

Dann machst du etwas falsch! ;)

Zitat:

Also bei mir funktionier das! Man muss nach der Änderung nur das aktuelle Layout gezielt abspeichern.

Ist auch sinnvoll.

gruss