Click here to Skip to main content
Click here to Skip to main content

Building Security Awareness in .NET Assemblies : Part 3 - Learn to break Strong Name .NET Assemblies

By , 31 Oct 2004
 

Disclaimer

NeCoders shall not be held responsible for any cases of software/files being hacked due to the information provided in this article.

General Overview

Welcome back to part 3 of the Building Security Awareness in .Net Assemblies series. In this article, I will share with you the possibility of breaking Strong Named .Net Assemblies. Make sure you have already read through part 1 and 2 before continuing on.

Questions pertaining to Strong Name

I do believe many others have the same doubts as I do on whether Strong Name keys could really protect the assembly from being tampered. I would like to share my doubts with you in this article.

Questions:

  1. Question : Is Strong Name key secure?
    • Answer : Yes, Strong Name key uses RSA 1024 bit encryption.
  2. Question : Is Strong Name key breakable?
    • Answer : If you have enough computing power, time and knowledge on how to break RSA, the answer is yes.
  3. Question : Can Strong Name key be removed from .NET assemblies?
    • Answer : Yes, it can be removed very easily if you know how.

The Demonstration Test machine specifications :

  • Windows XP Professional Edition SP 1 1

  • Intel Pentium 4 2.6GHz

  • 256MB DDR-RAM

  • Visual Studio .Net 2003 Professional Edition

  • Microsoft .Net Framework 1.1
  1. Download the executable files that come with this article.
  2. Open your Visual Studio .Net 2003 command prompt.
  3. Make sure you are inside the CrackingIL/bin/debug directory.
  4. Type “ildasm CrackingIL.exe /out=CrackingIL.il”.

  1. You must be wondering, why we are repeating what we had done in part 1 and part 2 of the series. If you notice, the way to break Strong Name keys is by manipulating the Intermediate Language. But the problem is in part 2, we did modify the Intermediate Language and at the end when we tried to convert it back to an assembly, we will receive an error. I will explain in detail on which part of the Intermediate Language that you should modified to remove the Strong Name key.
  2. Open up the CrackingIL.il with a text editor. I use notepad.

  1. Take a look at the red boxes. From what I understand, each assemblies like System.Windows.Forms, System and mscorlib contains their own public key token and version number.
  2. Now, does our assembly contain a public key? The answer is yes. Before showing it to you, I will first show you 2 screenshots; one without Strong Name key and one with Strong Name key attached.

Without Strong Name :

With Strong Name :

  1. You will notice that the difference on both sides is that the Strong Name key assembly contains a public key. In order to tamper a Strong Named .Net Assembly, just remove that highlighted section. It will look like this.

  1. Now do some modifications to the existing Intermediate Language. You have to remove the registry checking so it will not prompt you for serial number or license. Look for this code.

  1. Then remove the lines of code from IL_0000 to IL_0075. You should have an output like this.

  1. Now just edit some text to prove that you have hijacked that Strong Named key .Net Assembly. Find the code with the phrase “Welcome to NeCoders” and replace it to “You are being hijacked, Strong Names are useless here”.

Change above to:

  1. Open your Visual Studio .Net 2003 command prompt, and type “ilasm CrackingIL.il”.

  1. Try to run CrackingIL.exe. You will see this.

  1. Congratulations! You had managed to manipulate .Net assemblies with Strong Name key attached to it.

Conclusion

Again, I hope you find this series of the article to be interesting. There will be more articles under this series, in terms of breaking and securing the .Net assemblies. Do check out article 4 when it is available as it will explaining the many theories in .NET security. This in return should provide you with a better understanding in this topic.

References

None

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Chua Wen Ching
Software Developer
Malaysia Malaysia
Member
I am Chua Wen Ching and it is great to be part of CodeProject network Smile | :)

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralRe: Missunderstanding to strong namesmemberchuawenching11 Nov '04 - 15:05 
Hi Jan,
 
Thanks for the explanations. I will look into your examples.
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralRe: Missunderstanding to strong namesmemberJanSeda11 Nov '04 - 15:42 
Hi!
 
You're welcome to contact me. I'm specialized on security topics in Microsoft and we can discuss it (some topics are covered in my ebooks or articles). But thank you for your articles, maybe you could be contacted by some our MS guys to be an MVP Wink | ;)
 
Regards and wish you many success.
 
Jan
www.skilldrive.com
GeneralRe: Missunderstanding to strong namesmemberchuawenching11 Nov '04 - 15:53 
Thanks Jan. I hope to be a MVP one day for sure.
 
But anyway I wrote these articles for my interest in this field. Smile | :)
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralRe: Strong namesmemberKurt H11 Nov '04 - 9:58 
This is incorrect. Strong names are not used to prove publisher identity, thats what Publisher Certificates and signcode is used for. SN is to provide a globally unique name so that it may be stored in the GAC without conflicting with other assemblies that may have the same friendly names. It is not used to protect an assembly from tampering or to prove publisher identity.

GeneralRe: Strong namesmemberHugo Hallman11 Nov '04 - 10:10 
Well, it's right that strong names are indeed required to put assemblies in the gac, and the term "strong name" certainly indicates it too. But a strong name does indeed prove the author, given of course that you can somehow verify the public key with which the "publc key token" or fingerprint if you wish. It does prove that the assembly is signed with a certain private key. Thanks for correcting me.

GeneralRe: Strong namesmemberKurt H11 Nov '04 - 10:52 
In some sence you can ensure that only the person with the private key can generate an assembly with the same identity. If the calling assembly validates the strong name identity of the assembly this hack will fail. For example the .NET runtime itself will check the strong name evaluate security policies, if this assembly was explicitly granted full trust (assuming it is not granted by default, which by default all assemblies on run from local machine are given full trust) then the hacked assembly will no longer have full trust. This hack essentially only works when strong name identity is not required.
 
Although SN proves only a person with the private key can modify the assembly without changing its identity (as identity was changed here) it still is not proof of publisher identity. For example if someone aquires the private key we can no longer guarentee a specific person or organization has created it. Authenticode however is different by utilizing a trust network and timestamping services if a private key is ever stolen it is revoked. The timestamp also included in the signed data can gaurentee the assembly was signed before or after the key was stolen. This is not possible with SN which has no trust network. SN was designed for assembly identity. If publisher identity is important use Authenticode, as SN cannot make the same gaurentees.
 
For more information on the differences in intent see Authenticode and Strong Names see:
http://msdn.microsoft.com/library/en-us/secmod/html/secmod80.asp
GeneralRe: Strong namesmemberchuawenching11 Nov '04 - 15:10 
Hi Kurt,

Cool. Thanks a lot. I really learn a lot from the reviews here. Lasly, I will make sure i won't repeat these mistakes in article 4 onwards.
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralXenoCodememberstaceyw9 Nov '04 - 8:40 
Just curious if you could crack the XenoCode obfuscator with control flow obfuscation and the IL breaker turned on. If so, that would be good to know.
Get a XenoCode trial at http://www.xenocode.com to test your assembly and try to crack it. I am not associated with them, just curious as I have their product. Cheers!
 
--
William Stacey, MVP
http://mvp.support.microsoft.com
GeneralRe: XenoCodememberchuawenching9 Nov '04 - 12:20 
Hi William,
 
I will look into it. I am working on an article of the possibilities of obfuscation. Well much to r&d before writing that article. Give me some time.
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralRe: XenoCodememberShaun Wilde25 Nov '04 - 20:50 
Please be careful.
 
I am very interested in your articles and I would hate to see the full weight of the law descend upon you for cracking commercial software.
 
Keep up the good (or some would say bad) work. but I feel with open discussion of these issues can only force Microsoft to make things better for the author.
 
In the end if the commercial market doesn't take to .NET then it's doomed.
 
I await the next article. Type faster...
 

 
www.many-monkeys.com
GeneralRe: XenoCodememberchuawenching25 Nov '04 - 21:25 
Hi there,
 
Thanks for your comments. There will be an article coming out soon to clarify my mistakes on my article 1 - 3.
 
Well, I think i have some wrong concepts over here on Strong Name.
 
But i do believe that all these feedbacks will make me write better articles.
 
Again, i am trying to build awareness, that's all.
 
Furthermore, i don't crack commercial software. As you can see in my articles, the samples were written by myself. I didn't show any possibilities to crack an existing software out there.
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralRe: XenoCodememberFrank Hileman9 Jul '05 - 5:55 
According to the cracker forums I sometimes monitor, this obfuscator has not provided sucessful protection. I believe any obfuscator can be defeated. The list of .net development tools protected by professional products, that have been cracked, is huge!
 
Forget about real protection and focus on basic protection. The best protection is to withold key bits of your binary from all except true purchasers. That is, don't put out a full version that is "protected", but make two builds: one for demos, missing code, and one for purchasers, or serious evalators that you can verify. Remember the crackers are just doing it for fun most of the time. They are not interested in using your product seriously.
GeneralPotential problem with methodmemberEtienne Fortin9 Nov '04 - 5:03 
I just tought 3 seconds about this, but this example is showing an independant assembly. If an assembly reference a Strong Named assembly and you tamper that referenced assembly, then that tampered assembly can't be referenced. Am I correct?

 
Etienne Fortin
GeneralRe: Potential problem with methodsussAnonymous9 Nov '04 - 5:24 
Hi Etienne Fortin,
 
Yeah, in this article I am only refering to a single independent assembly. But for your 2nd question, I will reserve it for my coming articles. I am really working hard on something cool on the next releases of the articles. Give me some time Poke tongue | ;-P
 
Hope you like it. Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralNice onememberrawwool6 Nov '04 - 21:06 
Going one step further than that, the hacker could even sign the tampered assembly by his own private key - so potentially fooling the CLR, if the CLR grants trust to an assembly simply if it is signed.
I now more strongly feel that the onus is now on the system administator of the machine(s) to cleverly set trust and evidence based code access security policies for the CLR so that the compromised assemblies fail to execute. This can probably only be achieved if the policy is based on the publisher's identity - be it his public key or his digital certificate.
http://dotnetyogi.blogspot.com/[^]
GeneralRe: Nice onesussAnonymous6 Nov '04 - 21:54 
Point taken.
 
I am looking into it. Cheers Wink | ;)
 
Regards,
Chua Wen Ching
GeneralRe: Nice onememberHugo Hallman9 Nov '04 - 11:32 
No.
The public key token will be different if you sign the assembly with a different key. So the loader won't be fooled at all.
 
If an exe loads a library which checks for a registration, and you change the public key token of the library, then the clr won't load the "hacked" dll at all. You'd have to modify all the assemblies that references a hacked one too.
GeneralRe: Nice onememberchuawenching9 Nov '04 - 12:18 
Hi Hugo Hallman,
 
Thanks for the clarification. Point taken.
 
Cheers.
 
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
GeneralRe: Nice onememberrawwool10 Nov '04 - 5:58 
Totally agree. The hacker would have to 'unsign' and sign all the related assemblies. The CAS policies still wouldn't allow running that code if it has been set up to allow only trusted code to run. I have a feeling, in majority of the .Net running environments (especially the small to medium size sites) the code access security policies have not been set up at all. I think, as much as or more than the developers, the idea of .Net security has yet to sink in with the system administrators.
 
Thanks
GeneralDisclaimermemberHoria Tudosie4 Nov '04 - 3:29 
"NeCoders shall not be held responsible for any cases of software/files being hacked due to the information provided in this article."
 
Why not? Suspicious | :suss:
 
Horia Tudosie
GeneralRe: DisclaimermemberMisty_Blue11 Nov '04 - 11:00 
Just Like That loooooolz
GeneralGreat Jobsusssandurea3 Nov '04 - 23:51 
Hi Chua Wen Ching,
 
It's great article to read, and you have given a good example of strong name assemblies , but what i know that strong name are used for side by side execution of assemblies which are applicable on Public Assemblies , but any way these were very good articles and hope to get Part IV soon from you
 
Cheers
Nitin SandureaSmile | :)

GeneralGood articlememberRakker713 Nov '04 - 7:34 
Just wanted to say thanks for the articles so far. I agree they might be a little verboose, but I found it easy to read and understand. thanks again & keep going!
GeneralDisturbingmemberRabidKangaroo2 Nov '04 - 9:53 
Great series of articles. One thing though...
 
Your disclaimer is ludicrous.
 
NeCoders shall not be held responsible for any cases of software/files being hacked due to the information provided in this article.
 
That's like me writing an article "50 Ways To Infiltrate Buildings and Plant Explosives" and including a disclaimer: "RabidKangaroo shall not be held responsible for any buildings that are destroyed due to the information provided in this article."
 

 
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
GeneralRe: DisturbingmemberDaniel Turini6 Nov '04 - 22:09 
Sorry, but the author is right. Security through obscurity does not work, and that's why even MS publishes deatiled information about vulnerabilities - knowing about a vulnerability in detail is the only true way of knowing if you're in danger and how you can protect yourself.
 
RabidKangaroo wrote:
That's like me writing an article "50 Ways To Infiltrate Buildings and Plant Explosives" and including a disclaimer: "RabidKangaroo shall not be held responsible for any buildings that are destroyed due to the information provided in this article."
RabidKangaroo never entered a building, right? A world where only hackers know how to break code is a world where no one is safe. Good programmers need to know how to break code. Trying hard to break your own code is the first line of defense against hackers.
 
Yes, even I am blogging now!

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web03 | 2.6.130523.1 | Last Updated 1 Nov 2004
Article Copyright 2004 by Chua Wen Ching
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid