http://bugs.winehq.org/show_bug.cgi?id=8601
------- Additional Comments From focht@gmx.net 2007-05-06 06:52 ------- Hello,
yes, it's armadillo 4.x - one of the more advanced software protections to date :-)
Actually this is a meta bug. There exist quite a number of games and applications which suffer from this. All protected by 4.x version of armadillo.
I made some progress investigating this but it's a pain because you can't debug the target in wine with conventional means due to Copymem II and nanomites feature (parent process acts as debugger/on demand child process page encryption/decryption). Unfortunately I can't offer a general workaround for all games/apps yet...
Basically one of armadillos features is to redirect and emulate win32 API calls. Usually the import table gets destroyed on purpose and all IAT calls are rerouted to dynamic memory.
From there thunk calls and/or API code splicing takes place - to make it harder
to trace/dump/reconstruct IAT.
The problematic "feature" is the API code splicing. It requires hooking of system calls from certain dlls. The list is specific to each application. Due to the nature wine dynamic libraries are currently represented in memory (portable executable format), armadillo is unable to hook wine builtin libraries, resulting in different data returned from API (hook vs. original). For some apps, reverting to native libraries (which have correct PE structures, suited to hooking feature) solves this problem.
I worked around to some degree by modifying wine's PE loader to emulate original first thunks table (original unbound IAT) and the IAT data directory.
This is an issue that possibly needs some wine PE loader changes and/or the way wine PE header data is created (wine tools).
Regards