Validating the .NET Framework Assembly

Question

I just went through the German VB.NET forum and there was something interesting that gave me some kind of headache.

In fact, you can edit .NET Framework assemblies using ReflexIL or some other IL editor. The only thing you need to get around is signing the strong name of the assembly. After changing the IL assembly, you must run sn.exe -Vr [assemblyname] to skip validating the strong name. After that, you should clear the cached native images. Just go to the C:\Windows\assembly directory and delete all the images associated with your assembly. Then reboot. When you are logged in, run ngen install [assemblyname] . Now the original new images are created.

It works. I checked this procedure in my virtual environment (Windows XP x86). Now I am most concerned about the fact that you can easily bypass the .NET VerifyHash or VerifyData methods of the RSACryptoServiceProvider . This also works. One friend of mine and my tested one could check this problem ( see screenshots ). It was pretty easy.

For example, if I created a licensing system based on the .NET Framework cryptography classes, it would be possible to bypass the system-wide for each .NET application on the system using the framework. In addition, anyone can register and modify the input of functios, which I call by simply connecting to the methods.

Now my question is: Since this can be a huge problem, how can I do something about it? Of course, an attacker can simply modify my application, but it will not be as bad as doing it throughout the system. I was thinking of some framework checksum validation, but since there are many different updates for the .NET Framework, this seems impossible.

Any solutions or suggestions? Will Microsoft help solve this problem in any way?

Answer 1

If an attacker has administrator access to your computer (which is required for the attack you described), you are pretty much lost. All you could do could be circumvented by an attacker.

Because of this, I think it is completely pointless to try to defend against this type of attack. If you have to deal with unreliable, potentially at-risk computers, then you simply cannot trust them to do something sensitive, and you have to do it on your own server or something like that.