0

ファイル アラインメントとセクション アラインメントが 4 バイトの圧縮された PE (Windows コンソール EXE) を使用しているときに、セクションの仮想サイズと生のサイズが一致するとプログラムが読み込まれることに気付きましたが、データ セクションの仮想サイズが、最後のセクションが一致しない場合、仕様では生のサイズよりも大きな仮想サイズを持つことができるはずですが、Windows はそれをロードすることを拒否します。

これは、圧縮された PE に対する何らかの隠れた制約ですか?

以下のexeのダンプビン/ヘッダーを貼り付けました：

Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file ba42x.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               2 number of sections
        50AABC14 time date stamp Mon Nov 19 18:09:08 2012
               0 file pointer to symbol table
               0 number of symbols
              60 size of optional header
             10F characteristics
                   Relocations stripped
                   Executable
                   Line numbers stripped
                   Symbols stripped
                   32 bit word machine

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            2.03 linker version
             BD0 size of code
            5000 size of initialized data
               0 size of uninitialized data
              CC entry point (004000CC)
              CC base of code
             C9C base of data
          400000 image base (00400000 to 00403FFF)
               4 section alignment
               4 file alignment
            4.00 operating system version
            0.00 image version
            4.00 subsystem version
               0 Win32 version
            4000 size of image
              CC size of headers
               0 checksum
               3 subsystem (Windows CUI)
               0 DLL characteristics
           10000 size of stack reserve
            1000 size of stack commit
               0 size of heap reserve
               0 size of heap commit
               0 loader flags
               0 number of directories


SECTION HEADER #1
   .text name
     BD0 virtual size
      CC virtual address (004000CC to 00400C9B)
     BD0 size of raw data
      CC file pointer to raw data (000000CC to 00000C9B)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
E0000020 flags
         Code
         Execute Read Write

SECTION HEADER #2
   .data name
    3102 virtual size
     C9C virtual address (00400C9C to 00403D9D)
    3102 size of raw data
     C9C file pointer to raw data (00000C9C to 00003D9D)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0000040 flags
         Initialized Data
         Read Write

  Summary

        3104 .data
         BD0 .text

たとえば、上記の .data セクションの仮想サイズを 3106 に変更すると、初期化されたデータ (0x5000) のサイズが追加のメモリを収容するのに十分なサイズであっても、プログラムはロードされません。

4

1 に答える 1

1

いいえ、イメージが PE に準拠している限り、ローダーは圧縮を気にしないため、圧縮されたイメージに関連する特別な制約はありません。圧縮は、ローダーではなくスタブによって処理されます。

さらに分析するために画像を提供できますか?

dumpbin の出力を見るだけで、画像が変に見えます..ディレクトリがまったくなく、かなり変です。ローダーの問題は、位置合わせとは直接関係がなく、画像ファイルの形式に問題があるようです。他の PE ツール (PeStudio、CFF Explorer など) を使用して画像ファイルを確認しようとしましたか?

于 2012-12-06T08:06:23.073 に答える