From: alexfrunews@gmail.com   
      
   On Saturday, January 8, 2022 at 4:26:08 AM UTC-8, James Harris wrote:   
   > On 07/01/2022 02:44, Alexei A. Frounze wrote:   
   > > On Wednesday, January 5, 2022 at 8:39:10 AM UTC-8, James Harris wrote:   
   > >> I should say I remember someone (Alex?) since long ago espousing a   
   > >> certain .exe format as being very easy to relocate but I am not sure   
   > >> whether it was suitable for 32-bit code,   
   > >   
   > > The 32-bit PE image is easy to relocate (the 64-bit PE should be easy too),   
   > > there's only one x86-32 kind of relocation: IMAGE_REL_BASED_HIGHLOW   
   > > (=3) in the .reloc section. That is, if the base address differs from the   
   > > one in the image header, you add a constant to all locations enumerated in   
   > > the .reloc section.   
   > A relocatable PE may be easy to relocate ... but it doesn't seem so easy   
   > to create. :-(   
      
   Not easy because you don't have the right tools or because you haven't   
   yet worked out the formats on both sides (input obj and output exe)?   
      
   I simply wrote my own linker to be able to produce the different kinds   
   of executables I wanted. And it works great in the relatively simple   
   scenarios I have (statically linked executables for the most part;   
   Windows ones are an exception since the Windows API isn't defined   
   as some kind of int#/fxn# in DOS or Linux and must be imported   
   from system libraries).   
      
   > Those I make seem to come without any relocation entries.   
      
   Might be that you aren't asking the linker to produce them for you.   
   That's what MinGW does by default. There are two tweaks here:   
   ----8<----   
   /*   
     How to compile for Windows with MinGW:   
       gcc hw-mingw-reloc.c -o hw-mingw-reloc.exe -Wl,--dynamicbase   
   */   
      
   #include    
      
   int __declspec(dllexport) main(void)   
   {   
     printf("Hello, World! @ %p\n", (void*)&main);   
     return 0;   
   }   
   ----8<----   
      
   1. dllexport on main forces creation of .reloc.   
   2. --dynamicbase sets a flag to enable ASLR for the executable.   
      
   I'm getting different addresses printed in different runs, as expected.   
      
   My smlrl produces .reloc by default and sets the ASLR flag too.   
      
   > Am I correct that data_directory[5] should contain the relocations?   
      
   Yes. But it's optional.   
      
   > I   
   > see that entry's address and length as zero - despite source which   
   > AFAICS needs to be relocated such as   
   >   
   > mov eax, label   
   >   
   > where label is elsewhere in the code.   
   >   
   > That's with a PE file created by   
   >   
   > ld -m i386pe ifile... -o ofile   
   >   
   > FWIW objdump -x shows most sections as empty:   
   >   
   > The Data Directory   
   > Entry 0 00000000 00000000 Export Directory [.edata (or where ever we   
   > found it)]   
   > Entry 1 00003000 00000014 Import Directory [parts of .idata]   
   > Entry 2 00000000 00000000 Resource Directory [.rsrc]   
   > Entry 3 00000000 00000000 Exception Directory [.pdata]   
   > Entry 4 00000000 00000000 Security Directory   
   > Entry 5 00000000 00000000 Base Relocation Directory [.reloc]   
   > Entry 6 00000000 00000000 Debug Directory   
   > Entry 7 00000000 00000000 Description Directory   
   > Entry 8 00000000 00000000 Special Directory   
   > Entry 9 00000000 00000000 Thread Storage Directory [.tls]   
   > Entry a 00000000 00000000 Load Configuration Directory   
   > Entry b 00000000 00000000 Bound Import Directory   
   > Entry c 00000000 00000000 Import Address Table Directory   
   > Entry d 00000000 00000000 Delay Import Directory   
   > Entry e 00000000 00000000 CLR Runtime Header   
   > Entry f 00000000 00000000 Reserved   
      
   Yep, it could be like that.   
      
   > > I still haven't found the minimum requirements for simple relocatable ELF   
   > > images. If I got it right, Linux kernel modules are actually objects, not   
   images.   
   > > Fun.   
   > Despite spending time learning about PE I fear I may have to switch to   
   > ELF if I cannot get PE relocation working.   
   >   
   > The thing is, maybe I'm misunderstanding something. If the code contains   
   > absolute references, as above, I cannot get how it's even sensible for   
   > ld to create a PE which contains no relocations. Such an executable   
   > could only ever be loaded to a certain location - which is not how I   
   > understand PE is supposed to work.   
   >   
   > What's more, even with the switch --dynamicbase which tells ld to allow   
   > for ASLR the PE file still has an empty .reloc section.   
      
   There's at least one way to force gcc to produce .reloc, one shown above.   
   --dynamicbase on its own is likely insufficient as it probably merely sets   
   the ASLR flag but it can't magically function without the relocation table.   
      
   > Or maybe ld is doing the right thing as it's my expectation which is   
   > wrong. Let me know if you can see what it is!   
   >   
   > What do you see in the data directory for your PE files?   
      
   Like I said, my version of MinGW doesn't produce .reloc or ASLR flag   
   by default, but I can talk it into doing that.   
   OTOH, my compiler comes with its own linker that does this by default.   
      
   HTH,   
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)