[Mono-list] Security Q

[Tom Larsen]

I've seen this kind of question pop up before: they want the compiled 
binary to be obscured.  Unfortunately I have yet to see any solution that 
obscures the "user" disassembler but allows the "runtime" disassembler to 
execute.  And often I have to wonder "why bother?"  Obscuring code seems 
to cause more problems than it solves.

.Net is not natively an "obscure execution platform".  I always cringe at 
the idea of trying to make a runtime platform something it wasn't designed 
to do.  There are clever ways of obscuring code using runtime encryption 
in C/C++ which can theoretically be applied to .Net IL but its slow and 
sooner or later instructions are passed out of the secured/encrypted space 
and hits the processor which in general is unsecured.  In short, if you 
run it on a machine, even virtual ones, you can always intercept the
instruction so putting all of that fancy encryption in the way is somewhat
meaningless.

So let me ask this: why do you think you need to have your .Net 
application obscured?  After all, the best security patterns are well 
known.  What strength do you think you will have by hiding how your 
application executes?

Security and secure code isn't about hiding stuff.  Its about a sound 
process and data flow.  Concentrate on that instead of trying to make the 
runtime do something it was never designed to handle.

Tom Larsen

On Wed, 8 Sep 2004, PFJ wrote:

> Hi,
>
> What command while compiling my source code do I need to pass to mcs so
> that the compiled code is not readable? I know there is a way to reverse
> engineer C# code by looking at the bytecode and want to prevent someone
> from doing this for a small security program I'm writing.
>
> TTFN
>
> Paul
> -- 
> "If I face my God tomorrow, I can tell Him I am innocent.
> I've never harmed anyone. I have cheated no one.
> I have deceived no one. I have hurt no one.
> Except myself. And that He will forgive me." - Hans Holzel
>