[Mono-list] Security Madness

[Tom Larsen]

I'm not a big believer in code obfuscation especially on platforms like 
.Net.  The fact is that at some point an instruction hits the virtual 
machine in  an unofuscated manner.  All of the encryption in the world 
does not matter if the CLR runs it.  A hacker can hook into the CLR and
watch it process instructions.  So I always treat any .Net assembly as an
"open book".  If you want something to be secured you put the security 
elsewhere.

Instead of working to confuse how the assembly runs, you should work 
towards making the machine that runs it secured.  Instead of hiding how 
the assembly works, you should be working towards hiding the data and 
encrypting the transactions.  In fact IMHO, the authentication algorithrms 
should be open to review.  The then authenticaiton path however should be 
obscrued.

But if you really want to do this, just use well known public/private key 
technology.  Encrypt the assembly, when the app domain is being created 
decrypt it into a temporary file and load that assembly instead.

Tom Larsen

On Wed, 19 Jan 2005, Matthew Metnetsky wrote:

> I have one assembly, that when compiled is no more than 11kb's, but it
> contains code that manages our Universities authentication plus some
> more annoying things.  I've been asked to find a way to obfuscate this
> assembly my any means necessary.
>
> I've thought of a couple ways, which all seem like pure madness.  What
> do you all think?
>
> 1) Maintain an encrypted copy of the assemblies CIL code that is
> reachable via Http for quick download and compilation.  Every time the
> application started it would grab the file, descrypt, and compile into
> the current AppDomain.
>
> 2) Similar to the previous option... maintain an encrypted copy of each
> file that makes up the assembly for retrieval and compilation into the
> current AppDomain.
>
> 3) rewrite the entire assembly so that it's generated real time by a
> Codedom into the current AppDomain.
>
> 4) Make use of assembly signing and loading permissions, which don't
> seem to keep people from reworking the code to CIL.
>
> So.... what should I actually do?  The above options seems absurd, but
> I've been asked to take absurd measures.
>
> ~ Matthew
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>