No, the wrapper itself isn't the/a problem. The problem is in how people will deploy their games. I can't look now, since I've given away my 3DGS license key (and don’t even have it installed anymore), but I think even Lite-C games can be easily patched/reversed/cracked/etc.

Without revealing too much of my personal "insurance policy", I'll try to give a bit of an explanation...

#1) Good obfuscators are a MUST! Dotfuscator should be sufficient in repelling the majority of attacks. But don't kid yourself into thinking it's invincible.

The key is verbosity and ambiguity. Good obfuscators will let you control what lengths it goes to. With a good one, any program (like Reflector) which tries to parse the IL, metadata and generate source code will get a whacky jumble of practically meaningless code. It is hard enough to understand clean code without documentation and comments, but this ups the ante. The only thing you really have to worry about is using System.Reflection in your assemblies, which can cause unexpected bugs in obfuscated CIL.

#2) Next is encryption. You can have all of your strings encrypted, of course. But you can also fully encrypt your assemblies with certain tools (or on your own). They key to this is just making sure there's a way for the CLR to decrypt and understand the code, so it can be JIT'ed. Believe it or not, there are still even ways to precompile .NET to native binary! However, portability is a HUGE concern, and you lose the power of CLR management. So I really wouldn't think of that, honestly.

So I think there's two possible options. There's raising community awareness about possible attacks on their .NET games, and there's creating a tool to prevent it. The former, I think, needs to be done in any case. People need to understand what's possible BEFORE they start working on a serious project.

I'm very experienced with .NET and know most of the intricacies of the CLR. I've also got a pretty strong arsenal of knowledge pertaining to native assembly language, and how it relates to programmers concerned with security. When we were teenagers, my friends and I would even exchange Win32 "crackme" applications and try to crack/patch/keygen each other's code. And I still probe my own native code for weaknesses with a good ol' debugger. Even native can be frighteningly easy to crack. :-/ The trick is to make it so time consuming that the attacker will give up and move on.

If wanted, I can make time soon to do some articles/tutorials about such topics, and .NET/CLR themselves. I think that could shed some light on different vulnerabilities and possibilities. So if people are interested, please let me know, and what topics you would like to know more about. I can even do general C# stuff too, since I’ve noticed that most people try to make C# code “just work”, instead of work correctly and efficiently. I.e., making fields public (static) for external access. Ewww! *shudders*

But on top of this, there are even less forceful ways to impede cheaters and crackers. Those pertain to the actual design of the software itself. This is especially true for online game networking; where a good client/server architecture can make cheating nearly impossible!

Oops, sorry for MY verbosity, heheh… But let me know. I’ll be around frequently.