|
|
Comments and Discussions
|
|
 |

|
Strong names is for assigning an assembly identity to prevent name collision and provide CAS policy. Authenticode signatures would protect the file integrity and provide publisher identity and certificate revocation. Removing a strong name signature is not proving anything except that it can be done. In the ECMA spec there is details on a cleaner way to do this without even decompiling. If the assembly is part of a bigger product and that product is cryptographically tied to an Authenticode signature, all bets are off.
|
|
|
|

|
Author didn't succeed in altering an assembly without removing/changing the signage
|
|
|
|

|
these 3 part articles are superb.
thanks alot.
|
|
|
|

|
Hello Chua,
thanks for this work, i really enjoyed reading your articles
but i wonder if you posted any other parts concerning this topic ?
Best regards
|
|
|
|

|
It's not good theory because this theory only useful on single or not more than 2 or 3 assemblies. When we face more than 3 assemblies then we have a lots to do. We must change the entire assemblies collection if we want to assign new strong name.
I figure out how to change some public key, and public key token using hex tools. Its easier to find and replace the public key (its only a string and hex value). But the problem is if the assembly have been sign then in that assembly also include hash for that assembly (like embedded CRC). So if we modify the assembly then when the assembly executed it will fail because invalid hash.
Is there any ways to avoid this up. I want to make sure that .NET assembly really secure, because first I think if I write .NET assembly it will be secured.
|
|
|
|

|
Hi Chua, just want to know your thoughts on the best way to do when you have a strong named assembly that need to call a non strong named assembly.
Thanks!
|
|
|
|

|
Will it be out soon?
Thanks a lot.
======================
horngsh
======================
|
|
|
|

|
Hi, I have try you guide line for assinging strong name to dll that strong named dll used to assign full trust. I will perform following step for that, ildasm myFile.dll /output:myFile.il /* for deassembling the dll */ /* after deassembling I will add public key code which is copied from a stong named dll. */ ilasm /dll /output:myFile.dll /* used for reassembled the dll */ sn - vf myFile.dll /* used for veryfing strong name of dll */ /* when I used reassembled dll for veryfing the strong name it was display : myFile.dll is a delay-signed or test-signed assembly */ caspol -af myFile.dll /* used for assign fulltrust to dll */ /* when I used above command it was diplay error message assebly couldn't load. */ so please guide me how to assign the full trust using strong name to dll with reagrds,
Nimit Patel -- modified at 9:14 Monday 22nd May, 2006
|
|
|
|

|
When will part 4 be posted here?
|
|
|
|
|

|
Your articles are very enjoyable and I look forward to reading more. One question comes into my mind is, since you can remove the public key of the assembly, do you think you can replace that public key with another public key?
Thanks and great work.
|
|
|
|

|
Hmmm,
at first my reaction was - ok. SN is not to be meant for..., but then what if someone changed both, the dll, AND the exe which used it and removed the SN references from both. Then the exe would gladly use the unsigned assebmly/dll. Which still might mean, that (provided the admins do their work) at system-level/by policy, then unsigned assemblies will now not have as many OS-rights as they did have.
regards, Tilli
|
|
|
|

|
Excellent series of articles - short and to the point. I like it
This space for rent!
|
|
|
|

|
I was, prior to this, pretty confident that we could use a non-obscure licensing scheme safe in the knowledge that our interdependant assemblies could not be compromised easily, however this seems to be completely untrue in light of what you published here.
There is obfuscation of course, but it must be turned off for the bits that use reflection and our business apps rely heavily on reflection in the business object framework we are using so it's looking increasingly like were going to have trouble with the licensing however we go about it.
Hopefully you have some tricks up your sleeve?
Thanks again for the informative article, there is too little on this subject out there.
|
|
|
|

|
Strong names are not intended to prevent modification of the code at all. They are intended as a means of verifying that the assembly does indeed come from said source. If you want to modify an assembly and have programs that reference it continue to run, that's easy too, just modify the programs in the same manner as well.
What strong names DO prevent is outright spoofing. For instance, if a machine's code access security is set to allow code from company X (say that's your employer's company and this is the internal network) to do anything it wants while all other code is sandboxed, it makes it impossible (unless, as you say, you happen to have obscene amounts of processing power and can break the key) for a hacker (or virus, etc) to change company X's code to do something harmful. As soon as they change the code, they break the strong name and CAS refuses to give the assembly full access to the system.
The only way to really hack a strongly named assembly is to have the private key available (or, again, lots of computer power to break the encryption) so that the altered version can be resigned and have the same public key.
|
|
|
|

|
Strong names are used to prove who wrote an assembly, and not to protect it. If you modify an assembly, you can't make it look like it was someone else who wrote it. Therefore, when you load any strong name asembly, you can be shure who wrote it. Even after deployment.
|
|
|
|

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

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

|
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/[^]
|
|
|
|

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

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

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

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

|
I don't believe there is enough content to provide a 3 part article. You could probably get good reviews (You already are but it could get better) if you condensed the 3 parts into a single part about Strong Names. Also you need to understand, like others have said, that Strong Naming isn't supposed to protected code from highjacking but to provide the ability to strongly name an aseembly for reference abilities. It also provides some other benefits when it comes to the CAS but that could be another article. The reason the hashing exists is to verify that the assembly is the same as it was before so that when an app loads the assembly it can be sure it has the one it is supposed to. If you remove the strong name then an app that references that assembly won't be able to find it thus defeating the purpose of trying to highjack the assembly.
Great article though. I need to get off my butt and submit the ones I have laying around. Kudos to you.
-
Drew
|
|
|
|

|
Thanks for your series of articles, they are well written and easy to understand.
I really don't see the point of strong named assemblies after reading this. I didn't think it would be that easy to crack, but I guess, having clear text IL code will always make it easily breakable.
A previous comment said that Strong Named assemblies are just for more reliable referencing. I really had the impression that it was for security, but you have blown that theory sky high!
Thanks
Being in a minority of one, doesn't make you insane George Orwell However, in my case it does
|
|
|
|
|

|
Remove security checks all over by removing the security related assembly declarations from machine.config...
VictorV
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
Building Security Awareness in .NET Assemblies : Part 3 of 3
| Type | Article |
| Licence | |
| First Posted | 31 Oct 2004 |
| Views | 195,307 |
| Downloads | 998 |
| Bookmarked | 89 times |
|
|