Protecting Assemblies

  • Thread starter Thread starter Anthony Bouch
  • Start date Start date
A

Anthony Bouch

I'm building an n-tier application with data access, application and UI
layers in separate projects and hence separate assemblies.
MyProjectUI.dll
MyProjectApp.dll
MyProjectDataAccess.dll

etc...

The application will eventually be publicly available for download and
installed on end-users machines.

How can I protect my middle tier and DAL assemblies from unauthorised access
so that a 'clever' user cannot add a reference to one of my separate
assemblies and start calling it's public members. Marking members as
Internal only works for classes that are 'inside' the same assembly.

Any tips or suggestions would be greatly appreciated.
 
You've crossposted!
I'm building an n-tier application with data access, application and UI
The application will eventually be publicly available for download and
installed on end-users machines.

How can I protect my middle tier and DAL assemblies from unauthorised access
so that a 'clever' user cannot add a reference to one of my separate
assemblies and start calling it's public members. Marking members as
Internal only works for classes that are 'inside' the same assembly.
Click to expand...

Fundamentally, you can't trust anything running on a client machine.
Normally, a middle tier runs on a remote machine (i.e. a middle tier
machine between the client and the database) for just this reason.

So, the "correct" answer is not to install the DAL assembly with the
client at all, and communicate via some mechanism (such as .NET remoting
or web services) with your middle tier.

-- Barry
 
You may add the constraints on the calling assembly.

Assembly.GetCallingAssembly()

And then verify the assembly. Verify against all the parameters - name,
version, culture and public key token.

Although you cannot trust the other party, but definitely you can verify the
other party.

You may also want to do some tricks:

In the calling assembly, put some embeeded resources, say public key or a
bitmap or a secret-key (though nothing is secret because of decompilers).
From the DAL assembly, verify that the resources exist untampered.

If you are using .Net 2.0, checkout the topic of "Friend Assemblies".
 
Thanks Gaurav. Interesting and helpful.

Gaurav Vaish (EduJini.IN) said:
You may add the constraints on the calling assembly.

Assembly.GetCallingAssembly()

And then verify the assembly. Verify against all the parameters - name,
version, culture and public key token.

Although you cannot trust the other party, but definitely you can verify
the other party.

You may also want to do some tricks:

In the calling assembly, put some embeeded resources, say public key or a
bitmap or a secret-key (though nothing is secret because of decompilers).
From the DAL assembly, verify that the resources exist untampered.

If you are using .Net 2.0, checkout the topic of "Friend Assemblies".


--
Happy Hacking,
Gaurav Vaish
http://www.mastergaurav.org
http://www.edujini.in
Click to expand...
 
Anthony Bouch said:
Thanks Gaurav. Interesting and helpful.
Click to expand...

If you are looking for any professional help in anti-piracy or protecting
your code, be sure to contact us.
You can either mail me at gvaish[at]edujini[dot]in or directly to
info[at]edujini[dot]in
It's a small company... about 10 dedicated guys :)

The website, altough does not speak of this in depth, is in the signature.
And don't miss out the "Expertise" section :-)


--
Happy Hacking,
Gaurav Vaish
http://www.mastergaurav.org
http://www.edujini.in
-------------------
 
Back
Top