Private members and reflection

[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

 

[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

 

[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

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

 

[Daniel O'Connell [C# MVP]]

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.

 

[Richard Blewett [DevelopMentor]]

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:[email protected]...

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

---
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]

 

[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.

 

[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...

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?

 

[Y S]

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.

 

[Jon Skeet [C# MVP]]

I don't think it is false, as long as you acknowledge its limits...
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.

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.