 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / March 2005Cheating with ILDASM/ILASM
I have found that it is possible to do the following: 1. Disassemble a strong named assembly held in the GAC. 2. Make some changes (if desired). 3. Reassemble it and replace it in the underlying GAC folder (e.g. C:\WINDOWS\assembly\GAC\MyLib\1.0.0.0__1ac87ef5ff129800) without actually installing it to the GAC (since it doesn't have a valid strong name). 4. Run an existing application that uses this library and it will use the modified code. You could reassemble it with debug symbols switched on too. All of this is done without using the original private key. Can anyone reproduce this? I would imagine it applies to any library held in and loaded from the GAC, including those provided by Microsoft with .NET. I believe the strong name check is done only when the library is installed to the GAC, not on subsequent resolution. I haven't done any further tests but I was wondering whether this might also have implications for Code Access Security, since the strong name could not have been checked properly in this case - would the CLR still go back and check the strong name properly when resolving permissions? >I have found that it is possible to do the following: You can only do this with admin privileges on the machine. And as an admin you can do any number of stupid things that would screw up CAS and everything else. Mattias  SignatureMattias Sjögren [MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. > You can only do this with admin privileges on the machine. And as an > admin you can do any number of stupid things that would screw up CAS > and everything else. So I guess you are saying that that does bypass CAS checking. Well it's certainly true that there are other ways to screw CAS up, but it does seem a bit too easy and difficult to detect. For example when CAS is turned off I would have expected a more obvious warning than the single line at the top of the CASPOL output and nothing else from any other tools. It doesn't bypass CAS checking, it bypasses the digital signature verification check. CAS is still in place. -Brock DevelopMentor http://staff.develop.com/ballen >> You can only do this with admin privileges on the machine. And as an >> admin you can do any number of stupid things that would screw up CAS [quoted text clipped - 6 lines] > the single line at the top of the CASPOL output and nothing else from > any other tools. This is known behavior. You need Admin privileges to do what you just did. -Brock DevelopMentor http://staff.develop.com/ballen > I have found that it is possible to do the following: > [quoted text clipped - 20 lines] > the CLR still go back and check the strong name properly when > resolving permissions?
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.