OBFUSCATORS PAGE UPDATED

Just a quick a post: I have updated the page containing the list of obfuscators of .NET IL code, adding two word checking:

• BitHelmet, and
• Eazfuscator.NET.

You can find the whole list here.

Cheers!
~Pete

> Link to Spanish version.

NEED OBFUSCATOR FOR .NET? - PART 2

Remember this post?

Well, on XNA GSE's forums there's a new thread -regarding the same matter- where Jim Perry has posted a very useful link to a site with a list of available obfuscators for .NET (as well as discontinued ones).

The beauty of the site is that for each obfuscator listed, you will also know which versions of the .Net framework it works with (included the compact framework), whether there's a free version to download, when it was last updated, the vendor, etc.

Hope it helps, bye!

[BTW, I have tried to find a comparison chart in the Internet (independent from any vendor) with no success so far ... :( ]

NEED OBFUSCATOR FOR .NET?

Do you remember the second part of the series "Deploying Games To The 360 Without Sharing Source Code" -related to obfuscation of .NET assemblies?

Well, if you're not interested in the subject just skip this post. Otherwise, read on ...

I have searched the Internet for some obfuscators and this is what I've found so far:

• BitHelmet
• Eazfuscator.NET
• .NET Reactor
• {smartassembly}
• CliSecure
• CodeVeil
• dotNet Protector
• Dotfuscator for .NET
• Salamander .NET Obfuscator
• Skater .NET Obfuscator
• Spices.Obfuscator
• Xenocode

Some of the vendors' sites do include comparison charts but unfortunately I couldn't find "user-made" comparison charts. Thus, like usual we all end up in a "try the demo-before-you-buy" scenario to get the one that properly fills our needs for code protection.

BTW, the list above is meant to be as a "dynamic" reference, so if I happened to miss one obfuscator -sorry about that, just let me know and I add it to the list a.s.a.p.

Also, if you know well one/some of these apps -because you use or used it/them- and want to share your thoughts you're welcome to post your comments.

Hope this helps!

TIP: DEPLOYING GAMES TO THE 360 WITHOUT SHARING SOURCE CODE - PART II

In line with what he had explained for the matter, Stephen Styrchak has added some important information regarding obfuscation in general, and for the 360 platform in particular.

From Microsoft's forums: "Whether you want to obfuscate or not is completely up to your own discretion. It seems like a lot of people share the false impression that being able to decompile/disassemble binaries is a new thing that is possible with managed assemblies. It is not. It is just as easy to run a decompiler/disassembler on native binaries, and that technology has been around for decades.

That being said, yes, it will certainly work for assemblies compiled for the Xbox 360. Obfuscation is a post-compilation step that takes an assembly as input, and generates a new (obfuscated) assembly as output. The obfuscated assembly is functionally equivalent, but the instructions and functions have been rearranged in a way that makes it harder for humans to understand.

An obfuscated assembly is no different than an unobfuscated assembly in that it makes no difference to the JIT compiler and runtime if an assembly is obfuscated or not (which is why it will work on the Xbox 360). Similarly, assemblies for the 360 are not special assemblies; they are produced by the same C# compiler as the Windows assemblies -- so no special obfuscator is required to use on them.

Note that obfuscation just makes it harder to read disassembled assemblies, not impossible to read. With a more sophisticated disassembler, I believe you could effectively undo most of the obfuscation. You'll have to check with your obfuscation tool vendor to understand just how "secret" they can make your code. From my understanding of obfuscation, the efficacity also depends on the complexity of the software you are trying to obfuscate. That is, an algorithm in a single function will probably remain almost completely unchanged. However, an algorithm that requires dozens or more functions would be very well hidden. The trick is in hiding what functions are being called an what data is being passed around. The instructions doing the work (loops, branches, etc) are otherwise the same.

--Stephen"

Cheers!

TIP: DEPLOYING GAMES TO THE 360 WITHOUT SHARING SOURCE CODE

From Microsoft's forums (by Stephen Styrchak): "If you really want to share an Xbox 360 game without sharing the source, you can do it pretty easily. Just build your game into a DLL instead of an EXE (Game Library project). Then share a project with the source for the program entrypoint (main) that references your compiled assembly.

Basically, the project you have to share is the default Xbox 360 Game project with the Game1.cs file removed. The Game1 class should be defined in a separate DLL, which you can build from an Xbox 360 Game Library project. That way, the code in Program.cs will instantiate and invoke your game, which is implemented in another assembly.

You can develop the game using a multi-project solution and a project-to-project reference. But when it comes time to share it, just create a new Xbox 360 Game project and reference the already-compiled Game Library that holds all your game logic. Share that project (which is just a stub and contains no game logic), your compiled game assembly, and all the compiled assets.

This way, anyone with XNA Game Studio Express can use your shared project to build and deploy your game, without actually having the source for your game.
Although many people will encourage you to share your source as well, there are ways to show off your games and your creativity without giving everything away if you really, really don't want to.

Simpler methods are on the way. Just be patient.

--Stephen"

Some tip! But wait, if you can read between lines you may notice that something is cooking -even though no time frame has been revealed.

Please, tell me that an update pack for XNA is almost there ...

"... Just be patient ..."

Ok.