[Mono-dev] Mono and Obfuscation

[Miguel de Icaza]

Hello,

> However, this quite does not serve the purpose of obscuring the algorithm or
> other know-how involved in the application because as the system has to
> decrypt the code before JITting, this is the place where the reverse
> engineer can come in and watch the actual, plain-text pieces of MSIL just
> before they get JITted and therefore deduce the algorithm or know-how quite
> trivially.

Yes.   I have done this while hunting down bugs in applications that
were submitted to us in binary form.

I replace the code in Assembly.cs, and save the resulting assembly
before it gets loaded into Mono.

So depending on these kinds of hacks is not secure *at all*.   In fact,
its so insecure, that I would be willing to put a
MONO_DUMP_ALL_LOADED_ASSEMBLIES environment variable to make it even
simpler and discourage this fake sense of security.

> Obfuscation, however, is based on a different approach: if the code is hard
> to understand, it becomes much trickier to get to the core business. You
> could just write REALLY unreadable code from the beginning, but this is
> quite impractical for obvious reasons. Obfuscators just do this for you as a
> post-build step, allowing you to maintain good code base and fool the
> plagiarist at the same time.
> It is true, in general, that any code which is executed by the computer can
> be understood by human. However, as you increase the burden, you are
> protected much better. 

The problem is that these tools the best they can do is rename symbols
in the code (the flow change is another problem, but that also can be
fixed by anyone that really needs to get to the bottom of things).

Someone smart could use Cecil to rename the symbols and fix all the
public names so things like "break ildasm" fail.   Dis# for example has
a capability to let you edit names in place, so you can gradually
"recover" the assembly.


> >it's more portable than code obfuscation, and the same problems also
> >apply to code obfuscation (people can always debug the process and view
> >the JIT-generated code to see the unobfuscated assembly).
> 
> I think the last point is not exactly correct. The obfuscated code, as
> opposed to encrypted one, can be executed (JITted) as is; it is just harder
> for humans to understand it. Also, I do not understand how the portability
> is involved.
> 
> David.
> 
> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan
> Pryor
> Sent: Friday, February 02, 2007 1:04 PM
> To: APS
> Cc: Mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] Mono and Obfuscation
> 
> On Thu, 2007-02-01 at 16:38 +0100, APS wrote:
> > I agree with you but my boss insist to find some level of protection 
> > from reverse engineering at least at some core library and I was 
> > investigating about how to do that.
> 
> As an alternative to obfuscation, use encryption.  You can encrypt an
> assembly, decrypt it into memory, and then use Assembly.Load(byte[]) to
> load the decrypted assembly.
> 
> This isn't a "real" solution for a number of reasons (people will be
> able to decrypt the assembly themselves, as the key will need to be
> bundled with your app; system memory & possibly the SWAP file will
> contain the decrypted contents; anyone with a debugger will be able to
> attach to the process in order to view the decrypted memory, etc.), but
> it's more portable than code obfuscation, and the same problems also
> apply to code obfuscation (people can always debug the process and view
> the JIT-generated code to see the unobfuscated assembly).
> 
>  - Jon
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
> 2:28 PM
>  
>