Strong names in assemblies and exes

It was possible to turn the strong name checking off in an assembly in 1.0/1.1. 2.0 fixed this.

You could use the StrongNameIdentityPermission CAS attribute and let the runtime do the checking for you.

PolymorphicCode wrote:



blowdart wrote:It was possible to turn the strong name checking off in an assembly in 1.0/1.1. 2.0 fixed this. You could use the StrongNameIdentityPermission CAS attribute and let the runtime do the checking for you.

I am aware of this. However, I am asking with regards to the signing itself. Can someone change the assembly and sign it using their own key, and the runtime would run it because the signed hash and the calcualted hash would be equal?

If you change a 2.0 assembly it won't load, nor will you be able to resign it.

You could of course just use reflector, pull the code out and sign it on your own, after which point the StrongNameIdentity permission comes into play. However that's only useful when calling seperate assemblies, because, of course, when you decompile and edit you can take them out. Taken to the extreme you could then decompile the surrounding assemblies and remove the check, either the CAS or your own check.

You should be able to use the StrongName class to get at the evidence for the strong name, get the evidence for your assembly thus

Assembly assembly = Assembly.GetExecutingAssembly();
Evidence evidence = assembly.GetEvidence();

Then you would enumerate through the Evidence looking for the hash of the SNK. I believe that's all you get at runtime, but I'd have to go digging to check

PolymorphicCode wrote:



Hello,
   Can someone change the signed assembly's hash and public key after you have signed it? Can they put their own stuff after modifing your assembly or exe?

How to use reflection to get the hash of your running application to check if its been altered or not?

Thank You!

If you sign an assembly with a strong name your assembly is digitally signed. In CLR header is added "encrypted hash (metadata, il, resources, ...) with a private key" in manifest is added public key. If you try to modify IL or resources then hash will be different and when CLR will decrypt signature with public key and will check results with hash it will see that they differ and will not load modified assembly. Also this does'nt mean that you cannot change the entire signature (private key, hash; public key), you can.

Take a look here: http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/default.aspx

Its not about Microsoft its about what digital signatures cannot do. Well you can try encrypt entire assembly (I dont think CLR suports this) with public key, but imagine how much time this will take (RSA + 2-10M)

PolymorphicCode wrote:

Thank you guys for the help!. I cant help but note that MicroSoft did not develop a way to reliably verify that a particular person made a particular program , and that no one else is able to spoof or tamer the product or even be able to see what it does easily.

Particular person? That's what code signing keys are for, not strong names. Consider that strong names don't have any identity information beyond a key. Hardly useful to the end user.

Strong names do prevent tampering; at least in .net 2.0, if you change bytes in an assembly it will fail to load due to the strong name failing. Whilst you can resign with another key you can check using the StrongNamePermission or iterate over the evidence and check it yourself and exit if it's not what you expect. And of course combined with a code signing key that will also stop tampering.

As for seeing what it does, errr, right, that has nothing to do with anything. Although with CAS you can restrict what things can do, and assemblies can advertise what they need.