[Mono-list] How to protect a mono application from reverse engineering?

Jonathan Pryor jonpryor at vt.edu
Sun Oct 24 21:49:26 EDT 2010

On Sun, 2010-10-24 at 18:42 +0200, Stéphane C wrote:
> I am currently evaluating mono as a replacement of Qt/C++ for a
> commercial application but I'm a bit worried about the way it
> compiles. Extracting the source code from an IL assembly seems a very
> easy task, in fact I found it quite alarming, thus I am looking for
> ways to protect my application. 

It should be noted that native code is no solution either; it's quite
possible to reverse engineer native assembly code, and there are a
number of commercial tools which greatly simplify the process.
(Granted, it's not quite as easy as with IL & Reflector, but it's not
significantly more difficult for those who *really* want to understand
your app, either.)

> It's not that I'm a paranoid, thinking the entire world is going to
> hack my software but I need to prevent people from running modified
> versions of some crucial parts. 

Again, native code would have the same problems, and the solutions are
largely the same:

  - embed a file hash of the program into the program and verify that
    the hash is correct during app startup
  - Encrypt parts of the program and use some private key to unencrypt
    those bits
  - Move the *really* important bits to a server, and require network 
  - ...

It should be noted that all of these (and more!) have been used for e.g.
copyright protection/copy prevention...and all have largely failed, when
enough people wanted to bypass it.  (See also CSS and ~every music
encryption scheme known to man.  And XBox360/PS3 app startup. And...)

The only reasonably surefire approach is requiring use of a server, and
even that has been bypassed (in game copy protection systems, by hosting
a secondary server).

(Remember, most of the above systems did NOT have source available, and
yet they were still broken.  Native code will at best slow down

So really, you can either hope for being infrequently used enough to not
draw the ire of those who break these systems for fun, try to play
cat-and-mouse with the inevitable "breaks", or to just give up and sue
anyone you later find to be copying your program.

 - Jon

More information about the Mono-list mailing list