Protecting Assemblies

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Anthony Bouch - 16 May 2006 21:52 GMT

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.

Reply to this Message

Barry Kelly - 16 May 2006 22:07 GMT

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
[quoted text clipped - 4 lines]
> assemblies and start calling it's public members. Marking members as
> Internal only works for classes that are 'inside' the same assembly.

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

Reply to this Message

Gaurav Vaish (EduJini.IN) - 17 May 2006 05:13 GMT

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

Signature

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

> I'm building an n-tier application with data access, application and UI
> layers in separate projects and hence separate assemblies.
[quoted text clipped - 13 lines]
>
> Any tips or suggestions would be greatly appreciated.

Reply to this Message

Anthony Bouch - 17 May 2006 15:14 GMT

Thanks Gaurav. Interesting and helpful.

> You may add the constraints on the calling assembly.
>
[quoted text clipped - 32 lines]
>>
>> Any tips or suggestions would be greatly appreciated.

Reply to this Message

Gaurav Vaish (EduJini.IN) - 17 May 2006 19:30 GMT

> Thanks Gaurav. Interesting and helpful.

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 :-)

Signature

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

Reply to this Message

Protecting Assemblies

Free Magazines