https://bugs.winehq.org/show_bug.cgi?id=36630
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID
--- Comment #3 from Anastasius Focht focht@gmx.net --- Hello folks,
after spending some more hours I came to conclusion this problem is actually an application bug (mistake in assembly signing process/obfuscator post-processing), exhibited with certain .NET Frameworks/service packs installed.
* .NET Framework 2.0 -> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) * .NET Framework 2.0 SP1 -> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) * .NET Framework 2.0 SP2 -> OK, application loads successfully * .NET Framework 3.0 -> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) * .NET Framework 3.5 -> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) * .NET Framework 3.5 SP1 -> OK, application loads successfully
The trace log/debugging doesn't show any suspicious behaviour when the public key/hash validation (advapi32/crypt32) is done, so the hash mismatch is indeed there.
https://www.codeguru.com/csharp/.net/net_general/article.php/c4643/Giving-a-...
http://www.grimes.nildram.co.uk/workshops/secWSThree.htm
The 2.0/3.0 CLR calls 'StrongNameSignatureVerification()' which fails, causing last error 0x8013141A being set, leading to C++/exception.
https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/hosting/iclr...
(NOTE: this is doc for .NET 4.0 but it should be still applicable for old CLRs)
--- snip --- HRESULT StrongNameSignatureVerification ( [in] LPCWSTR wszFilePath, [in] DWORD dwInFlags, [out] DWORD *pdwOutFlags ); --- snip ---
The main exe is obfuscated using SmartAssembly 6.x. This likely has contributed here. I suspect a tooling problem with post-processing/delay-sign of assemblies.
Finally I found a hint for the inconsistent behaviour with different .NET CLRs here:
https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/
--- quote --- Many managed applications start up slower than they really need to because of time spent verifying their strong name signatures. For most of these applications, the strong name verification isn't buying the application anything - especially fully trusted desktop applications that are using C# as a better C++.
Since these applications were paying the cost of verifying their assemblies at load time, but were not receiving any benefit from that cost, we've made a change in .NET 3.5 SP1 which lets these applications bypass strong name signature verification.
Specifically, for any assembly which is:
Fully signed (delay signed assemblies still require a skip verification entry) Fully trusted (without considering its strong name evidence) Loaded into a Fully trusted AppDomain Loaded from a location under the AppDomain's ApplicationBase
The CLR will no longer verify the assembly's strong name when it is loaded. ... Also, if a machine administrator wants to disable strong name bypass for all assemblies loaded on a particular computer, they can set the DWORD registry value named AllowStrongNameBypass to 0 under the HKLM\Software\Microsoft.NETFramework key: --- quote ---
Indeed, if I disable the bypass using registry, the strong name validation error appears with newer .NET Frameworks/CLR versions too.
--- snip --- [HKEY_LOCAL_MACHINE\Software\Microsoft.NETFramework] "AllowStrongNameBypass"=dword:00000000 --- snip ---
IMHO the vendor never tested the app with older .NET Frameworks hence the StrongName mismatch was not caught. It seems the released version was very short lived/silently replaced by some newer fixed version.
Pity it took some efforts to figure that out. Resolving 'INVALID' here.
Regards