Prevent Reflection of Private Members

[Matthias Truxa]

Hello NG,

I'm 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 wasn't
able to achieve what I need (or I don't 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

 

[Willem van Rumpt]

Hello NG,

I'm 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 wasn't
able to achieve what I need (or I don't understand the concept of these
permissions).

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

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

Well, short of not deploying the assembly locally at all, I don't think
there's 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?

 

[Matthias Truxa]

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

 

[Peter Duniho]

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

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's possible
and what's not. If .NET had tried to prevent reflection of code based
on security permissions, it would simply have misled people into
thinking that there's a way to prevent reflection of code based on
security permissions.

Pete