How about just releasing the code as open source ;-)
Heck, not everything should be protected and if you DO
need that kind of protection you can always go the more
conventional way of writing only that specific part
(usually an algorithm) in native code.
.NET is REALLY good (performance wise) in P/Invoke.
This doesn't seem to be all that complex, mostly you
just need to hook into the AssemblyResolve event and
store the encrypted assembly as a resource in the main
assembly. It gets interesting when you try to unencrypt
it, because then you have to deal with securing the key.
I suppose that it can be done via a web service or
something like this, but performance will suffer if it
is done remotedly.
The interesting question is where they put their keys.
The "JIT decryption" pattern has been
around for a long time, and became commonplace in the
mid-90s when viruses self-decrypted their payloads in
order to dupe the weaker signature-based scanners.
The problem with this type of protection is that the
weakest link is in the interface between it and the
platform (in this case the CLR). Once their algorithm is
discovered, it becomes easy to insert a layer in between
(think 'rootkit for CLR') which can access the
unprotected code. So in theory it does discourage
"casual decompilation", but everyone
knows that in X months ( 1 < X < 4) the
ripper with be up on IRC/Kazaa...
After some investigation, looks like this is not
encryption/decryption technology. This is kind of
partial pre-compilation. The pre-compiled code is
executed by what they call "SVM" -
some Virtual Machine. The idea is that pre-compiled code
does not need .NET metadata anymore, and it has a custom
format, which also may vary. So decompilation of such
code is impossible, but clearly should be some
performance impact. The SVM itself runs on top of CLR,
so it is not like compilation to native, the code is
still managed. This is good, especially for code
security support.