Inconsistency/bug with GetProcAddress

[Kuba Ober]

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