Results 1 to 7 of 7

Thread: Strong-Name Signing, AdmiralDebilitate v0.1

  1. #1

    Strong-Name Signing, AdmiralDebilitate v0.1

    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. 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.



    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/rce/strong-name-signing-admiraldebilitate-v01/

  2. #2
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  3. #3
    nice tool thx for sharing..

  4. #4
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    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.
    This is not the point of Strong Name Signing. Removing it from the assembly is very easy, the purpose of this protection is to work in "trusted" environments. Let's say you sign an assembly with you signature. I grant you, the producer, special privileges. When I run your assembly the privileges are granted by verifying the integrity of your assembly through the strong name signature. You can remove the strong name signature, no problem, but your assembly will no longer have the privileges it requires. Strong Name Signatures has been wrongly identified as an anti-patching method. This is mostly due to the lack of knowledge about the .NET framework. Anyway, your application can be very handy, I haven't tested it yet, but I'm sure it works, so good work. However, I would correct the statement above.

  5. #5
    Hi Daniel.

    It looks like I did indeed misunderstand the point behind strong-name signing, but I'm afraid I don't entirely like your definition either. The MSDN article (http://msdn.microsoft.com/en-us/library/ms235305(VS.80).aspx) states that strong naming is used to provide tighter version-control for distributed projects. By demanding that all assemblies are uniquely identifiable by their strong-name and signed by their proprietors, consumers stand a better chance of avoiding 'DLL hell'. The concepts of trust and privilege control are linked close-by, but they pertain more to ClickOnce Security than strong naming itself.

    Point taken nonetheless, and I'll be sure to make this clear in the post. But either way, all intentions aside, strong-name signing is undeniably being used by developers as a quick-and-easy means of patch defence. So it's up to us to fight back
    www.ring3circus.com
    Diary of a programmer, journal of a hacker.

  6. #6
    By the way, my apologies to those of you who already downloaded and archived the first release of this tool, but I recently discovered a bug whereby some assemblies were falsely listed as having no dependencies. This obviously put a spanner in the works, but the fix was simple enough. My website and the CRCETL have been updated accordingly.

  7. #7
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    The MSDN article (http://msdn.microsoft.com/en-us/library/ms235305(VS.80).aspx) states that strong naming is used to provide tighter version-control for distributed projects. By demanding that all assemblies are uniquely identifiable by their strong-name and signed by their proprietors, consumers stand a better chance of avoiding 'DLL hell'.
    Yes, absolutely true, but I was talking from a cracking point of view. Overcoming Strong Name Signing would mean gaining the trust (thus the privileges). Dll hell is absolutely one reason for strong signing, but there certainly are other ways to uniquely identify a file. Using an asymmetric encryption method and not a simple hash (or even better a unique identifier like the GUID stream) surely tells us that this is not the only reason. I'm sorry if I haven't specified this yesterday, but as you can see it was late.

    But either way, all intentions aside, strong-name signing is undeniably being used by developers as a quick-and-easy means of patch defence. So it's up to us to fight back
    Yes, I didn't say that the lack of knowledge about the .NET framework is only present in the RCE community. It's much more present in the dev community. Many developers honestly think that it's a antipatching method. I always remove strong name signing if I have to with the CFF Explorer, but an automatic tool like yours which works even for dependencies is useful.
    Last edited by Daniel Pistelli; June 17th, 2008 at 17:31.

Similar Threads

  1. Strong-Name with AssemblyRef problem ...
    By kappasm in forum Advanced Reversing and Programming
    Replies: 8
    Last Post: December 4th, 2010, 17:47
  2. JAR Signing Issue
    By Velos in forum The Newbie Forum
    Replies: 10
    Last Post: June 7th, 2010, 12:21
  3. AdmiralDebilitate
    By Kurapica in forum Tools of Our Trade (TOT) Messageboard
    Replies: 4
    Last Post: December 20th, 2009, 08:25
  4. Strong names again...
    By crassy in forum Advanced Reversing and Programming
    Replies: 5
    Last Post: December 19th, 2008, 09:37
  5. Update on Driver Signing Bypass
    By Alex Ionescu Blog in forum Blogs Forum
    Replies: 0
    Last Post: December 10th, 2007, 23:52

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •