HighTechTalks DotNet Forums  

Protecting Assemblies

Dotnet Distributed Applications microsoft.public.dotnet.distributed_apps


Discuss Protecting Assemblies in the Dotnet Distributed Applications forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Anthony Bouch
 
Posts: n/a

Default Protecting Assemblies - 05-16-2006 , 04:52 PM






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 With Quote
  #2  
Old   
Barry Kelly
 
Posts: n/a

Default Re: Protecting Assemblies - 05-16-2006 , 05:07 PM






"Anthony Bouch" <ab (AT) nospamever (DOT) com> wrote:

You've crossposted!

Quote:
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.
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 With Quote
  #3  
Old   
Gaurav Vaish \(EduJini.IN\)
 
Posts: n/a

Default Re: Protecting Assemblies - 05-17-2006 , 12:13 AM



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


"Anthony Bouch" <ab (AT) nospamever (DOT) com> wrote

Quote:
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 With Quote
  #4  
Old   
Anthony Bouch
 
Posts: n/a

Default Re: Protecting Assemblies - 05-17-2006 , 10:14 AM



Thanks Gaurav. Interesting and helpful.

"Gaurav Vaish (EduJini.IN)" <gaurav.vaish.nospam (AT) nospam (DOT) gmail.com> wrote in
message news:e3pYJhWeGHA.2068 (AT) TK2MSFTNGP02 (DOT) phx.gbl...
Quote:
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
-------------------


"Anthony Bouch" <ab (AT) nospamever (DOT) com> wrote in message
news:uAA03qSeGHA.2076 (AT) TK2MSFTNGP04 (DOT) phx.gbl...
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 With Quote
  #5  
Old   
Gaurav Vaish \(EduJini.IN\)
 
Posts: n/a

Default Re: Protecting Assemblies - 05-17-2006 , 02:30 PM




"Anthony Bouch" <ab (AT) nospamever (DOT) com> wrote

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


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




Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.