Inconsistency/bug with GetProcAddress

[Kuba Ober]

> >>>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).

> >>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

> 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.

That's clever too! I didn't think of it. Now the question is if the copy 
protection guys didn't think of doing checksumming of the actual functions in 
question, or if they won't eventually. That'd firmly lock their products to 
Windows, unless their checksumming was insecure. Then code could be 
fabricated to match the signature while doing the jump that one needs. One 
hopes they don't read wine-devel ;)

Kuba