Assemblies Should have valid Strong Names

Question

I am trying to convince the developers in the company that we really should obey this rule. What I thought I would do would be create 2 projects one that calls a dll with a strong name and another that does not call a dll with a strong name. I was then intending to demonstrate that if the dll's got altered the assembly calling the strong named dll would bring up an error message. 
I then came unstuck because I discovered that it is possible to get in to the immediate language and remove the public key reference in the assembly that is expecting a strong named dll and remove the public key from the dll as well as make other changes like add instead of subtract and reassembling the intermediate language. Running the 'hacked' assemblies poses no obvious problems with the exception that the functionality has changed. I cannot see customers running FxCop or other utilities regulary to check that the assemblies have not been tampered with.
I still believe that strong names should be in place but I no longer have the collateral to confince the developers.
If anyone has any suggestions as to how I can convince them including suggestions for a demonstration I would be grateful.

Answer 1

Have you strong-named the assembly that is calling the strong-named dll?
I allways believed that modifying should be impossible if that is the case.

Answer 2

Hacking a binary in the way you describe is not a kind of exploit that a feature like strong-name signing is intended to protect against. If a hacker can disassemble, modify and replace a binary on your machine, they already have the rights to do anything they want. For a more realistic test, try running a managed program with restricted permissions (that can't write to disk or execute native code, for example) and try to modify or replace usage of a strong-named assembly.

Also, as a side note, it sounds as though you've described modifying the IL from an unsigned assembly that refers to a strong-named assembly. The CLR security system only performs an integrity check on loading strong-named assemblies. If you'd like to test this, create a strong-named signed binary, try to disassemble, modify, reassemble and load it (by reference) from another binary. 

A more primary purpose of strong-named binaries is to specify a unique identity for an assembly and to support a strong versioning story. Strong-named binaries can live in the GAC, so that there is guaranteed to only be a single copy of a binary on a machine. Finally, if you're developing reusable components, you must be strong-named, otherwise, a strong-named binary won't be able to reference your component.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconStrong-NamedAssemblies.asp

Michael