Re: Protecting assemblies from being used outside a company/group/team

From: Nicole Calinoiu (calinoiu)
Date: 02/03/05 

Date: Thu, 3 Feb 2005 07:49:52 -0500

"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e90v5uXCFHA.3928@TK2MSFTNGP15.phx.gbl...
> Not sure I follow that completely. How does reading the
> strong name from the assembly help?

Reading the public key directly from the assembly file on disk is a slightly
more robust approach since the assembly could spoof its own evidence at
runtime if it has sufficient CAS permissions. In other words, if you use
the .NET framework classes to read assembly information, you may be reading
pure fiction. Howevever, you could use lower level API functionality (e.g.:
StrongNameTokenFromAssemblyEx) to read the public key directly from the PE
file. You could also use the StrongNameSignatureVerificationEx to check if
the PE file has delay signed or fully signed. That said, it may also be
possible to spoof the PE file path reasonably easily, so using the lower
level API may actually have very little benefit. (I haven't actually tried
spoofing the PE file info, so I'm not sure how difficult it might be.
However, I suspect that it's probably possible via either evidence massaging
or swapping out the PE file after it loads.)

> You could find the logic points, but to create a "cracked" assembly and
> distribute you still need to make a change to the code and round trip the
> IL, which you can't do currently when using some obfuscators.

If you can't round-trip the IL, you're probably using a tool that does a
little more than mere obfuscation. Regardless of the details, this sort of
thing probably just defers the problem since assemblies that are deployed
today with such techniques will still be available for decompilation when
folks figure out how to bypass the protective mechanism at some point in the
future. Unfortunately, the more popular the tool, the more likely it is
that someone is working on bypassing its protective mechanisms...

Relevant Pages

  • Re: Ngen.exe
    ... The lack of support for reading 2.0 assemblies is a limitation of the ... supports the 2.0 C# language extensions yet. ...
    (microsoft.public.dotnet.security)
  • Re: Including a C# class in VB project
    ... > assemblies". ... > languages. ... > May I misunderstood. ... > Still reading ...
    (microsoft.public.dotnet.languages.vb)
  • Re: The internal key word does not work as a book say.
    ... I'm now reading a book and there are some example on the internal key work ... You can have multiple namespaces in the same assembly, and the same namespace in mulitple assemblies. ...
    (microsoft.public.dotnet.languages.csharp)