Inconsistency/bug with GetProcAddress
jack at itma.pwr.wroc.pl
Mon Aug 8 09:59:13 CDT 2005
Kuba Ober wrote:
>On Sunday 07 August 2005 10:13, Mike McCormack wrote:
>>> > When creating a process, the loader on Win 2000, Win XP and Win 2003
>>> > checks if kernel32.dll and user32.dll (their names are hardcoded into
>>> > the loader) are mapped at their preferred bases; if not, a hard error
>>> > is raised. In WinNT 4 ole32.dll was also checked. In WinNT 3.51 and
>>> > lower such checks were not present, so kernel32.dll and user32.dll
>>> > could be anywhere. Anyway, the only module that is always at its base
>>> > is ntdll.dll. The loader doesn't check it, but if ntdll.dll is not at
>>> > its base, the process just can't be created.
>>>It's a common technique to rely on the fact that exports from kernel32
>>>reside at the same address to use CreateRemoteThread calling LoadLibrary
>>>for remote code injection (this is not what Vitaliy's App is doing here
>>>but the assertions are the same).
>>OK, fair enough.
>>It's hard to implement that in Wine, because dlls are loaded using
>>dlopen() and there's no way to specify which address to load the dll at.
>I would say that the only relatively sane way to do it is to re-implement
>dlopen to support such functionality. The ELF tables that dlopen needs are
>documented. It doesn't seem like a trivial task to reimplement it, but it
>should be doable. Last time I checked, ELF tables are at least manageable to
>deal with given a rainy afternoon:
There is also other way to do it. Wine could create the jump table
(I don't know if it's good name in English) that would look like:
where func1 is what dlsym returns and GetProcAddress could return
address to this jump instruction. This table could be mmaped in fixed
More information about the wine-devel