.Net Code Access

[abaljry]

Hi all,
I have built some dlls in c# using .NET 3.5 SP1.
and I want to protect these dlls from calling outside my application. which
means Only my application can access the functions, but if some one try to
use them they will not work with him.

what is the standard way to do this in .NET 3.5 SP1 ?
Thanks in advance

 

[Andy O'Neill]

Hi all,
I have built some dlls in c# using .NET 3.5 SP1.
and I want to protect these dlls from calling outside my application.
which
means Only my application can access the functions, but if some one try to
use them they will not work with him.

what is the standard way to do this in .NET 3.5 SP1 ?
Thanks in advance

Kind of the reason to compile into separate dll would be to share their
goodness.
Compile the projects into the one exe

 

[Arne Vajhøj]

I have built some dlls in c# using .NET 3.5 SP1.
and I want to protect these dlls from calling outside my application. which
means Only my application can access the functions, but if some one try to
use them they will not work with him.

what is the standard way to do this in .NET 3.5 SP1 ?

The intention with DLL's is to make them reusable.

If you really want to make some horrible code, then look
at internal visibility and the InternalsVisibleTo
attribute.

Arne

 

[Arne Vajhøj]

Kind of the reason to compile into separate dll would be to share their
goodness.
Yep.

Compile the projects into the one exe

But code residing in an EXE can still be reused
from another EXE.

Arne

 

[Andy O'Neill]

But code residing in an EXE can still be reused
from another EXE.

Arne

Well yes it depends on the degree of protection you want.
I have some pretty secure code on my hard drive.
Even that isn't as secure as the stuff on my usb stick in the drawer.

 

[Family Tree Mike]

Well yes it depends on the degree of protection you want.
I have some pretty secure code on my hard drive.
Even that isn't as secure as the stuff on my usb stick in the drawer.

I believe Arne was pointing out that an executable can be added as a
reference from visual studio, in the same way that a dll could.

Presumably, the person wanting to do this, with exe or dll, would know
where they put their usb stick. The author can't keep it for them (nor
from them).

 

[Arne Vajhøj]

Well yes it depends on the degree of protection you want.

The location in an EXE instead of a DLL does not
provide any extra protection in itself.

Arne

 

[Arne Vajhøj]

The location in an EXE instead of a DLL does not
provide any extra protection in itself.

If the visibility is changed to internal, then it do
have some effect. And that requires either building
everything into the EXE or use the horrible attribute.

Arne

 

[Peter Duniho]

Hi all,
I have built some dlls in c# using .NET 3.5 SP1.
and I want to protect these dlls from calling outside my application. which
means Only my application can access the functions, but if some one try to
use them they will not work with him.

what is the standard way to do this in .NET 3.5 SP1 ?

As has been pointed out, if you don't want the code available as a
separate library, then don't compile a separate library. Simple.

But as also has been pointed out, even when compiled directly into an
EXE assembly, other assemblies can reference the EXE and use the code.

You can use the "internal" accessibility to prevent that compiled-in
code from being visible as a plain reference. But through reflection,
it will still be available. Depending on what your idea of "protect"
is, the _real_ answer to your question is "you can't".

If you deliver code to run on a client computer, that code can be
reused. No matter what you do.

Pete

 

[Andy O'Neill]

I believe Arne was pointing out that an executable can be added as a
reference from visual studio, in the same way that a dll could.

Presumably, the person wanting to do this, with exe or dll, would know
where they put their usb stick. The author can't keep it for them (nor
from them).

Well yes, I got that.
I was attempting to explain somewhat humourously what Pete explained rather
clearer.

I suppose you could maybe obfuscate your code.

To perhaps be more constructive.
If the dll is only used by the one exe then stick the code in the same
project.
Separate things out using folders and compile into one thing.
At least someone would have to go to some effort then to extract the code
and recompile.
Maybe look at obfuscation.

For something where the code is very sensitive then a different platform
than .net might be more suitable.

All this is one of the reasons software houses like to offer software as a
service.

 

[Konrad Neitzel]

Hi Peter!

You can use the "internal" accessibility to prevent that compiled-in code
from being visible as a plain reference. But through reflection, it will
still be available. Depending on what your idea of "protect" is, the
_real_ answer to your question is "you can't".

If you deliver code to run on a client computer, that code can be reused.
No matter what you do.

Hmm. Isn't it possible to use Code Access Security (CAS)? It could be
possible to force, that the assemblies, that are calling your assembly, is
signed with a special Key (Publisher Evidence).

Something like:
[PublisherIdentityPermission(SecurityAction.LinkDemand,
SignedFile=@"c:\....")]

http://msdn.microsoft.com/en-us/library/930b76w0.aspx
http://msdn.microsoft.com/en-us/lib...ons.publisheridentitypermissionattribute.aspx
http://msdn.microsoft.com/en-us/library/system.security.permissions.securityaction.aspx

And a possible szenario would be, that a vendor has some DLLs and nobody
else then the own applications should use that code.
Not sure, if that makes sense, because someone can always use Tools to get
the code again. And even when the code is obfuscated, maybe it will be easy
to remove the attributes and recompile it? So maybe you simply insert some
code in important functions that checks the permissions? It could be much
harder to find / remove that way.

I never spend more time in this than reading / understanding it for my
070-536 exam, but maybe this information is usefull.

Konrad

 

[Peter Duniho]

[...]

If you deliver code to run on a client computer, that code can be
reused. No matter what you do.

Hmm. Isn't it possible to use Code Access Security (CAS)? It could be
possible to force, that the assemblies, that are calling your assembly,
is signed with a special Key (Publisher Evidence).

Possibly. But that doesn't stop someone from reusing your code. It
just forces them to copy your code into a different assembly that
doesn't carry that kind of protection.

[...]
Not sure, if that makes sense, because someone can always use Tools to
get the code again. And even when the code is obfuscated, maybe it will
be easy to remove the attributes and recompile it? So maybe you simply
insert some code in important functions that checks the permissions? It
could be much harder to find / remove that way.

As I always point out when this type of discussion comes up, my general
rule of thumb is:

Whatever level of effort is warranted to protect the code based
on the costs of that effort versus the costs of the code not
being protected, there is an equivalent level of effort warranted
by someone wanting to circumvent whatever protection you implement.

Or, put another way:

By definition, assuming you do not put more effort into protecting
the code than is actually justified, your code will not be well-
enough protected to discourage someone who really wants to reuse
it or otherwise reverse engineer it.

The corollary to the above is:

If your code is well-enough protected that no one will find it
worth the effort to circumvent your protection, then you spent
too much protecting the code.

Copy protection is a losing battle. Encryption is well and good for
protecting data, but only because public key encryption allows us to
have encryption without one end having the secret key required to
decrypt at the other end (and even there, we need longer and longer keys
as computing power becomes less and less expensive). Code can't work
until it's unlocked, and if that unlocking occurs on the client end,
then the client will always be able to see the code.

Instead of worrying about copy protection, one should ensure that they
offer value above and beyond just the code itself. Customer support,
documentation, or even using the code to provide a service rather than
delivering it to the customer, that sort of thing.

Pete

 

[Konrad Neitzel]

Hi Peter,

thank you. I think that was giving a good overview about the problems.

Konrad