Inconsistency/bug with GetProcAddress

[Vitaliy Margolen]

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

Well they actually took care of that. They don't really use GetProcAddress. At
least safedisc doesn't. They pretty much implemented their own GetProcAddress
that does work on wine. I don't know details of it but it suffers form the same
problem :-(

Something tells me that their GetProcAddress will not work with such a jump
table.

Vitaliy