Re: unicows update and PE memory format

[Rolf Kalbermatter]

Message: 4
Subject: Re: PE stack trick not working on lowmem machines
From: Mike Hearn 
To: Alexandre Julliard 
Cc: Marcus Meissner , [e-mail]
Date: Mon, 24 Nov 2003 21:00:33 +0000

On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote:
> > Btw, why don't we use -Wa,--noexecstack ?
>
> It doesn't help with prelink AFAICT.

Is it really too late to get some kind of hook into prelink to stop it
interfering with Wine? It seems daft that we need such a big hack when
surely a flag in the elf headers would work just as well with
co-operation from the rtld.

--__--__--
> Shachar Shemesh  writes:
> Now here's the puzzle - GetProcAddress is never called. Neither are 
> these functions imported from the DLL in the PE header. In fact, 
> unicows.dll does not even appear in the PE header (which makes sense - 
> on NT you don't even want to install it). This means that unicows.lib 
> manages to call GetProcAddress, without actually calling GetProcAddress.
>
> Some tracing leads me to suspect (I have not done enough research to 
> determine yet) that it accesses the PE header of kernel32 directly. It 
> appears that unicows.dll enountered the exact same problem we have vis a 
> vis GetProcAddress, and have happily hacked their way around it using 
> direct memory access. What I see them do is call "GetModuleHandle" on 
> "kernel32.dll", and then use the resulting handle as a struct/array 
> pointer, and access offsets into it.

This is not exactly very nice but it is also not to surprising. The PE
header is actually documented on MSDN including the import and export
tables. GetModuleHandle actually also just returns the HMODULE which
at least for Win32 is the same as the HINSTANCE returned by LoadLibrary.
The difference is if I'm not mistaken, that GetModuleHandle will usually
not try to load the module if it isn't already loaded, but for kernel32
you can safely assume that a process has it already loaded implicitedly
or even explicitedly.
An HMODULE on Win32 is nothing else than the base address of a loaded
module image, and with some offset calculations using Macros from winnt.h
you can get at anything in that image including the export table and from
there you can then search GetProcAddress. One possible problem is that the
unicows GetProcAddress implementation might not search the function in the
export table by name but rather by ordinal and our ordinal or ordinal base
is different from what Unicows expects.

Rolf Kalbermatter