0

So for system32 binaries, dumpbin will report:

...
        6178 entry point (0000000140006178)
...
SECTION HEADER #1
   .text name
    63E6 virtual size
    1000 virtual address (0000000140001000 to 00000001400073E5)
    6400 size of raw data
     400 file pointer to raw data (00000400 to 000067FF)

But the entry point at RVA 6178 maps to file offset 6178-1000+400 = 5578h (21,880), but the file opened in a hex editor only goes up to 4A00h (18,944).

Also, the file size is reported as 38,400 bytes by the shell.

So it seems that the .text section is encrypted or some other magic for system binaries. Anyone know what's going on?

  • What's strange is a) CFF explorer will read the file correctly in the Address Converter hex dump display and b) if you copy the file using windows explorer to the desktop, everything looks ok in that copy - it displays all 20,480 bytes of the file and the sections look to be unencrypted somehow. I wasn't aware of any PE encryption used by Windows though for system files. – grv grv Mar 09 '12 at 05:40

1 Answers1

0

As far as I can see, the Entry point is not pointing to the .text section. This is not unusual for encrypted binaries. Using CFF Explorer or other tools like PeStudio, PE Explorer, etc, you might take a look at the mapping of the Entry Point and the pointed Section.

mox
  • 6,084
  • 2
  • 23
  • 35
  • I don't follow. Entry point VA 140006178 lies within bound of .text section VA addresses (0000000140001000 to 00000001400073E5). EP does not need to point to the start of the .text section. – grv grv Mar 16 '12 at 04:42
  • I never said that the EP needs to point the start of the .text section. – mox Mar 16 '12 at 07:31
  • OK, I'm not sure what you meant then by EP not pointing to the .text section. – grv grv Mar 17 '12 at 19:48