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
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
