[...] warum ich aus meiner Sicht heute sogar aus Sicherheitsaspekten aber eher skeptisch bei Exe-gepackten Programmen bin. Obwohl ich das früher selber sportlich fand.
Ma gucken:
Hieß doch damals, daß die gestarteten Programme (Prozesse) (sich) keine DLLs mit anderen teilen (möchten).
Öhm nö. Das hieß es nie. Es hieß, daß DLLs die sich im Speicher zur Laufzeit selbst entpacken nicht als MMF die Speicherseiten mit anderen Prozessen teilen.
CoW eben.
Ob das nun selbstmitgebrachte DLLs betrifft, oder auf dem Wirtssystem benutzte, weiß ich nicht.
Selbst mitgebrachte, sofern "gepackt". Wobei "Packen" sich hier ebenfalls auf Obfuscatoren ala Themida, VMProtect und Gedöns erstreckt.
Hab nie getestet, ob z.B. 20-50 als exepacker "verkleinerte" Prozesse den
RAM mit jeweils neugestarteten DLLs den
RAM belegen und zumüllen.
Ein solcher Packer verhält sich bei einer
DLL nunmal anders als beim Programm selber. Immer kann man zugutehalten, daß bspw. bei alten Drehscheiben (Festplatten) die Verkleinerung beim erstmaligem Start zu Performanceschüben führen
konnte. Aaaber, wer benutzt diese Platten denn heutzutage noch? Und außerdem ist schon beim zweiten Start der Cache-Manager von Windows so hilfreich und hat alles bereits vorab geladen. Und
dann kommt erstmal eine theoretische Performanceeinbuße zum tragen, nämlich dann wenn sich der Code im Speicher des ladenden Prozesses selbst entblättert. Wobei da jede Menge Abstufungen möglich sind und zumeist auf heutigen Systemen die Performanceeinbuße recht vernachlässigbar sein dürfte.
Relevanter wäre da wohl der Aspekt, daß mangels "Introspektion" diverse Anti-Malware-Hersteller beschlossen haben diverse Packer/Obfuscatoren einfach auf ne schwarze Liste zu setzen.
Zwar sollte IEEE Taggant da Abhilfe schaffen; ist aber mittlerweile ein Ex-Projekt.
Außerdem verschafft mir das ein sicheres Gefühl, da es etwas offensichtlicher erscheint, was der Programmierer mir "mitteilen" möchte.
Der Programmierer wollte aller Wahrscheinlichkeit nach deinem Rechner und nicht dir etwas mitteilen. Ich sag ja nur ...
OK, wenn man natürlich eine 20 MB große Hallo-Welt-Exe ausliefert, die man mit-ohne Debuginformationen auf 2-3 MB kriegen könnte (Delphi 5 kreiert eine Fensterapp mit 385 KB; Delphi7 mit 430 KB), würd das Packen vielleicht Sinn machen.
Das ist wohl eher eine individuelle Entscheidung des Entwicklers, oder?
Bedenke: heutzutage haben die meisten Menschen mehrere Instanzen der Chromium-Engine auf ihrem Rechner rumliegen. Sei's unter der Haube bei Electron-Apps wie Signal Desktop, Teams, VS Code
oder anderem Gedöns, oder in einem echten Browser (Vidaldi, Opera, Chrome, usw. ...).
Es gab mal eine Zeit da galt es als eine gut Idee wenn sich Prozesse die gleichen Komponenten teilen. Eben daher der Kritikpunkt zu
gepackten DLLs deren Speicherseiten nach dem CoW-Prinzip nach erstmaligem Schreiben in jedem Prozeß ihre eigene Kopie bekommen. Aber heute ist das so ziemlich jedem Anwender wumpe. Ich habe mittlerweile sogar Software gesehen die allen Ernstes Chromium mit höchsten lokalen Rechten in einem Dienst ausführt.
Aber es gab ja auch einmal eine Zeit in der es als sinnvoll galt Software in Verzeichnissen zu installieren die weniger leicht manipulierbar sind als %APPDATA% und %LOCALAPPDATA%.
Aber man kann z.B auch 20MB-EXE-Programme zum Transport via Internet mit ZIP oder 7Z/WinRAR packen.
Aber der darf sich nicht wundern, wenn er danach Supportanfragen zu dem Thema bekommt, daß nix passiert wenn man die Datei doppelklickt (außer ZIP wo das meist zum Öffnen führt).
Selbst erlebt. Aber auch mit ZIP.
(übrigens auch mit dem KGB-Archiver auf 50 KB .... allerdings braucht man dann genügend so 64 bis 256 GB
RAM zum Entpacken. Wer seinen Kunden oder Nutzern das zumuten möchte - nur zu!)
Bekommt man im Zweifel auch bei LZMA2 mit den richtigen Parametern auf die Reihe
Das ist aber eigentlich genau wie lrzip eher so ein domänenspezifisches Werkzeug. Gut, vielleicht nicht für Menschen die sich mit dem Skalpel ihr Honigbrötchen zum Frühtück schmieren ... aber so normal denkende Menschen halt, mit Verständnis für die Werkzeuge welche sie nutzen.
Ich hab auch mal meine geteilten FreewareProgramme mit Pecompact gepackt. Als man das noch bedenkenlos tun konnte.
Kann man noch immer bedenkenlos tun. Wobei ich persönlich immer FLOSS den Vorrang geben würde, also bspw. dem empfohlenen UPX.
Es gehört offensichtlich mittlerweile eh zum guten Ton Qt C++Programme mit je eigener Distribution von QT im Umfang von 100-150 MB auszuliefern.
Siehe oben, Chromium/Electron. Selbst die Zielsetzung (Cross-Plattform-igkeit) ist die gleiche.
Ich reg mich nicht mehr auf, wenn von Delphi 40-60 GB der Installation und bei jedem Compilliervorgang 20 MB Exe's hin und her auf die Platte geklatscht werden.
Ich schon und versuche immer nur das zu installieren was auch muß. Läßt sich leider insbesondere bei sehr verzahnter Software nicht immer machen. Zumal man bei Delphi 5 meiner Erinnerung nach auch nur - und dann nur in gepacktem Zustand - auf die behauptete Größe von 84 MiB kam.
"Es dient ja der Sicherheit."
"Die Programme werden sicherer."
Stimmt teils, aber teils auch nicht. Wenn der Entwickler von einem Programm wie 7-Zip -- übrigens ein Russe ...
oh Schreck! --
sich weigert aktuelle Toolchains zum Bau der Software zu benutzen (halte diesen Blogartikel für leicht übertrieben), hat das durchaus andere Auswirkungen als wenn das irgendeine Nischensoftware betrifft. Zumal es 7-Zip täglich millionenfach mit Eingabedaten zu tun bekommt, die auch kleine Programmierfehler sicherheitsrelevant werden lassen können.
Oh (<- gemeint ist die Online-Hilfe
!) Gott ... und WinRAR: auch von einem russischen Entwickler. Wir werden alle sterben!
"Der Programmierer wird total entlastet"
Klar. Sieht man auch bei Containern. Ist da mal einer abgeschmiert? Okay: "ich zieh ne neue Instanz hoch" ... während ich noch zurufen möchte: und was ist mit der Postmortem-Diagnose des Absturzes?
Aber hat man das nicht ohnehin an allen Stellen? Ich erinnere mich noch gut, daß man bei
VCL-Programmierung sehr aufpassen mußte nicht die Logik direkt in die Units für die Forms zu kippen. Ähnliches fand ich später bei .NET und C# wieder.
Alle diese "Entlastungen" haben eben auch Kosten. Und vom selbständigen Denken haben sie noch selten entlastet.
Da ich das Produkt Aspack und weder Freeware (UPX) und generell kommerzielle Packer (seit PeCompact-Problemen) nicht mehr nutze, - trägt das zwar nicht zur Lösung bei, wollte ich aber anregen, ob es mittlerweile auch ungepackt ginge und ggf. sogar verkaufsfördernd sein könnte. Manchmal verliert man solche Aspekte aus dem Sichtfeld. Könnte ja sein.
Da wäre wohl das Signieren der Software (sei es PGP und/oder AuthentiCode), sowie die Integration mit Chocolatey, WinGet usw. deutlich förderlicher, oder?