 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / September 2004Private members and reflection
Hello, Is there any way to prevent a tool like Reflector (http://www.aisto.com/roeder/dotnet/) from reading and disassembling private members using reflection? I am aware of a suggestion posted here by Microsoft, stating that using [StrongNameIdentityPermission...] may help, but I can't find any example for successful usage of it. Thanks, Y S You can try to put ReflectionPermission to the whole assembly: In AssemblyInfo.cs, add the following: [assembly: ReflectionPermission(SecurityAction.RequestRefuse, unrestricted=true)] This will prevent any reflection calls using the standard .NET Framework APIs, but it won't prevent other native code based disassembler/decompiler, such as our .NET Explorer and Salamander Decompiler, or Microsoft's ILDASM utility. I am not sure whether it will work against Reflector. Huihong Remotesoft > Hello, > [quoted text clipped - 8 lines] > Thanks, > Y S > You can try to put ReflectionPermission to the whole assembly: > > In AssemblyInfo.cs, add the following: > > [assembly: ReflectionPermission(SecurityAction.RequestRefuse, > unrestricted=true)] I actually did that, all over the assembly code, to no avail... > This will prevent any reflection calls using the standard .NET Framework > APIs, but it won't prevent other native code based > disassembler/decompiler, > such as our .NET Explorer and Salamander Decompiler, or Microsoft's ILDASM > utility. I am not sure whether it will work against Reflector. Hmmm... so assuming that the above suggested premission juggle is working, Reflector must not be using the standard API approach... pretty neat for a freeware... There must be something evident here I miss, as otherwise C# has a real problem protecting private code. Note that I had no difficulty browsing MSFT's code in mscorlib, not that there is any problem with that, but you would expect to have a way to hide your personal stuff. Well, back to C++ :-) > Huihong > Remotesoft [quoted text clipped - 13 lines] >> Thanks, >> Y S > There must be something evident here I miss, as otherwise C# has a real > problem protecting private code. Note that I had no difficulty browsing > MSFT's code in mscorlib, not that there is any problem with that, but you > would expect to have a way to hide your personal stuff. Why, so you can have the false sense of security you had in C++? Its not like x86 is an arcahic langauge that no one knows, its unfortunate but your code *will* be cracked and\or stolen if someone wants to, and there is nothing you can do about it. If you are just worried about people not stealing your code, its pretty likely you're out of luck either way as well. You can use an obfusticator to mess up your code pretty well, but anyone who is dedicated enough can learn from the obfusticated code just as well as unobfusticated(and as well as X86 assembly, for that matter) and learn how you did it and steal it. Beyond that, for all but the most complicated applications, many people can just look at the input and output and clone the apps functionality. You are really just fooling yourself if you think your code is safe once its released into the wild. Its not. Security through obscurity has worked correctly. If the thing is important enough, someone will crack. Of course, this is the argument Open source used to use against MS and other propriatary implementations. I think security particularly important in this world of web services where the cracking the actual source is far less important than the actual transmission of bytes on the wire. Anyway, to answer the original caller's question. you can always write your "secure" code in unmanaged C++ and use P/Invoke from C# and others, if it makes you more feel secure.  SignatureGirish Bharadwaj http://msmvps.com/gbvb > > > There must be something evident here I miss, as otherwise C# has a real [quoted text clipped - 18 lines] > You are really just fooling yourself if you think your code is safe once its > released into the wild. Its not. > Why, so you can have the false sense of security you had in C++? I don't think it is false, as long as you acknowledge its limits... > Its not like x86 is an arcahic langauge that no one knows, its unfortunate > but your code *will* be cracked and\or stolen if someone wants to, and > there is nothing you can do about it. No doubt that someone who has the time, knowledge and resources, will break the code, no matter if it was created using managed C#, X86 or a Turing machine. My only expressed concern was that when you create an assembly using C#, and take no precaution at all, a tool like Reflector can list your code as is (or almost "as-is"). This means that the time, knowledge and resources one has to invest are minimal. > You are really just fooling yourself if you think your code is safe once > its released into the wild. Its not. True enough. But hey, don't you put locks on doors to keep honest people honest? > > Why, so you can have the false sense of security you had in C++? > I don't think it is false, as long as you acknowledge its limits... [quoted text clipped - 8 lines] > code as is (or almost "as-is"). This means that the time, knowledge and > resources one has to invest are minimal. Have you tried reading thousands of lines of application code without any understanding of the architecture? Not libraries - they're relatively easy to understand, as they tend to be more modular - but application code? If you compile without debug information, you won't get local variable names - it's that much harder to understand. Use obfuscation and things get that much harder again. It may be feasible to understand small amounts of code, but not very much - not without spending far more effort than it would take to work out the code to start with. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Unfortunately stopping fully trusted code from doing stuff is incredibly hard ? see this article by Keith Brown for details http://msdn.microsoft.com/msdnmag/issues/04/04/SecurityBriefs/ Regards Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog ? nntp://news.microsoft.com/microsoft.public.dotnet.framework/ You can try to put ReflectionPermission to the whole assembly: In AssemblyInfo.cs, add the following: [assembly: ReflectionPermission(SecurityAction.RequestRefuse, unrestricted=true)] This will prevent any reflection calls using the standard .NET Framework APIs, but it won't prevent other native code based disassembler/decompiler, such as our .NET Explorer and Salamander Decompiler, or Microsoft's ILDASM utility. I am not sure whether it will work against Reflector. Huihong Remotesoft "Yaniv Schahar" wrote in message news:evnuqzSmEHA.412@TK2MSFTNGP10.phx.gbl... > Hello, > > Is there any way to prevent a tool like Reflector > (http://www.aisto.com/roeder/dotnet/) from reading and disassembling private > members using reflection? > > I am aware of a suggestion posted here by Microsoft, stating that > using [StrongNameIdentityPermission...] may help, but I can't find any > example for > successful usage of it. > > Thanks, > Y S [microsoft.public.dotnet.framework] > Unfortunately stopping fully trusted code from doing stuff is incredibly > hard ? see this article by Keith Brown for details > > http://msdn.microsoft.com/msdnmag/issues/04/04/SecurityBriefs/ Thanks, this was the exact article that triggered my original question... I had some short term hopes when I saw his suggested solution, but it does not work (at least not here, on my machine). It seems as if you have to limit the permissions of the *calling code* to prevent it from digging into another assembly, which can do nothing to protect itself. Oh well, as long as you are aware of that, it may not be that bad. 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.