Long and short is really in the question title. For a language which compiles to an intermediate language like MSIL or Java byte-code, if there's concern about something like reverse engineering or hacking to disable security features, should AOT (ahead of time) compilation be considered rather than just obfuscation? Obviously, there's a bit of wiggle room in this question as there's no one answer I wouldn't imagine, but when would you start looking at performing an AOT compilation before distributing something versus sending it out obfuscated?

If you have much reason for concern about RE, you should be aware that neither is really going to do a whole lot of good. Pure assembly language code can be RE'd quite effectively as well. It's somewhat slow going, but can certainly be done.
–
Jerry CoffinSep 21 '11 at 17:05

1

Moral of this story is: you can't protect anything that exists on the end user's computer. The worst case scenario is that you try to protect your code and inconvenience the end user, oops you just lost a customer to a competitor who has made the user experience his priority and gained a bad reputation.
–
Patrick HughesSep 21 '11 at 17:10

@JerryCoffin - I've always kind of imagined that it could be done, but I'd also imagined it being at least a magnitude's worth more work.
–
trycatchSep 21 '11 at 17:40

4 Answers
4

Its my understanding that .NET assemblies (and, I assume java .class files, too) include a hash value of some sort. If the hash value fails when the .class or assembly is loaded then, I believe, its rejected and an exception is thrown. So, if someone did decide to take a hex editor to an assembly or .class file, they'd have to know how the hash value was calculated and update that part of the file with the correct value as well.

In addition, .NET assemblies can also be Strongly Named which can also help in ensuring an assemblies integrity and provenance.

should AOT (ahead of time) compilation be considered rather than just obfuscation?

Although probably not your intent, that can be interpreted as "should we use AOT compilation as opposed to obfuscation", which implies that AOT compilation > obfuscation. This is not necessarily the case, in fact, I would argue that good obfuscation is better than AOT compilation, since it will at least slightly irritate the person doing the RE in assembly. In the long run though, neither will be of much help; anything can be cracked, given enough time.

Don't distribute. Expose via the web or something like Citrix. Bloomberg have built a multi-billion dollar business doing that and their users love it. (Well we don't seem to be able to provide much comfort with AOT or Obfuscation).

It'll be a lot harder to maintain different versions. You should either use a language like C++ or if you're stuck with Java, you can use a custom class loader instead of just obfuscating. All code can be RE'd with time; I'd just trust the law to do your work for you and obfuscate.