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