Do strong-named assemblies in .NET ensure the code wasn't tampered with?

Question

I'm trying to understand the point of strong-naming assemblies in .NET. While googling about it I noticed that everywhere it is said that it ensures that the code comes from me and wasn't tampered with. So I tested it. I created a simple DLL, signed it with a newly created PFX key and referenced it by my WPF application. And ok, everything works. When I compile the DLL with another PFX file I get an error, so it's ok.

BUT when I decompile the DLL by ildasm, modify it and recompile it by ilasm the WPF application still works without any error. So I tampered the strongly-named DLL and changed it manually with the old one and the application still works with the tampered DLL. The PublicKeyToken is the same. So what is the point of strong-naming? It doesn't ensure the code hasn't been tampered with since I strong-named it.

Sophia

Can you give the exact steps and code you have used? – Sacrificial

Did you do your "tampering" on another machine where you definitely don't have access to the original PFX? – Lophobranch

Maybe you switched off strong name check on your PC for performance reasons? learn.microsoft.com/en-us/dotnet/framework/app-domains/… – Nonchalant

Answer 1

It used to check for tampering, but the overhead of checking every strong-name-signed assembly at application startup was too high, so Microsoft disabled this behaviour by default a number of years ago (way back when ".NET Framework version 3.5 Service Pack 1" was released).

This is called the Strong-Name bypass feature.

You can disable the feature (i.e. make Windows check for tampering) for a particular application by adding the following to its ".config" file:

<configuration>  
  <runtime>  
    <bypassTrustedAppStrongNames enabled="false" />  
  </runtime>  
</configuration>  

You can enable strong-name checking for ALL applications by editing the registry (which is clearly not a feasible solution!).

For more details, see the following page:

https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

The advice nowadays is to use a full code-signing certificate for your executable and DLLs if you want to prevent code tampering.

Errol

So, if you sign assembly with code-signing cert then check disabling won't work? – Nonchalant

@AccessDenied : No, as code signing certificates are always validated by Windows itself (you can't disable it, AFAIK). Strong names was a more "localized" and simpler solution for .NET applications, but full code signing certificates can be used for any application and are designed to be very secure. – Arsenal

Ok, now it works. So still - strong-naming assemblies is pointless as far as the checking for tampering is concerned? Or maybe is it somehow possible to set this flag in the codebehind and obfuscate it, so any registry keys couldn't influece it? – Sophia

@Sophia It just means that you will have to pay for security. For example, buy commercial cert and enjoy: comodo.com/e-commerce/code-signing/code-signing-certificate.php – Nonchalant

My company has bought a full code-signing certificate but I wanted to perform some "additional" security. But as I understood and tested the validation of this bought full code-signing cert must be done by myself in the code? I referenced a signed dll that was signed with the bought cert, tampered with it, and it still worked. So Windows didn't notice the signing had been removed. – Sophia

@Sophia : "So still - strong-naming assemblies is pointless as far as the checking for tampering is concerned?" - Not necessarily. The app.config setting isn't overridden by the registry, so if you set it your assemblies will be verified. However as you say it's not 100% secure. It prevents external libraries from being tampered with and loaded by your application, but it doesn't prevent anyone from modifying your core application and tamper with it or disabling that check. It is simply a mean for you to verify libraries loaded by your app. – Arsenal

Fully code signed apps can also be tampered with, but then they will no longer match the certificate signing and thus will be displayed as risky or untrustworthy. Code signing doesn't stop anyone from modifying the binary, only from modifying it and displaying it as still coming from you. – Arsenal

@VisualVincent So then obfuscation comes in handy. I know it's not 100% bullet-proof but still... – Sophia

@Sophia : Exactly. You can never stop anyone from tampering with the .exe file itself, but you can always make it harder and, through code signing, prevent malicious users from editing it and distributing it as coming from you. – Arsenal