|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Protecting AssembliesI'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. "Anthony Bouch" <ab@nospamever.com> wrote: You've crossposted!> I'm building an n-tier application with data access, application and UI Fundamentally, you can't trust anything running on a client machine.> 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. 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". Show quote "Anthony Bouch" <ab@nospamever.com> wrote in message news:uAA03qSeGHA.2076@TK2MSFTNGP04.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. > > Thanks Gaurav. Interesting and helpful.
Show quote "Gaurav Vaish (EduJini.IN)" <gaurav.vaish.nospam@nospam.gmail.com> wrote in message news:e3pYJhWeGHA.2068@TK2MSFTNGP02.phx.gbl... > 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@nospamever.com> wrote in message > news:uAA03qSeGHA.2076@TK2MSFTNGP04.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. >> >> > > "Anthony Bouch" <ab@nospamever.com> wrote in message If you are looking for any professional help in anti-piracy or protecting news:OTEGwwbeGHA.3364@TK2MSFTNGP05.phx.gbl... > Thanks Gaurav. Interesting and helpful. > 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 :-)  |
|||||||||||||||||||||||
Other interesting topics