Re: Application security

From: Nicole Calinoiu (nicolec_at_somewhere.net)
Date: 05/19/04 

Date: Wed, 19 May 2004 07:13:28 -0400

<anonymous> wrote in message news:u79phHYPEHA.2740@TK2MSFTNGP11.phx.gbl...
> One of my libraries use reference to Interop.SHDocVw to capture IE events.
> I don't want that this lib can be called from another program than my
> mainapp.exe.
> Strong names seems to respond partially to this need. (as I use LinkDemand
> in StrongNameIdentityPermission... ).
> The problem is I can't even compile my code with [assembly:
> AssemblyKeyFile]
> set to my key file, because compiler says that reference Interop.SHDocVw
> has
> no strong name.

You need to ensure that the managed COM wrapper that's being created for you
by VStudio is also signed with your key. To do this, open the properties
dialog for your project in VStudio and add the appropriate key file or
container name in the "Wrapper Assembly for ActiveX/COM Objects" section on
the "General" page. (Help topic is available at
http://msdn.microsoft.com/library/en-us/cscon/html/vcurfCProjectGeneralPropertyPage.asp.)

> My project contains some unmanaged dll I
> want to protect from being called by extra exe.
> Is it possible ?

Unmanaged code cannot take advantage of the services offered by the CLR.
Your protection options for an unmanaged DLL are the same as they would be
if the .NET Framework did not exist at all.

> The problem is not with Dotfuscator but with obfuscation.
> Obfuscation creates more complex code to decompile. But it is not a secure
> solution. Logic of the program can be rebuild after obfuscation.

Your logic can also be determined from machine code if someone is
sufficiently motivated to make the effort. <g>

As I mentioned in my previous post, there is at least one vendor offering a
code protection system that supposedly strips out the MSIL. However, I've
never used it, so I won't recommend it. There may also be others since last
time I looked. A web search on a relevant search term list (e.g.:
obfuscation + decompilation + ".net") should reveal a pretty complete set of
vendor offerings.

You should also be aware that any mechanism that strips out the MSIL will
run somewhat counter to how assemblies are intended to be used by the CLR.
If you do choose such a solution, you should probably be prepared to run
into a few unexpected problems at deployment and runtime. The quality of
vendor support should probably be a major factor in your selection of this
type of solution.

HTH,
Nicole

Relevant Pages

  • Re: Application security
    ... >> set to my key file, because compiler says that reference Interop.SHDocVw ... >> The problem is not with Dotfuscator but with obfuscation. ... > As I mentioned in my previous post, there is at least one vendor offering ... > code protection system that supposedly strips out the MSIL. ...
    (microsoft.public.dotnet.security)
  • Re: Blindly Into the Bubble
    ... in the home mortgage market. ... discussion exactly what protections you reference at mortgage signing. ... Allow me to submit that if average Joe Sixpack needs ... protection with his mortgage, he needs that protection before he ...
    (soc.retirement)
  • Re: Blindly Into the Bubble
    ... in the home mortgage market. ... exactly what protections you reference at mortgage signing. ... me to submit that if average Joe Sixpack needs protection with his ...
    (soc.retirement)
  • Re: Blindly Into the Bubble
    ... in the home mortgage market. ... Allow me to submit that if average Joe Sixpack needs protection with his mortgage, he needs that protection before he commits - signs those papers - rather than after. ... Please be specific and share with us exactly what protection you reference. ...
    (soc.retirement)
Loading