Vista relocation bug for executable with relocation

NTDEV
1

Hi All,

I think I have found a bug in Windows Vista when loading a v6.0 relocationable executable files with LoadLibrary function. It’s seems like the Vista uses a different algorithm for decideding the image base for CreateProcess and a different algorithm for LoadLibrary. The relocation, however, is done by CreateProcess algorithm.

I don’t think I’m fully understand the algorithm or it’s attributes.

As you can see in the WinDbg log below, “IEUser.exe”, which in dumpbin shows the following
OPTIONAL HEADER VALUES
10B magic # (PE32)
8.00 linker version
11000 size of code
38800 size of initialized data
0 size of uninitialized data
5301 entry point (01005301)
1000 base of code
12000 base of data
1000000 image base (01000000 to 0104BFFF)
1000 section alignment
200 file alignment
6.00 operating system version
6.00 image version
6.00 subsystem version
0 Win32 version
4C000 size of image
400 size of headers
5392A checksum
2 subsystem (Windows GUI)
8140 DLL characteristics
RESERVED - UNKNOWN
NX compatible
Terminal Server Aware

Should normally be loaded at 1000000 is now loaded at 00ac0000. The relocation process changes the binary but to the wrong address!!!
Original code:

.text:01005310 8B FF mov edi, edi
.text:01005312 55 push ebp
.text:01005313 8B EC mov ebp, esp
.text:01005315 83 EC 10 sub esp, 10h
.text:01005318 A1 00 20 01 01 mov eax, ___security_cookie

After relocaton:

00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h] <=== WRONG! SHOULD BE 0xad2000

Notice that the relocation base is ALWAYS start based on 4A000 (Even at your computer/load library application)!

Does anyone has a clue?

Best Regards,
Elad Raz
integrity-project.com

Microsoft (R) Windows Debugger Version 6.7.0005.1
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Windows\System32\rundll32.exe “C:\Program Files\Internet Explorer\IEUser.exe” start

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00df0000 00dfe000 rundll32.exe
ModLoad: 775d0000 776ee000 ntdll.dll
ModLoad: 770e0000 771b8000 C:\Windows\system32\kernel32.dll
ModLoad: 75e90000 75f2e000 C:\Windows\system32\USER32.dll
ModLoad: 77060000 770ab000 C:\Windows\system32\GDI32.dll
ModLoad: 76ef0000 76faf000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 77370000 77433000 C:\Windows\system32\RPCRT4.dll
ModLoad: 76fb0000 7705a000 C:\Windows\system32\msvcrt.dll
ModLoad: 75f30000 75f59000 C:\Windows\system32\imagehlp.dll
(c08.f64): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=001cfaf0 edx=77630f34 esi=fffffffe edi=77695d14
eip=77612ea8 esp=001cfb08 ebp=001cfb38 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:000> g
ModLoad: 73760000 7377e000 C:\Windows\system32\ShimEng.dll
ModLoad: 75c90000 75cbc000 C:\Windows\System32\apphelp.dll
ModLoad: 73460000 734e7000 C:\Windows\AppPatch\AcLayers.DLL
ModLoad: 76240000 76d0e000 C:\Windows\system32\SHELL32.dll
ModLoad: 76090000 760e5000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 77220000 77364000 C:\Windows\system32\ole32.dll
ModLoad: 76d10000 76d9c000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 75d40000 75d5e000 C:\Windows\System32\USERENV.dll
ModLoad: 75d20000 75d34000 C:\Windows\System32\Secur32.dll
ModLoad: 74ac0000 74b01000 C:\Windows\System32\WINSPOOL.DRV
ModLoad: 758e0000 758f4000 C:\Windows\System32\MPR.dll
ModLoad: 776f0000 7770e000 C:\Windows\system32\IMM32.DLL
ModLoad: 760f0000 761b7000 C:\Windows\system32\MSCTF.dll
ModLoad: 77720000 77729000 C:\Windows\system32\LPK.DLL
ModLoad: 761c0000 7623d000 C:\Windows\system32\USP10.dll
ModLoad: 74be0000 74d74000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6000.16386_none_5d07289e07e1d100\comctl32.dll
ModLoad: 00ac0000 00b0c000 ieuser.exe
ModLoad: 00ac0000 00b0c000 C:\Program Files\Internet Explorer\IEUser.exe
ModLoad: 74ba0000 74bdf000 C:\Windows\System32\uxtheme.dll
(c08.cfc): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000000 ecx=00000000 edx=7765f06d esi=00000000 edi=00000000
eip=77612ea8 esp=00c5f790 ebp=00c5f7bc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:001> u 0x0ac5318
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Internet Explorer\IEUser.exe
IEUser+0x5318:
00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h]
00ac531d 8365f800 and dword ptr [ebp-8],0
00ac5321 8365fc00 and dword ptr [ebp-4],0
00ac5325 57 push edi
00ac5326 bf4ee640bb mov edi,0BB40E64Eh
00ac532b 3bc7 cmp eax,edi
00ac532d 0f85b0090000 jne IEUser+0x5ce3 (00ac5ce3)
00ac5333 56 push esi
0:001> dd 004B2000
004b2000 1a2ccf0d dea0d859 0226c97f dea1d859
004b2010 1a13c938 dea2d859 0210cf57 dea3d859
004b2020 0211c622 dea4d859 1220cf54 dea5d859
004b2030 022fcf1f dea6d859 022cc984 dea7d859
004b2040 020fc9e2 dea8d859 022cc9ee dea9d859
004b2050 0215cf38 deaad859 0225cf55 deabd859
004b2060 0224c936 deacd859 0211c66a deadd859
004b2070 0222c6e4 deaed859 0233cc50 deb2d859
0:001> dd 0xad2000
00ad2000 bb40e64e 44bf19b1 ffffffff 00000000
00ad2010 00000000 00000000 00000000 00000000
00ad2020 00000000 00000000 00000000 00000000
00ad2030 00000000 00000000 00000000 00000000
00ad2040 ffffffff 00000000 00000000 00000000
00ad2050 00000000 00000000 00000000 00000000
00ad2060 00000000 00000000 00000000 00000000
00ad2070 00000000 00000000 00000000 00000000

2

I’m not sure that I understand what you think the issue is, but in general, if understand what you’re saying correctly, there’s
nothing saying that an executable has to be loaded at it’s preferred base address. That’s the point of all the RVA business. Also,
Vista has added address space layout randomization (http://en.wikipedia.org/wiki/Address_space_layout_randomization) to
intentionally do this in an attempt to thwart shellcode and return to libc attacks.

You should fix your symbols before investigating this any further, or do anything else for that matter.

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
.reload -f

Cheers,

mm

xxxxx@raztech.co.il wrote:

Hi All,

I think I have found a bug in Windows Vista when loading a v6.0 relocationable executable files with LoadLibrary function. It’s seems like the Vista uses a different algorithm for decideding the image base for CreateProcess and a different algorithm for LoadLibrary. The relocation, however, is done by CreateProcess algorithm.

I don’t think I’m fully understand the algorithm or it’s attributes.

As you can see in the WinDbg log below, “IEUser.exe”, which in dumpbin shows the following
OPTIONAL HEADER VALUES
10B magic # (PE32)
8.00 linker version
11000 size of code
38800 size of initialized data
0 size of uninitialized data
5301 entry point (01005301)
1000 base of code
12000 base of data
1000000 image base (01000000 to 0104BFFF)
1000 section alignment
200 file alignment
6.00 operating system version
6.00 image version
6.00 subsystem version
0 Win32 version
4C000 size of image
400 size of headers
5392A checksum
2 subsystem (Windows GUI)
8140 DLL characteristics
RESERVED - UNKNOWN
NX compatible
Terminal Server Aware

Should normally be loaded at 1000000 is now loaded at 00ac0000. The relocation process changes the binary but to the wrong address!!!
Original code:

.text:01005310 8B FF mov edi, edi
.text:01005312 55 push ebp
.text:01005313 8B EC mov ebp, esp
.text:01005315 83 EC 10 sub esp, 10h
.text:01005318 A1 00 20 01 01 mov eax, ___security_cookie

After relocaton:

00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h] <=== WRONG! SHOULD BE 0xad2000

Notice that the relocation base is ALWAYS start based on 4A000 (Even at your computer/load library application)!

Does anyone has a clue?

Best Regards,
Elad Raz
integrity-project.com

Microsoft (R) Windows Debugger Version 6.7.0005.1
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Windows\System32\rundll32.exe “C:\Program Files\Internet Explorer\IEUser.exe” start

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00df0000 00dfe000 rundll32.exe
ModLoad: 775d0000 776ee000 ntdll.dll
ModLoad: 770e0000 771b8000 C:\Windows\system32\kernel32.dll
ModLoad: 75e90000 75f2e000 C:\Windows\system32\USER32.dll
ModLoad: 77060000 770ab000 C:\Windows\system32\GDI32.dll
ModLoad: 76ef0000 76faf000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 77370000 77433000 C:\Windows\system32\RPCRT4.dll
ModLoad: 76fb0000 7705a000 C:\Windows\system32\msvcrt.dll
ModLoad: 75f30000 75f59000 C:\Windows\system32\imagehlp.dll
(c08.f64): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=001cfaf0 edx=77630f34 esi=fffffffe edi=77695d14
eip=77612ea8 esp=001cfb08 ebp=001cfb38 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:000> g
ModLoad: 73760000 7377e000 C:\Windows\system32\ShimEng.dll
ModLoad: 75c90000 75cbc000 C:\Windows\System32\apphelp.dll
ModLoad: 73460000 734e7000 C:\Windows\AppPatch\AcLayers.DLL
ModLoad: 76240000 76d0e000 C:\Windows\system32\SHELL32.dll
ModLoad: 76090000 760e5000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 77220000 77364000 C:\Windows\system32\ole32.dll
ModLoad: 76d10000 76d9c000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 75d40000 75d5e000 C:\Windows\System32\USERENV.dll
ModLoad: 75d20000 75d34000 C:\Windows\System32\Secur32.dll
ModLoad: 74ac0000 74b01000 C:\Windows\System32\WINSPOOL.DRV
ModLoad: 758e0000 758f4000 C:\Windows\System32\MPR.dll
ModLoad: 776f0000 7770e000 C:\Windows\system32\IMM32.DLL
ModLoad: 760f0000 761b7000 C:\Windows\system32\MSCTF.dll
ModLoad: 77720000 77729000 C:\Windows\system32\LPK.DLL
ModLoad: 761c0000 7623d000 C:\Windows\system32\USP10.dll
ModLoad: 74be0000 74d74000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6000.16386_none_5d07289e07e1d100\comctl32.dll
ModLoad: 00ac0000 00b0c000 ieuser.exe
ModLoad: 00ac0000 00b0c000 C:\Program Files\Internet Explorer\IEUser.exe
ModLoad: 74ba0000 74bdf000 C:\Windows\System32\uxtheme.dll
(c08.cfc): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000000 ecx=00000000 edx=7765f06d esi=00000000 edi=00000000
eip=77612ea8 esp=00c5f790 ebp=00c5f7bc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:001> u 0x0ac5318
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Internet Explorer\IEUser.exe
IEUser+0x5318:
00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h]
00ac531d 8365f800 and dword ptr [ebp-8],0
00ac5321 8365fc00 and dword ptr [ebp-4],0
00ac5325 57 push edi
00ac5326 bf4ee640bb mov edi,0BB40E64Eh
00ac532b 3bc7 cmp eax,edi
00ac532d 0f85b0090000 jne IEUser+0x5ce3 (00ac5ce3)
00ac5333 56 push esi
0:001> dd 004B2000
004b2000 1a2ccf0d dea0d859 0226c97f dea1d859
004b2010 1a13c938 dea2d859 0210cf57 dea3d859
004b2020 0211c622 dea4d859 1220cf54 dea5d859
004b2030 022fcf1f dea6d859 022cc984 dea7d859
004b2040 020fc9e2 dea8d859 022cc9ee dea9d859
004b2050 0215cf38 deaad859 0225cf55 deabd859
004b2060 0224c936 deacd859 0211c66a deadd859
004b2070 0222c6e4 deaed859 0233cc50 deb2d859
0:001> dd 0xad2000
00ad2000 bb40e64e 44bf19b1 ffffffff 00000000
00ad2010 00000000 00000000 00000000 00000000
00ad2020 00000000 00000000 00000000 00000000
00ad2030 00000000 00000000 00000000 00000000
00ad2040 ffffffff 00000000 00000000 00000000
00ad2050 00000000 00000000 00000000 00000000
00ad2060 00000000 00000000 00000000 00000000
00ad2070 00000000 00000000 00000000 00000000

3

This is due to ASLR. The unknown characteristics flag that your version of link.exe does not understand is dynamicbase, which flags an image as ASLR-able.

All in-box Microsoft built user mode binaries shipping with Vista and beyond have ASLR turned on.

  • S

-----Original Message-----
From: xxxxx@raztech.co.il
Sent: Monday, August 04, 2008 05:12
To: Windows System Software Devs Interest List
Subject: [ntdev] Vista relocation bug for executable with relocation

Hi All,

I think I have found a bug in Windows Vista when loading a v6.0 relocationable executable files with LoadLibrary function. It’s seems like the Vista uses a different algorithm for decideding the image base for CreateProcess and a different algorithm for LoadLibrary. The relocation, however, is done by CreateProcess algorithm.

I don’t think I’m fully understand the algorithm or it’s attributes.

As you can see in the WinDbg log below, “IEUser.exe”, which in dumpbin shows the following
OPTIONAL HEADER VALUES
10B magic # (PE32)
8.00 linker version
11000 size of code
38800 size of initialized data
0 size of uninitialized data
5301 entry point (01005301)
1000 base of code
12000 base of data
1000000 image base (01000000 to 0104BFFF)
1000 section alignment
200 file alignment
6.00 operating system version
6.00 image version
6.00 subsystem version
0 Win32 version
4C000 size of image
400 size of headers
5392A checksum
2 subsystem (Windows GUI)
8140 DLL characteristics
RESERVED - UNKNOWN
NX compatible
Terminal Server Aware

Should normally be loaded at 1000000 is now loaded at 00ac0000. The relocation process changes the binary but to the wrong address!!!
Original code:
==============
.text:01005310 8B FF mov edi, edi
.text:01005312 55 push ebp
.text:01005313 8B EC mov ebp, esp
.text:01005315 83 EC 10 sub esp, 10h
.text:01005318 A1 00 20 01 01 mov eax, ___security_cookie

After relocaton:
================
00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h] <=== WRONG! SHOULD BE 0xad2000

Notice that the relocation base is ALWAYS start based on 4A000 (Even at your computer/load library application)!

Does anyone has a clue?

Best Regards,
Elad Raz
integrity-project.com

------------------------------------------------------

Microsoft (R) Windows Debugger Version 6.7.0005.1
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Windows\System32\rundll32.exe “C:\Program Files\Internet Explorer\IEUser.exe” start

Symbol search path is: Invalid

Symbol loading may be unreliable without a symbol search path.
Use .symfix to have the debugger choose a symbol path.
After setting your symbol path, use .reload to refresh symbol locations.

Executable search path is:
ModLoad: 00df0000 00dfe000 rundll32.exe
ModLoad: 775d0000 776ee000 ntdll.dll
ModLoad: 770e0000 771b8000 C:\Windows\system32\kernel32.dll
ModLoad: 75e90000 75f2e000 C:\Windows\system32\USER32.dll
ModLoad: 77060000 770ab000 C:\Windows\system32\GDI32.dll
ModLoad: 76ef0000 76faf000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 77370000 77433000 C:\Windows\system32\RPCRT4.dll
ModLoad: 76fb0000 7705a000 C:\Windows\system32\msvcrt.dll
ModLoad: 75f30000 75f59000 C:\Windows\system32\imagehlp.dll
(c08.f64): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=001cfaf0 edx=77630f34 esi=fffffffe edi=77695d14
eip=77612ea8 esp=001cfb08 ebp=001cfb38 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:000> g
ModLoad: 73760000 7377e000 C:\Windows\system32\ShimEng.dll
ModLoad: 75c90000 75cbc000 C:\Windows\System32\apphelp.dll
ModLoad: 73460000 734e7000 C:\Windows\AppPatch\AcLayers.DLL
ModLoad: 76240000 76d0e000 C:\Windows\system32\SHELL32.dll
ModLoad: 76090000 760e5000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 77220000 77364000 C:\Windows\system32\ole32.dll
ModLoad: 76d10000 76d9c000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 75d40000 75d5e000 C:\Windows\System32\USERENV.dll
ModLoad: 75d20000 75d34000 C:\Windows\System32\Secur32.dll
ModLoad: 74ac0000 74b01000 C:\Windows\System32\WINSPOOL.DRV
ModLoad: 758e0000 758f4000 C:\Windows\System32\MPR.dll
ModLoad: 776f0000 7770e000 C:\Windows\system32\IMM32.DLL
ModLoad: 760f0000 761b7000 C:\Windows\system32\MSCTF.dll
ModLoad: 77720000 77729000 C:\Windows\system32\LPK.DLL
ModLoad: 761c0000 7623d000 C:\Windows\system32\USP10.dll
ModLoad: 74be0000 74d74000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6000.16386_none_5d07289e07e1d100\comctl32.dll
ModLoad: 00ac0000 00b0c000 ieuser.exe
ModLoad: 00ac0000 00b0c000 C:\Program Files\Internet Explorer\IEUser.exe
ModLoad: 74ba0000 74bdf000 C:\Windows\System32\uxtheme.dll
(c08.cfc): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000000 ecx=00000000 edx=7765f06d esi=00000000 edi=00000000
eip=77612ea8 esp=00c5f790 ebp=00c5f7bc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77612ea8 cc int 3
0:001> u 0x0ac5318
 ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Internet Explorer\IEUser.exe
IEUser+0x5318:
00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h]
00ac531d 8365f800 and dword ptr [ebp-8],0
00ac5321 8365fc00 and dword ptr [ebp-4],0
00ac5325 57 push edi
00ac5326 bf4ee640bb mov edi,0BB40E64Eh
00ac532b 3bc7 cmp eax,edi
00ac532d 0f85b0090000 jne IEUser+0x5ce3 (00ac5ce3)
00ac5333 56 push esi
0:001> dd 004B2000
004b2000 1a2ccf0d dea0d859 0226c97f dea1d859
004b2010 1a13c938 dea2d859 0210cf57 dea3d859
004b2020 0211c622 dea4d859 1220cf54 dea5d859
004b2030 022fcf1f dea6d859 022cc984 dea7d859
004b2040 020fc9e2 dea8d859 022cc9ee dea9d859
004b2050 0215cf38 deaad859 0225cf55 deabd859
004b2060 0224c936 deacd859 0211c66a deadd859
004b2070 0222c6e4 deaed859 0233cc50 deb2d859
0:001> dd 0xad2000
00ad2000 bb40e64e 44bf19b1 ffffffff 00000000
00ad2010 00000000 00000000 00000000 00000000
00ad2020 00000000 00000000 00000000 00000000
00ad2030 00000000 00000000 00000000 00000000
00ad2040 ffffffff 00000000 00000000 00000000
00ad2050 00000000 00000000 00000000 00000000
00ad2060 00000000 00000000 00000000 00000000
00ad2070 00000000 00000000 00000000 00000000

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Hi MM,

Thank you for the reply! :slight_smile:

I do know about ASLR and I intentionally didn’t add symbols to the process (So I won’t misunderstood).
Normally executable don’t have relocation, (this is the default setting for VC compilers), in that case they CANNOT be loaded elsewhere then the preferred loading address (Remember they are .EXE file and all code internally is fixed according baseAddress).
All I’m saying is, that executable file that has relocation section (e.g. can be loaded everywhere) gets a special address when loaded (VIA CREATEPROCESS) in Vista, he get 0x4A0000 no matter what (You can check it yourself). During that process loading all relocation pointers are change to that address.
When I use LoadLibrary on that specific .exe file (IEUSER.exe for example - you can see my command line is RunDll32 on that process), it get a random base address, as you said, and it’s OK from my side.
My problem (And now i’m sure it’s Vista kernel bug) is that during the relocation process of that .EXE with the random XXXXX address there is a bug; Instead of using XXXXX in the relocation it’s uses 0x4A0000 as an hardcoded number NO MATTER WHAT.
This cause the pointers inside the .EXE to be INVALID and pointing into anywhere from 0x4A0000…EndOfImage.

I hope I made myself clear,
Regards,
Elad Raz
integrity-project.com

5

In the example I just gave, I used rundll32 over ieuser.exe.

ieuser.exe got a base address of 00ac0000 in it’s WinMain (after relocation) there is:
00ac5318 a100204b00 mov eax,dword ptr ds:[004B2000h]

Reading the DWORD “004B2000h” which is 0x4A0000 + 0x12000.
What it’s should be said is: 0xAC0000 + 0x12000 = 0xAD2000!!

Cheers,
Elad.

6

How are you calling LoadLibrary on ieuser.exe? Are you using LOAD_LIVRARY_AS_DATA_FILE?

If so, the file is mapped as a plain (non-image) section, and no special processing of any sort based on the image headers is enabled.

As far as I know, LoadLibrary will refuse to map a .exe as an image section due to the lack of the “dll” characteristics value.

  • S

-----Original Message-----
From: xxxxx@raztech.co.il
Sent: Monday, August 04, 2008 09:41
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista relocation bug for executable with relocation

Hi MM,

Thank you for the reply! :slight_smile:

I do know about ASLR and I intentionally didn’t add symbols to the process (So I won’t misunderstood).
Normally executable don’t have relocation, (this is the default setting for VC compilers), in that case they CANNOT be loaded elsewhere then the preferred loading address (Remember they are .EXE file and all code internally is fixed according baseAddress).
All I’m saying is, that executable file that has relocation section (e.g. can be loaded everywhere) gets a special address when loaded (VIA CREATEPROCESS) in Vista, he get 0x4A0000 no matter what (You can check it yourself). During that process loading all relocation pointers are change to that address.
When I use LoadLibrary on that specific .exe file (IEUSER.exe for example - you can see my command line is RunDll32 on that process), it get a random base address, as you said, and it’s OK from my side.
My problem (And now i’m sure it’s Vista kernel bug) is that during the relocation process of that .EXE with the random XXXXX address there is a bug; Instead of using XXXXX in the relocation it’s uses 0x4A0000 as an hardcoded number NO MATTER WHAT.
This cause the pointers inside the .EXE to be INVALID and pointing into anywhere from 0x4A0000…EndOfImage.

I hope I made myself clear,
Regards,
Elad Raz
integrity-project.com

—

7

No, I’m not using LoadLibraryEx (or any of it’s special arguments), I used the good old RUNDLL32.EXE which call the normal kernel32!LoadLibraryA.
You can see in the windbg log that all module where loaded, and if you will dump the IAT you will see that all references were resolved.

Cheers,

  • Elad Raz
8

So, I’m not entirely clear as to what you’re doing. Are you giving rundll32 a .exe and expecting it to map it as an (image) DLL or what?

I’m trying to understand what it is that you are doing, because I’m not really following what you’re doing thus far. It sound to me like you said you’re trying to get rundll32 to load ieuser.exe. This doesn’t really make sense, though - so what is it exactly that you’re doing?

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@raztech.co.il
Sent: Monday, August 04, 2008 11:13 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista relocation bug for executable with relocation

No, I’m not using LoadLibraryEx (or any of it’s special arguments), I used the good old RUNDLL32.EXE which call the normal kernel32!LoadLibraryA.
You can see in the windbg log that all module where loaded, and if you will dump the IAT you will see that all references were resolved.

Cheers,

  • Elad Raz

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

Yes, that is exactly that.
I’m trying to make LoadLibrary work over an executable files. I can’t understand why it’s not possible to use exportable functions from an exe…
True, LoadLibrary doesn’t resolve imports if the module that is loaded is an Executable, also it’s doesn’t call to it’s start address (main entry point).

However, IT DOES fixing up sections, adding it as a module, making relocations and more…
On Windows XP, the relocation process works with the real base-adress.
On Vista, the relocation process uses imaginary value.

  • Elad Raz
10

Bottom line: This is not going to work. LoadLibrary doesn’t work on a .exe in this way. In fact, pre-Vista at least, LdrLoadDll will explicitly check to make sure that it is mapping a dll by looking at the Characteristics value and making sure the binary is stamped as a DLL, or it will fail the load.

Using LoadLibrary on a .exe is only supported for usage with the resource management functions. The function explicitly doesn’t support this attempted usage as part of the API contract.

You may static link (at link time) an exported function on a .exe if you have an import library for it. There is no supported API to load a .exe for running executable code for it at runtime, the closest supported mechanism is to static link at build time. If you want to try and do this, you’ll have to map the file yourself with SEC_IMAGE, and deal with relocations and resolving imports. Be aware that even taking this approach may not work reliably, as the .exe in question won’t be properly inserted into the loaded module list.

This isn’t a bug, as LoadLibrary isn’t designed to be used to map a .exe to run code out of it.

Why do you think that you need to do this in the first place?

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@raztech.co.il
Sent: Monday, August 04, 2008 12:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista relocation bug for executable with relocation

Yes, that is exactly that.
I’m trying to make LoadLibrary work over an executable files. I can’t understand why it’s not possible to use exportable functions from an exe…
True, LoadLibrary doesn’t resolve imports if the module that is loaded is an Executable, also it’s doesn’t call to it’s start address (main entry point).

However, IT DOES fixing up sections, adding it as a module, making relocations and more…
On Windows XP, the relocation process works with the real base-adress.
On Vista, the relocation process uses imaginary value.

  • Elad Raz

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

xxxxx@raztech.co.il wrote:

Yes, that is exactly that.
I’m trying to make LoadLibrary work over an executable files. I can’t understand why it’s not possible to use exportable functions from an exe…

This has never been supported because there’s no way to make it work
reliably. When LoadLibrary loads a DLL, it runs the main entry point.
With an EXE, the main entry point always ends with a call to
ExitProcess, so LoadLibrary would never return. Because of that,
LoadLibrary cannot run the main entry point. Because of THAT, there’s
no way to initialize global data. That’s makes it less than useful.

True, LoadLibrary doesn’t resolve imports if the module that is loaded is an Executable, also it’s doesn’t call to it’s start address (main entry point).

However, IT DOES fixing up sections, adding it as a module, making relocations and more…
On Windows XP, the relocation process works with the real base-adress.
On Vista, the relocation process uses imaginary value.

No one ever promised that this would work. That fact that it mostly
worked in XP was merely an accident. It doesn’t work on Vista. That’s
just the way it is.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Hi Guys,

I don’t want to use an exportable function from an executable, i’m experimenting on a completely different thing. I know that the Main isn’t called and imports aren’t fix.
BTW MSDN does say on LoadLibrary that the filename is an executable file (.DLL or .EXE).

Most of you just don’t care and probably never encounter this bug, and it is a bug:

  1. LdrLoadDll see that in Characteristics it’s not a DLL file and it’s not resolve it’s import/call main.
  2. LdrLoadDll DOES resolve the relocation. The function is called on both XP/VISTA. If the function wasn’t called on the first place, I was really don’t give a damn. But it DOES called, and this is the bug. The relocation is wrongly resolved and the MS kernel developer should pay attention to that piece of code.

Ways that you will see the bug: (And the bottom line of this thread)
On Vista, executable with a relocation section will always reloc itself during CreateProcess (!) Always and into a spesific location.

  • Elad.
13

It also says this:

‘LoadLibrary can be used to map a DLL module and return a handle that can be used in GetProcAddress to get the address of a DLL
function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .exe file to get a
handle that can be used in FindResource or LoadResource. However, do not use LoadLibrary to run an .exe file, use the CreateProcess
function.’

I’m still really sure why you are doing any of this.

Good luck,

mm

xxxxx@raztech.co.il wrote:

Hi Guys,

I don’t want to use an exportable function from an executable, i’m experimenting on a completely different thing. I know that the Main isn’t called and imports aren’t fix.
BTW MSDN does say on LoadLibrary that the filename is an executable file (.DLL or .EXE).

Most of you just don’t care and probably never encounter this bug, and it is a bug:

  1. LdrLoadDll see that in Characteristics it’s not a DLL file and it’s not resolve it’s import/call main.
  2. LdrLoadDll DOES resolve the relocation. The function is called on both XP/VISTA. If the function wasn’t called on the first place, I was really don’t give a damn. But it DOES called, and this is the bug. The relocation is wrongly resolved and the MS kernel developer should pay attention to that piece of code.

Ways that you will see the bug: (And the bottom line of this thread)
On Vista, executable with a relocation section will always reloc itself during CreateProcess (!) Always and into a spesific location.

  • Elad.
14

>How are you calling LoadLibrary on ieuser.exe? Are you using

LOAD_LIVRARY_AS_DATA_FILE?
If so, the file is mapped as a plain (non-image) section, and no special
processing
of any sort based on the image headers is enabled.

No.

LOAD_LIBRARY_AS_DATA_FILE uses the image section object and maps the binary
according to the section table in the header.

It does NOT do relocations and import resolution though, and no DllMain call.

LOAD_LIBRARY_AS_DATA_FILE should work on EXEs, since the resource (icon and
version) access for EXEs work using this way, so is Event Viewer API in
advapi32 which maps the event source EXE/DLL/SYS as a datafile to find the
resource-embedded event log MC-generated data.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

15

xxxxx@raztech.co.il wrote:

I don’t want to use an exportable function from an executable, i’m experimenting on a completely different thing. I know that the Main isn’t called and imports aren’t fix.
BTW MSDN does say on LoadLibrary that the filename is an executable file (.DLL or .EXE).

Yes, “to get a handle that can be used in FindResource or
LoadResource.” It also says “do not use LoadLibrary to run an .exe file.”

Most of you just don’t care and probably never encounter this bug, and it is a bug:

  1. LdrLoadDll see that in Characteristics it’s not a DLL file and it’s not resolve it’s import/call main.
  2. LdrLoadDll DOES resolve the relocation. The function is called on both XP/VISTA. If the function wasn’t called on the first place, I was really don’t give a damn. But it DOES called, and this is the bug. The relocation is wrongly resolved and the MS kernel developer should pay attention to that piece of code.

I still don’t understand why you call it a bug. You are relying on
undocumented behavior. That behavior has now changed. Too bad.

Ways that you will see the bug: (And the bottom line of this thread)
On Vista, executable with a relocation section will always reloc itself during CreateProcess (!) Always and into a spesific location.

I don’t get what you are trying to say. When a /dynamicbase executable
is run, it gets a “random” base address, but the relocation is cached.
It will get the same relocation until a reboot or until the file is changed.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

16

Ok,

I’ll repeat on what you guys are saying:

  1. LoadLibrary can’t load an executable file, unless you are using it for resources.
  2. The undocumented behavior of relocation fix is irrelevant in that case since you aren’t allowed on calling any procedure. Hence internal function change doesn’t affect anyone, and it is not a bug.

Still, although it isn’t a bug, the function is written pretty poorly in my opinion, since it change the relocation information wrongly (No matter how you call it)

Ok, this thread exhausted itself,
Thanks for anyone who helped me understand better!

Regards,

  • Elad