[Bug 17184] Achieve Planner 1.9.0 requires explicit native override of mscoree.dll

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17184


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #2 from Anastasius Focht <focht at gmx.net>  2010-07-29 17:37:02 ---
Hello,

--- snip ---
The app calls the function StrongNameSignatureVerificationEx from a dll called
mscoreesn.dll. This dll is installed somwhere in the MicroSoft.Net direcectory
in c:\windows. I thinkk this dlls just forwards it directly to mscoree.dll. So
in spite of mscoree's preference to use the native version, it calls the
function from buitin mscoree, as it's directly forwarded. This last is just a
guess, maybe someone with more knowledge about wine's load internals has a
clue, but if my guess would be correct, this might just be WONTFIX?
--- snip ---

The app dlls, for example "efxstd.DLL" (managed code, strong named assembly)
call StrongNameSignatureVerificationEx() use P/Invoke to check if they are
tampered (patched).
This is probably an attempt to stop novice hackers from re-signing the assembly
or completely removing the existing strong name signature.

Although obfuscated I deduced it seems to implement some
let-the-bad-guy-wait-until-he-dies-of-boredom scheme if
StrongNameSignatureVerificationEx() returns false.
Later the assemblies' public key token is verified with an internal (encrypted)
representation of the public key token.

The native vs. builtin mscoree load order problem most likely results from
different P/Invoke resolver implementation between .NET 1.1 CLR and .NET 2.0
CLR.