Inconsistency/bug with GetProcAddress
kuba at mareimbrium.org
Mon Aug 8 09:15:40 CDT 2005
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:
More information about the wine-devel