 |
|
When will part 4 be posted here?
|
|
|
|
|
|
Thanks for the link. Yeah, I have looked into it. No worries, the later article by me or a friend of mine will help clarify things.
Working on article 4 now, i believe it will an interesting article... hehe 
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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
|
|
|
|
|
Great done!!!
I don't find anythink better like use dotfuscator, but dotfuscator not realy protect application or assembly, so the one way is maybe possible do more secure to hide inside assembly or application code, the way is use small like VSTA engine inside and encript needed parts of code with unmanaged C++ 
|
|
|
|
|
Excellent series of articles - short and to the point. I like it
This space for rent!
|
|
|
|
|
Yes, They are very nice and useful.
Of cource I knew some parts.
![Rose | [Rose]](/script/Forums/Images/rose.gif)
|
|
|
|
|
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.
|
|
|
|
|
Hi John Cardinal,
Thanks. Yeah, I am working on the new articles, but have been busy lately. Furthermore, there are 6 days long holiday here.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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.
|
|
|
|
|
Hi punkrock,
Thanks for the clear clarification. I will bear that in mind when i write my coming articles. Hope I can write more clear and better articles in coming future.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Why not fix this one? It's horribly misleading.
|
|
|
|
|
Hi there,
If i have to fix this one, there is no point of this article (as people will not see what are the differences):
http://www.codeproject.com/dotnet/StrongNameExplained.asp#xx985079xx
It is refering to my article. So i prefer to let it be.
Sorry for the inconvenience.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
I think that you did some great work back there Chua!!! Carry on with it and hope you come up with another article soon.
The simplicity makes for such nice understanding that it is quite amazing.
Also please do keep on writing them like tihs. It is much better to read up on your opinions as they are changing. Too often understanding doesn't come because we do not understand the history behind it.
|
|
|
|
|
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.
|
|
|
|
|
Hi Hugo Hallman,
Point taken. Thanks.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Yes, this is correct statement. Microsoft created strong names to prove identity. Also this article makes mistakes in security concept. Strong names are related to .NET security infrastructure which can be partly seen in .NET Configuration wizard in Runtime security.
Here is important to understand security policies and code groups.
When you define your own code group where application will belong according to its strong name then it will get runtime permissions (maybe some higher ones because otherwise it will get the default ones from default code groups according to its origin - there can be other scenarios like when using GAC, third party assemblies etc).
This scenario is similar like when you would create app with strong key and you would leave doors open. Then when you loose your key then you can still pass through the door. But if the door are locked and require a key then when you remove the strong name from app you can't pass (doors = code groups).
So you can throw all your keys out like you can do it just droping them from your pocket. But then you'll not get at home, to your car simply anywhere where authorization is required.
So this article makes no sense.
Some more samples on this topic will come in my freebook on http://www.skilldrive.com/DOTNETinSamplesdoc.zip
Regards,
Jan
|
|
|
|
|
Hi Jan,
Thanks for the explanations. I will look into your examples.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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 
Regards and wish you many success.
Jan
www.skilldrive.com
|
|
|
|
|
Thanks Jan. I hope to be a MVP one day for sure.
But anyway I wrote these articles for my interest in this field.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
Hope you like it. Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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/[^]
|
|
|
|
|
Point taken.
I am looking into it. Cheers
Regards,
Chua Wen Ching
|
|
|
|
|
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.
|
|
|
|
|
Hi Hugo Hallman,
Thanks for the clarification. Point taken.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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
|
|
|
|
|
"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
|
|
|
|
|
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!
|
|
|
|
|
Daniel Turini wrote:
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.
I agree with Daniel. To KNOW to do the attack is the best form of protecting. Writing Secure Code[^] among other very useful things, talks exactly about this...
Marcelo Palladino
Brazil
|
|
|
|
|
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
|
|
|
|
|
Hi adinnell,
Point taken. There will be a total of 9 articles or more. I will provide some detail explanations on strong name in my article 4, which is in the process.
Thanks
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
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
|
|
|
|
|
Thanks. Hope you like it.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Don't forget this is very simplistic implementation of using strong names for security. A developer fluent in assembler could just as easily do something similar with compiled win32 code.
Strong names are also used for other reason like assigning privileges on a machine/enterprise based on the strong name or public (see Runtime security policy in .Net configuration, many Microsoft assembly are granted special privileges by their public key). .Restrictions can be applied for access to methods/classes in other systems based on public keys by using codeaccess security. (see StrongNameIdentityPermission).
Although as this article demonstrates Strong names could be compromised, if you employ a complete security model these changes can be detected. I would recommend that you sign all code, even if it is only deployed to desktops within your organisation. Security is not so much as preventing tamper completely, but making mechanisms that allow you to detect tamper and take appropriate action to prevent the system being compromised.
Rather than take the author at this word here suggest you get a good book on .Net security. The author is technically correct, his article is informative, but he has assumed that you are only using strong names for a single purpose which is only part of the .Net security model.
Sorry about the rant but as a consultant I often come into organisations where no security has been applied to .Net code, even on public web servers.
.Net code can be made secure, but like any good security system a compromise has to be expected and dealt with appropriately. To assume that you code/System will never be compromised just means you will never know when it is.
:(
|
|
|
|
|
HI J.B,
Thanks. Point taken.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Submit an article or tip
Post your Blog
News 
Suggestion 
Bug 
Joke 
Rant 
Admin 
