.NETGURU
Private members and reflection
Messages   Related Types
This message was discovered on microsoft.public.dotnet.framework.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
Post a new message to this list...

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

Reply to this message...
 
    
remotesoft
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" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...
 
    
Richard Blewett [DevelopMentor] (VIP)
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:Click here to reveal e-mail address...
[Original message clipped]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.760 / Virus Database: 509 - Release Date: 10/09/2004

[microsoft.public.dotnet.framework]

Reply to this message...
 
    
Y S
[Original message clipped]


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.

Reply to this message...
 
    
Y S
[Original message clipped]


[Original message clipped]

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++ :-)

[Original message clipped]

Reply to this message...
 
    
Daniel O'Connell [C# MVP] (VIP)
[Original message clipped]

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.

Reply to this message...
 
    
Y S
> 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...
[Original message clipped]

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.

[Original message clipped]

honest?

Reply to this message...
 
    
Jon Skeet [C# MVP] (VIP)
Y S <Click here to reveal e-mail address> wrote:
[Original message clipped]

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.

--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Reply to this message...
 
    
Girish bharadwaj
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.

--
Girish Bharadwaj
http://msmvps.com/gbvb
"Daniel O'Connell [C# MVP]" <Click here to reveal e-mail address> wrote in
message news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...
 
 
System.Security.Permissions.ReflectionPermission
System.Security.Permissions.SecurityAction
System.Security.Permissions.StrongNameIdentityPermission




ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
Ad


Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews
.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT
Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project
FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.
Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials
 
ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
 Copyright © ExamGuru, Inc. 2001-2006
Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification