locked
Get application load address in memory RRS feed

  • Question

  • How can I find the memory address of the code for the first module (the <g class="gr_ gr_363 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="363" id="363">exe</g>) of my application?  I am writing a secure app and want to be able to get a CRC for my portion of the code.  GetModuleInformation returns the compiled base for the code not where it is actually loaded to.

    Tuesday, May 15, 2018 6:58 AM

All replies

  • GetModuleHandle for the main program? The handle is basically the start address in memory.

    -- pa

    Tuesday, May 15, 2018 2:49 PM
  • GetModuleHandle() does return an address but its where the application was compiled from, in my case $00400000, this is not where its loaded into memory as all code has to be relocatable.  Where its loaded to depends upon:

    The amount of memory in the system

    What services are running

    What other apps are running

    How much memory is being used for data

    This is why I am struggling to find out where the <g class="gr_ gr_797 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="797" id="797">exe</g> is actually loaded.  Thanks for the info though because I hadn't realised the handle returned from GetModuleHandle() was the compiled address.

    Peter

    Wednesday, May 16, 2018 6:04 AM
  • What other apps are running

    So, you want the _physical_ address?

    - pa

    Wednesday, May 16, 2018 10:18 AM
  • I created a simple, 32 bit console application as follows -

    // AddressTest.cpp : Defines the entry point for the console application.
    //
    
    #include "stdafx.h"
    
    
    int main()
    {
    	MODULEENTRY32 me = { sizeof me };
    
    	HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, 0);
    
    	HMODULE hMod = GetModuleHandle(NULL);
    
    	_tprintf_s(_T("Module handle is 0x%p\n\n"), hMod);
    
    	if (Module32First(hSnap, &me))
    	{
    		_tprintf(_T("Enumerate all modules in this process and their base addresses\n"));
    
    		do
    		{
    			_tprintf_s(_T("Module Name : %s, Base Address : 0x%p\n"), me.szModule, me.modBaseAddr);
    
    		} while (Module32Next(hSnap, &me));
    	}
    
    	CloseHandle(hSnap);
    
    	_tprintf(_T("Hit a key to exit\n"));
    
    	_gettch();
    
        return 0;
    }
    


    When building the application I accepted all linker defaults.  Output of dumpbin on the executable was -

    Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    
    Dump of file AddressTest.exe
    
    PE signature found
    
    File Type: EXECUTABLE IMAGE
    
    FILE HEADER VALUES
                 14C machine (x86)
                   9 number of sections
            5AFC3551 time date stamp Wed May 16 09:42:41 2018
                   0 file pointer to symbol table
                   0 number of symbols
                  E0 size of optional header
                 102 characteristics
                       Executable
                       32 bit word machine
    
    OPTIONAL HEADER VALUES
                 10B magic # (PE32)
               14.00 linker version
                5000 size of code
                4400 size of initialized data
                   0 size of uninitialized data
               11046 entry point (00411046) @ILT+65(_mainCRTStartup)
                1000 base of code
                1000 base of data
              400000 image base (00400000 to 0041EFFF)
                1000 section alignment
    

    You can see that the default base address provided by the linker was 0x0040000.

    Running the application produced the following output -

    Module handle is 0x010F0000
    
    Enumerate all modules in this process and their base addresses
    Module Name : AddressTest.exe, Base Address : 0x010F0000
    Module Name : ntdll.dll, Base Address : 0x77CE0000
    Module Name : KERNEL32.DLL, Base Address : 0x77B50000
    Module Name : KERNELBASE.dll, Base Address : 0x75820000
    Module Name : VCRUNTIME140D.dll, Base Address : 0x67250000
    Module Name : ucrtbased.dll, Base Address : 0x507A0000
    

    So you can see that the module handle did contain the virtual base address, and that the loader did relocate the code from the default base address provided by the linker.

    Changing the linker settings to specify the same base address at which kernel32.dll was loaded resulted in the following dumpbin outputs -

    Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    
    Dump of file AddressTest.exe
    
    PE signature found
    
    File Type: EXECUTABLE IMAGE
    
    FILE HEADER VALUES
                 14C machine (x86)
                   9 number of sections
            5AFC3755 time date stamp Wed May 16 09:51:17 2018
                   0 file pointer to symbol table
                   0 number of symbols
                  E0 size of optional header
                 102 characteristics
                       Executable
                       32 bit word machine
    
    OPTIONAL HEADER VALUES
                 10B magic # (PE32)
               14.00 linker version
                5000 size of code
                4400 size of initialized data
                   0 size of uninitialized data
               11046 entry point (77B61046) @ILT+65(_mainCRTStartup)
                1000 base of code
                1000 base of data
            77B50000 image base (77B50000 to 77B6EFFF)
                1000 section alignment
    

    Running the executable produced -

    Module handle is 0x772E0000
    
    Enumerate all modules in this process and their base addresses
    Module Name : AddressTest.exe, Base Address : 0x772E0000
    Module Name : ntdll.dll, Base Address : 0x77CE0000
    Module Name : KERNEL32.DLL, Base Address : 0x77B50000
    Module Name : KERNELBASE.dll, Base Address : 0x75820000
    Module Name : VCRUNTIME140D.dll, Base Address : 0x6F360000
    Module Name : ucrtbased.dll, Base Address : 0x565B0000
    

    Again, the loader relocated the executable and the module handle was the virtual base address.

    Wednesday, May 16, 2018 1:54 PM