Thursday, February 01, 2007


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.




Lately, many of us have been worried because the 'Register' section of the Dream.Build.Play competition only shows one country: the US (and not all of the states).

Well, Dave Mitchell has confirmed that the D.B.P. is a global competition.

From Microsoft's forums: "The site is live and yes we realize there are a few things that haven't quite propped properly. We've got people looking to get these fixed asap.

To be clear, yes you will be able to register outside the US as this is a global competition. And yes, the missing states will be re-annexed shortly.

Apologies for the wrinkles in the rollout.

Just let's give the guys the due time to set up things properly, shall we?


Shawn Hargreaves has posted a technical article with relevant advice on how to debug and diagnose Direct3D-graphic calls both on Windows and XBox360.

From Shawn's post: "For debugging Xbox graphics you have to rely on less scientific techniques, such as tea leaves, entrails, or a visit to the local palm reader..."

Say no more, a must read ... ;)


By the time I publish this post, I guess this update is old news if you -like me- are suscribed to many XNA Community blogs.

The Dream.Build.Play website is being updated and in turn, relevant information is starting to be published. So far you will find information on some sections -like "Home", "About XNA" and "Register"- until the week of February 5th, 2007 when the rest of the information -like "Prizes" and "How to Play"- will be unveiled.

So, what's next? Just direct your browser to the site and start by registering if you want to get in the compo (what I assume you do).

And remember: "... Besides worldwidefame and recognition, you could also win some fantastic prizes!" (just show me the money! show me the money!)