CODEWITHSUNDEEP
cwindowslinkerexecutableportable-executable
Tyler Durden
Tyler Durden

Reputation: 11522

In a compressed PE must the virtual size of the data section match the raw size?

In working with a compressed PE (Windows console EXE) that has a file alignment and section alignment of 4 bytes, I notice that if virtual size and raw size of the sections match, then the program loads, but if virtual size of the data section, the last section, does not match then Windows refuses to load it, even though by the specification you should be able to have a virtual size larger than a raw size.

Is this some kind of hidden constraint on compressed PEs?

I have pasted a dumpbin /headers of the exe below:

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

For example if you change the virtual size of the above .data section to 3106 the program will not load, even though the size of initialized data (0x5000) is more than enough to accomodate the additional memory.

Upvotes: 0

Views: 2482

Answers (1)

mox
mox

Reputation: 6314

No, there are not special constraints related to compressed images, since as long as your image is PE compliant, the loader does not care about the compression. Compression is handled by the stub, not the loader.

Can you provide your image for further analysis?

Just by looking at the output of dumpbin, the image looks unusual..There are no directory at all, pretty strange. It looks like the issue with the loader is not directly related to the alignement, but malformation of the image file. Did you try to have a look at your image file using other PE tools (e.g. PeStudio, CFF Explorer..?)

Upvotes: 1

Related Questions