Prevent Reflection of Private Members

Hello NG,

I am working on a licensing component. In my validation class I'd like to
temporarily cache this and that using static fields. However, in order to not
compromize security, I have to prevent any foreign code to access or change
these private static fields. Using reflection (and proper rights) anyone
could easily reflect these fields and change them, thus cracking my
validation procedure.

I experimented with the ReflectionPermission attribute, however, I was not
able to achieve what I need (or I do not understand the concept of these
permissions).

What is the best way to secure a single class in an assembly against any
caller who wants to access privates?

Thank you,
Matt

Matthias Truxa wrote:I am not an expert on permissions, but I think the

I am not an expert on permissions, but I think the ReflectionPermission
attribute will only be useful in scenario's when the caller does not have
full trust. If the assembly is to be deployed on an end-user machine, I
cannot prevent him having full trust.


Well, short of not deploying the assembly locally at all, I do not think
there is anything you can do to prevent it. Maybe the licensing classes
in the framework (http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx)
can help you achieve what you want, without rolling your own licensing
component?

Hello myself,seems this is not possible at all - one cannot prevent foreign

Hello myself,

seems this is not possible at all - one cannot prevent foreign code against
reflecting metadata of .net types - too bad. Full-Trust callers can always do
that, and additionally there are unmanaged components that can populate
metadata. Hence the problem is the metadata itself, i.e. the byte-code nature
of .NET assemblies.

Not even the StrongNameIdentityPermission (only authentified callers allowed
to use some member) secures any longer since .NET 2.0.

Regards,
Matt

Matthias Truxa wrote:No, the problem is fundamental to the way client

No, the problem is fundamental to the way client applications work.  For
managed code, it is slightly easier to reverse-engineer the code, but
the same issue exists for unmanaged code too.  There have been
decompilers around since long before .NET has existed, including those
which work for native compiled code.

As Willem says, the only way to prevent someone else from reverse
engineering your code is to not deliver it to them in the first place.
This is true no matter what language, framework, compilation, etc. that
the code uses.

Frankly, had .NET attempted to enforce reflection-based restrictions,
those restrictions would only provide a false sense of security.  The
way things are now, you have a very realistic sense of what is possible
and what is not.  If .NET had tried to prevent reflection of code based
on security permissions, it would simply have misled people into
thinking that there is a way to prevent reflection of code based on
security permissions.

Pete