|
Thanks for the reply & looking forward to read any articles you're going to post in the future
|
|
|
|
|
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?
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|