Ring3 Circus
June 16th, 2008, 05:30
It has taken a little while, but the application of asymmetric cryptography to binary signing is becoming popular. This is reflected in the intrinsic DSA signing mechanism offered by the .NET framework. If you aren’t familiar with strong name signing, the idea is fairly simple: The creator of a .NET assembly has their own RSA key pair, which they use to encrypt a combination of hashes of the file. The resulting strong-name signature is included in the binary along with the public key and the whole lot is distributed as normal. Now, whenever a user tries to load this assembly, the public key and signature are used to verify the integrity of the file, thus thwarting the attempts of any bad guys to patch the assembly. And of course, because the private key is never published, it is virtually impossible for the file to be re-signed with the same key after its release.
The method of digital signing is remarkably effective at preventing patching and without the use of a hypercomputer, the chances of anyone cracking the key is as good as zero. Also of note is that the code responsible for verifying the signature is part of the system’s .NET assembly loader, and therein lies both a strength and the weakness of the technique. While this makes it easy for developers to sign their assemblies (very easy indeed using Visual Studio), it also unifies the implementation allowing for automated removal of such signatures. The weak point in the protection is obviously the DSA signature-checking algorithm, but it lies in system code and so for many reverse-engineers, bypassing it is undesirable or impossible. So we target the next best thing - the metadata in the assembly itself. If the assembly looks like it isn’t signed then that is exactly how it will be treated.
The exact structure of the relevant metadata is described in the .NET specification, and the steps necessary to remove the signing have been concisely detailed here ("http://www.codeproject.com/KB/security/StrongNameRemove20.aspx"). Even more generously, Andrea provides us in that article us with a tool to remove the signatures from a single file. Similar programs can be found elsewhere on the web but nowhere did I see a tool that’s capable of handling complex projects with nested binary dependencies. The problem here is that the public key is stored both in a binary itself and each assembly that references it, so if you’re patching a DLL deep in a dependency structure, it is nontrivial to isolate and execute all the necessary patches. That’s why I created AdmiralDebilitate.
http://www.ring3circus.com/source/admiraldebilitate/admiraldebilitate_tn.png ("http://www.ring3circus.com/source/admiraldebilitate/admiraldebilitate.png")
If you load up any number of PE files, AdmiralDebilitate will enumerate all .NET dependencies and provide you with a tree, much like the Dependency Walker. From here, you can ‘mark’ any and all assemblies that you intent to patch, and all the work of identifying dependants and patching out the headers will be done for you. I provide no further instructions but it should be self-explanatory. As usual, this is a one-man project and the code is correspondingly immature so please report any bugs.
Get the source and binary here ("http://www.ring3circus.com/downloads/admiraldebilitate/").
http://www.ring3circus.com/rce/strong-name-signing-admiraldebilitate-v01/
The method of digital signing is remarkably effective at preventing patching and without the use of a hypercomputer, the chances of anyone cracking the key is as good as zero. Also of note is that the code responsible for verifying the signature is part of the system’s .NET assembly loader, and therein lies both a strength and the weakness of the technique. While this makes it easy for developers to sign their assemblies (very easy indeed using Visual Studio), it also unifies the implementation allowing for automated removal of such signatures. The weak point in the protection is obviously the DSA signature-checking algorithm, but it lies in system code and so for many reverse-engineers, bypassing it is undesirable or impossible. So we target the next best thing - the metadata in the assembly itself. If the assembly looks like it isn’t signed then that is exactly how it will be treated.
The exact structure of the relevant metadata is described in the .NET specification, and the steps necessary to remove the signing have been concisely detailed here ("http://www.codeproject.com/KB/security/StrongNameRemove20.aspx"). Even more generously, Andrea provides us in that article us with a tool to remove the signatures from a single file. Similar programs can be found elsewhere on the web but nowhere did I see a tool that’s capable of handling complex projects with nested binary dependencies. The problem here is that the public key is stored both in a binary itself and each assembly that references it, so if you’re patching a DLL deep in a dependency structure, it is nontrivial to isolate and execute all the necessary patches. That’s why I created AdmiralDebilitate.
http://www.ring3circus.com/source/admiraldebilitate/admiraldebilitate_tn.png ("http://www.ring3circus.com/source/admiraldebilitate/admiraldebilitate.png")
If you load up any number of PE files, AdmiralDebilitate will enumerate all .NET dependencies and provide you with a tree, much like the Dependency Walker. From here, you can ‘mark’ any and all assemblies that you intent to patch, and all the work of identifying dependants and patching out the headers will be done for you. I provide no further instructions but it should be self-explanatory. As usual, this is a one-man project and the code is correspondingly immature so please report any bugs.
Get the source and binary here ("http://www.ring3circus.com/downloads/admiraldebilitate/").
http://www.ring3circus.com/rce/strong-name-signing-admiraldebilitate-v01/