6

I'm reversing a malicious 32-bit x86 Windows executable. Statically reviewing PE headers in Ghidra, I see that ImageBase is set to 0x400000 as expected. However, when the binary is loaded into memory, the initial RVA does not match the ImageBase defined in the file. For example, I have seen the in-memory base address set to 0x4B0000 and 0x900000. This behavior occurs on a clean VM, and when debugging with Immunity and x32dbg as well as IDA Free.

My understanding is that the Windows loader reads ImageBase and uses that offset to begin mapping sections into virtual address space. Because system code handles loading, and my system is clean upon first execution, my assumption is that the unusual ImageBase is a symptom of a loader nuance rather than tampering. I've never encountered this scenario and would appreciate any insights.

MD5: 1f63d04ee95ea041f2f6b1e818d94a7c

SHA1: 823ad6abb05f2393c44cf4b7f1d00e32ac04d1d1

ImageBase set to 0x400000 when viewing PE headers in Ghidra:

ImageBase set to 0x400000

ImageBase in memory-mapped PE header (0x4B0000) does not match ImageBase set in static file:

PE header dump

PE sections mapped into memory with ImageBase at 0x4B0000

PE sections mapped into memory

j5bb
  • 61
  • 3
  • 2
    if your system is aslr enabled (any is > xp) then this is a security feature and windows loader will randomize the address space layout on each run – blabb Aug 17 '20 at 06:12
  • Thanks for bringing ASLR to my attention @blabb. I'll keep that feature in mind going forward. After disabling ASLR on a fresh Windows 10 VM and restarting, I continued to see a non-0x400000 ImageBase when loading the binary into various debuggers. I note this here only to rule out ASLR as the cause of the RVA randomization in this particular case. – j5bb Aug 19 '20 at 13:19
  • ASLR is for the imported DLLs generally. This is the preferred base address. However, if this memory location is occupied by other image, the loader has the right to place it at other locations provided it gets enough continous space in memory. – BoRRis Mar 10 '21 at 21:28
  • @j5bb It depends on which version of Windows 10 you are using with regards to ASLR. The last version of 10 that can disable ASLR is build 1703. In all builds later than that one, the switches that say they disable ASLR have no effect.

    Also, in each disassembler: Ghidra, IDA, Binary Ninja etc, there is a setting to rebase the database to match the base address in memory. This can alleviate some of the pain.

     – Utkonos Apr 24 '22 at 05:23

1 Answers1

9

This is just a preferred address. Windows can load the binary at almost any address and rebase it to this new location.

ImageBase: The preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98, and Windows Me is 0x00400000.

Source: MSDN

Paweł Łukasik
  • 4,912
  • 1
  • 14
  • 27