Inconsistency/bug with GetProcAddress

[Jacek Caban]

Kuba Ober wrote:

>On Sunday 07 August 2005 10:13, Mike McCormack wrote:
>  
>
>>>http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767
>>>/
>>>
>>>says:
>>> > 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: 
>http://hrabia.ibib.waw.pl/~winnie/qtbeheader.html
>
>Kuba
>  
>
Hello.

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:
jmp <func1>
jmp <func2>
...
where func1 is what dlsym returns and GetProcAddress could return
address to this jump instruction. This table could be mmaped in fixed
place.

Jacek