[Mono-dev] Mono and Obfuscation
David Elkind
davide at mainsoft.com
Fri Feb 2 07:50:24 EST 2007
Hello Jon,
>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.
I think obfuscation and encryption help achieving different goals: it makes
sense to use encryption when you want, for instance, to protect your
application from copying. Then you put the decryption logic (and not just
the key) some smart card device (for instance, USB or serial plug). The code
is decrypted by pieces, right before execution (or JITting in our case), so
that the whole decrypted module (assembly) does never exist, even in memory,
so it is hard to recreate it as a whole plaintext entity.
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.
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.
>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
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
2:28 PM
More information about the Mono-devel-list
mailing list