PE file format + relocations
-
I'm writing a custom PE loader, and I finished everything except relocations, which I can't find anywhere in the EXE. I'm using Windows's notepad.exe as my initial test. Both the BASERELOC directory entry (DataDirectory[5]) and the PointerToRelocations field of the .text section are set to all 0's. Also, there is no ".reloc" section. Any ideas where these relocations would be located?
-
I'm writing a custom PE loader, and I finished everything except relocations, which I can't find anywhere in the EXE. I'm using Windows's notepad.exe as my initial test. Both the BASERELOC directory entry (DataDirectory[5]) and the PointerToRelocations field of the .text section are set to all 0's. Also, there is no ".reloc" section. Any ideas where these relocations would be located?
Hi zildjohn01, The image may be bound. I know binding overwrites the IMAGE_THUNK_DATA entires of the IAT. But I also believe that an image which cannot load at it's preferred address (after binding) will fail to load. Jeff
-
I'm writing a custom PE loader, and I finished everything except relocations, which I can't find anywhere in the EXE. I'm using Windows's notepad.exe as my initial test. Both the BASERELOC directory entry (DataDirectory[5]) and the PointerToRelocations field of the .text section are set to all 0's. Also, there is no ".reloc" section. Any ideas where these relocations would be located?
Since the EXE is the first thing to load into the process, and therefore there are very few allocations (a few DLLs are pre-mapped, such as kernel32.dll), it very rarely needs relocating. You might do it if you wanted to load an EXE as a DLL in another process, but more commonly you just want the resources out of it, in which case you specify LOAD_LIBRARY_AS_DATAFILE. Because relocation is so very rarely unnecessary, the linker provides an option, /FIXED, to control generation of relocation information. Since at least VC6, the default for EXEs has been to set /FIXED and not generate relocations, and for DLLs, to set /FIXED:NO (which does generate relocations). It's not that you can't find them, it's that they aren't there. The relocations information in each section is really for the use of the linker to link .obj files into an .exe or .dll. In a finished DLL, only the Base Relocations (.reloc section) are present. .NET executables have a .reloc section containing one relocation, which is a pointer to the start of the Import Address Table. When the loader loads the DLL or EXE, it overwrites this entry with the address of the function imported - for an executable,
_CorExeMainin mscoree.dll. The two bytes before the address that is updated are 0xFF 0x25, which are an indirect JMP instruction. The 'entry point' field in the IMAGE_OPTIONAL_HEADER structure points to the start of this instruction, so on loading the program, Windows calls this address which immediately transfers control to _CorExeMain. DLLs are similar but use _CorDllMain. In this way, a version of Windows which knows nothing about .NET can still load a .NET program as if it were any other kind of program with very little x86 code included. I'm guessing it's compiled at this odd location - after the Import Name Table - so it's on a page that will get discarded very quickly, as this instruction will run exactly once. I believe newer versions of the OS understand .NET programs and just invoke mscoree.dll directly, not even bothering to map this page. The 64-bit versions would have to, if they're going to create a 64-bit process (particularly on Itanium where 0xFF 0x25 means something else entirely - actually you'd get an alignment fault straightaway as that processor requires instructions to be aligned on 128-bit boundaries). If you specify /platform:itanium or /platform:x64, the C# 2.0 compiler generates a PE32+ structure, no import tables, and puts 0 in the 'entry point' field, so the 64-bit OS must understand .NET binaries d -
I'm writing a custom PE loader, and I finished everything except relocations, which I can't find anywhere in the EXE. I'm using Windows's notepad.exe as my initial test. Both the BASERELOC directory entry (DataDirectory[5]) and the PointerToRelocations field of the .text section are set to all 0's. Also, there is no ".reloc" section. Any ideas where these relocations would be located?
Awesome thanks, you guys are both right, they were resolved during linking. My options now are to either create a separate process, or manually parse the assembly code (ugh). We'll see how this goes.