UPXを使用してWindows実行可能ファイルを圧縮することの欠点はありますか？
以前に [〜＃〜] upx [〜＃〜] を使用してWindows実行可能ファイルのサイズを縮小しましたが、これがもたらす可能性のある悪影響にはナイーブであることを認めなければなりません。この梱包/開梱のすべての欠点は何ですか？
実行可能ファイルをUPXしないことを推奨するシナリオはありますか（たとえば、DLL、Windowsサービスを作成するとき、またはVistaまたはWin7をターゲットにするとき）？私はほとんどのコードをDelphiで記述していますが、UPXを使用してC/C++実行可能ファイルも圧縮しています。
ちなみに、私はnot実行可能ファイルのサイズを減らして大雑把なことを防ぐためだけに、exeを逆アセンブラから保護しようとしてUPXを実行していません改ざん。
その理由は、EXEコンプレッサーを使用することには欠点があるためです。最も注目すべき点：
圧縮されたEXE/DLLの起動時に、すべてのコードが1回のパスでディスクイメージからメモリに解凍されます。これにより、システムのメモリが不足し、スワップファイルへのアクセスが強制されると、ディスクがスラッシングする可能性があります。対照的に、非圧縮のEXE/DLLの場合、OSはコードページにオンデマンドで（つまり、実行時に）メモリを割り当てます。
圧縮されたEXE/DLLの複数のインスタンスは、メモリ内にコードの複数のインスタンスを作成します。 （圧縮前に）1 MBのコードを含む圧縮EXEがあり、ユーザーがその5つのインスタンスを開始した場合、約4MBのメモリが無駄になります。同様に、1MBのDLLがあり、実行中の5つのアプリケーションで使用されている場合、約4MBのメモリが無駄になります。非圧縮のEXE/DLLを使用すると、コードは1回だけメモリに保存されます。インスタンス間で共有されます。
これがまだ言及されていないことに驚いていますが、統計的に多くのマルウェアもUPXを使用しているため、UPXがパックされた実行可能ファイルを使用すると、ヒューリスティックアンチウイルスソフトウェアから誤検知が発生するリスクも高まります。
3つの欠点があります。
- コード全体は仮想メモリで完全に非圧縮になりますが、通常のEXEまたはDLLでは、実際に使用されるコードのみがメモリにロードされます。これは、EXE/DLLのコードのごく一部のみが各実行で使用される場合に特に関係があります。
- DLLおよびEXEが実行されているインスタンスが複数ある場合、それらのコードをインスタンス間で共有できないため、より多くのメモリを使用することになります。
- EXE/DLLがすでにキャッシュにあるか、非常に高速なストレージメディアにある場合、または実行しているCPUが遅い場合は、解凍を実行する必要があるため、起動速度が低下します。サイズの縮小によるメリットがあります。これは、繰り返し呼び出されるEXEに特に当てはまります。
したがって、EXEまたはDLLに多くのリソースが含まれている場合、上記の欠点はより問題になりますが、それ以外の場合、DLLについて話していない限り、実行可能ファイルと使用可能なメモリの相対的なサイズを考えると、実際にはそれほど大きな要因にはならない可能性があります多くの実行可能ファイル（システムDLLなど）で使用されます。
他の回答のいくつかの誤った情報を払拭するには：
- UPXは、DEPで保護されたマシンで実行する機能には影響しません。
- UPXは、UPXで圧縮された実行可能ファイル（およびその他の実行可能圧縮形式）をサポートしているため、主要なウイルス対策ソフトウェアの機能には影響しません。
- UPXはしばらくの間LZMA圧縮（7Zipの圧縮アルゴリズム）を使用することができました。-lzmaスイッチを使用してください。
サイズが重要なのは、インターネットからのダウンロード時のみです。 UPXを使用している場合、実際には 7-Zip を使用している場合よりもパフォーマンスが低下します（私のテストによると、7-ZipはUPXの2倍優れています）。次に、ターゲットコンピューターで実際に圧縮されたままにすると、パフォーマンスが低下します（ラースの回答を参照）。したがって、UPXはファイルサイズの適切なソリューションではありません。全部を7Zipするだけです。
改ざんを防ぐ限り、それは[〜＃〜]失敗[〜＃〜] 同様に。 UPXは解凍もサポートしています。誰かがEXEを変更したい場合は、UPXで圧縮されていることを確認してから解凍します。速度を落とす可能性のあるクラッカーの割合は、労力とパフォーマンスの低下を正当化するものではありません。
より良い解決策は、バイナリ署名または少なくともハッシュのみを使用することです。単純なハッシュ検証システムは、バイナリとシークレット値（通常はGUID）のハッシュを取得することです。 EXEだけが秘密の値を知っているので、検証のためにハッシュを再計算するときに、EXEはそれを再び使用できます。これは完全ではありません（秘密の値を取得できます）。理想的な状況は、証明書と署名を使用することです。
最近では、ディスク上の実行可能ファイルの最終的なサイズはほとんど関係ありません。プログラムの読み込みは数ミリ秒速くなる場合がありますが、実行を開始すると、違いは区別できません。
UPXで圧縮されているという理由だけで、実行可能ファイルを疑う人もいるかもしれません。エンドユーザーによっては、これが重要な考慮事項である場合とそうでない場合があります。
前回マネージアセンブリで使用しようとしたとき、ランタイムがロードを拒否するほどひどく壊れていました。それはあなたがそれを使いたくないと私が考えることができる唯一の時です（そして、実際、私が試したのはとても長い間、状況は今さらに良くなるかもしれません）。私は過去にすべてのタイプの管理されていないバイナリでそれを広範囲に使用しましたが、問題はありませんでした。
欠点はありません。
しかし、参考までに、UPXに関して非常に一般的な誤解があります-
リソースは圧縮されているだけではありません
基本的に、「ローダー」の義務を持つ新しい実行可能ファイルを構築しており、「実際の」実行可能ファイルは、セクションが削除されて圧縮され、ローダー実行可能ファイルのバイナリデータリソースとして配置されます（リソースの種類に関係なく）元の実行可能ファイル）。
リバースエンジニアリング手法と tools を教育目的で使用するか、otherを使用すると、「ローダー実行可能ファイル」に関する情報が表示されます。元の実行可能ファイルに関する可変情報ではありません。
実行可能ファイルのサイズを小さくすることだけに関心がある場合は、ランタイムパッケージがある場合とない場合の実行可能ファイルのサイズを比較してみましたか？確かに、実行可能ファイルとともにパッケージ全体のサイズも含める必要がありますが、同じ基本パッケージを使用する実行可能ファイルが複数ある場合は、かなりの節約になります。
もう1つ注意すべき点は、プログラムで使用するグラフィックス/グリフです。フォームごとに繰り返すのではなく、グローバルデータモジュールに含まれる単一のTimagelistに統合することで、かなりのスペースを節約できます。各画像は16進数としてフォームリソースに保存されると思います。つまり、各バイトは2バイトを占めることになります... TResourceStreamを使用してRCDataリソースから画像を読み込むことで、これを少し縮小できます。
「不明な」ウイルスを検索するウイルススキャナーは、UPX圧縮実行可能ファイルにウイルスがあることを示すフラグを立てることができます。これは、いくつかのウイルスがUPXを使用して自分自身を隠すためだと言われています。ソフトウェアでUPXを使用しましたが、マカフィーはファイルにウイルスのフラグを付けます。
IMHOの日常的なUPXingは無意味ですが、理由は上記のとおりです。ほとんどの場合、メモリはディスクよりも高価です。
エリック：LZMAスタブはもっと大きいかもしれません。アルゴリズムが優れていても、必ずしも正味のプラスになるとは限りません。
UPXに非常に多くの誤警報がある理由は、そのオープンライセンスにより、マルウェアの作成者がUPXを免責で使用および変更できるためです。もちろん、この問題は業界に固有のものですが、残念ながら、すばらしいUPXプロジェクトはこの問題に悩まされています。
更新：Taggantプロジェクトが完了すると、UPXがサポートしていると仮定して、誤検知を発生させずにUPX（またはその他のもの）を使用する機能が強化されることに注意してください。
[〜＃〜] dep [〜＃〜] （データ実行防止）がオンになっているコンピューターでは動作しない可能性があると思います。