[Bug 36630] Wizards Event Reporter v4.1.x (.NET 2.0 SP1 app) fails on startup with .NET runtime reporting: ' Strong name validation failed. Exception from HRESULT: 0x8013141A'

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=36630

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Anastasius Focht <focht at 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-NET-Assembly-a-Strong-Name.htm

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/iclrstrongname-strongnamesignatureverification-method

(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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.