Hi,
I want to protect my assemblies, but i receive error code 3 in xbox (there is no problem in Windows)
I have used this tools:

• Dotfuscator.
• Xenocode Post Build.
• DeployX Codeveil.

Can anyone show me a tool or a solution to protect the assemblies ?
Thanks in adv.

Why do you think you need to do this?

you don't need to protect your code on the xbox because you can't pull assemblies off the HD.  It's understandable for PC/Windows but for XBOX it's a waste of time since it's already pretty much under lock and key.

Jim Perry: Because i want to publish my .dll, but i want to protect the source code from unwanted eyes.
Aeon: Even if my project is not a single .dll, it is easy to unzip a .ccgame file and file the executable and of cource the source code.

Thanks for replies.

Don't take this the wrong way, but nobody wants your code :)


If the effort to protect your code is preventing it from running I'd say it's not worth it. Sure, someone could take your assemblies and open them in reflector or generate code from them, but they wouldn't know where to start understanding it. As stated above, if the Xbox is your target no one should be able to (legally) get your assemblies either. And Windows games can't talk to Xbox 360 games in production, so it's not like someone is going to get your development code and write a program to hack your game.

welcome to the land of managed code.  If you are releasing a .ccgame of a game you made for the xbox, unpacking it will run the XNA GS Device Connect.  If you unzip it, you don't get the dll's that you are talking about.  Unzipping my ccgame gave me files like "1, 2, 3, 4, 5, 6, XCabInfo.resources, etc" so there isn't a dll for people to "steal".  If you are releasing a windows dll, like I stated before, it's ok to obfuscate but for the xbox it's pointless as there isn't a way for people to steal your code.

You might want to take a look through these threads asking the same question. Pay special attention to some of the larger posters and guys from Microsoft offering their advice. Their years in the industry shouldn't shouldn't be taken lightly and their advice and comments should hold some weight for you.

Here's one of the threads and here's another.

You've already been given the same advice in this thread, but I figured it might help to see even more people chiming in explaining why this really is just wasted effort.

I think you are the 1st who has actually tried the products... the only major one you are missign is Salamander http://www.remotesoft.com/ - I'm not surprised they don't work. Many of them do odd things to the assemblies and the 360 usues a very special version of the compact framework which may not support all those odd things. Unless the product is tested for the 360 (and I've not seen one that is) then there's a good chance it will fail.

Aeon:

welcome to the land of managed code.  If you are releasing a .ccgame of a game you made for the xbox, unpacking it will run the XNA GS Device Connect.  If you unzip it, you don't get the dll's that you are talking about.  Unzipping my ccgame gave me files like "1, 2, 3, 4, 5, 6, XCabInfo.resources, etc" so there isn't a dll for people to "steal".  If you are releasing a windows dll, like I stated before, it's ok to obfuscate but for the xbox it's pointless as there isn't a way for people to steal your code.

Open XCAbInfo.Rresources in notepad interesting eh.... notice that there are the same number of nubmered files as were in your /bin directory and the file sizes are the same... use your keen powers of deduction and renaming skills to solve the problem..

Thanks George.

To Aeon: 0, 1, 2, ... files: one one them is the .dll, rename them one by one to .dll and then open them in Reflector.

Anyway thanks for replies.

I would expect Dotfuscator to work. Are you using it in combination with the other products, or by itself?

I'm a bit surprised more people don't try Dotfuscator for Xbox 360, frankly. Aside from obfuscation, the paid editions do optimization and inlining of functions that the C# compiler and the Xbox 360 JIT compiler don't do. For desktop applications, the C# compiler doesn't do them because the JIT compiler will, but in the Xbox 360 case, it doesn't. These are things that are widely lamented, and here's a product that claims to do it.

If you are using Dotfuscator by itself and getting an assembly that won't run, try using reflector or ildasm to check that no new dependencies have been added to the assembly manifest. You want all the references to still point to Xbox 360 assemblies only, otherwise there'll be trouble.

If you have a paid edition of Dotfuscator, you might check the docs to see if any of the optimizations they perform use stackalloc. That won't work on Xbox 360.

Stephen Styrchak:

I would expect Dotfuscator to work. Are you using it in combination with the other products, or by itself?

Have you guys tested it, or know someone who has? This is the 1st time we've seen someone in the forums actually try to use the tools - or admit to it anyway so beyond that there's no evidence of if they work or not.

I hadn't considered the optimsation advantages - thats a great tip.

When I said I expect it to work, I meant that is my personal expectation, not that it's a supported feature.

I do expect the community edition to work, but I haven't tried it myself. Based on the community edition's feature set, I don't expect it to result in invalid assemblies for Xbox 360. My dev manager asked me about it a long time back, and I told him I thought it would work, but someone needs to try it to be sure. Since he never came back to yell at me or tell me to fix it, I assume that what he tried worked. Simple test cases don't prove it will work in general, though, particularly when it's a product that produces vastly different results based on the inputs, but I'll see if he's around today to follow up. It's possible he was too busy and didn't try it at all.

Again, my expectation is that it should work, and I'd be very interested if it doesn't. It's something I would definitely try to fix.

Stephan, Your solution didn't work. as i wrote in my first post Dotfuscator didnt work. However, if it worked the result is not what i expect. i need to protect MSIL code not to obfuscate it.

There are lots of decompilers that detect obfuscation algorithms and generate compilable source code. also lot of tools that allow you to directly modify MSIL of the .dll.

i have used Codeveil for my windows applications before. when you load a codeveil protected assembly in Reflector, it says: "Invalid CLI header" and won't open it at all.

Anyway thank you very much and sorry for bringing an old message up. i set email subscription enable, but received no notifications.

Mahdi Khodadadi Fard:

Stephan, Your solution didn't work. as i wrote in my first post Dotfuscator didnt work. However, if it worked the result is not what i expect. i need to protect MSIL code not to obfuscate it.

Could you please clarify what you mean when you say you want to "protect" your MSIL code, but not obfuscate it?

If you aren't interested in obfuscation, then what are you trying to protect your code from? If you're trying to protect it from being made human-readable, and obfuscation isn't enough, then I'm afraid you're out of luck. Any code that is machine-readable can be made human-readable by a sufficiently sophisticated program.... And for your program to work, you need it to be machine-readable.

Stephen Styrchak:

Could you please clarify what you mean when you say you want to "protect" your MSIL code, but not obfuscate it?

Obfuscated (Human unreadable) code can be converted to readable code by tons of tools. however, even if the code is not readable one can modify it using say, Reflector's Reflexil plugin.

When you protect MSIL, no one/tool can access msil in your assembly and its metadata. even the unreadable code is not accessible.

Stephen Styrchak:

Any code that is machine-readable can be made human-readable by a sufficiently sophisticated program.... And for your program to work, you need it to be machine-readable.

In most cases least protection level is enough, at least it is not nothing.

Mahdi Khodadadi Fard:

When you protect MSIL, no one/tool can access msil in your assembly and its metadata. even the unreadable code is not accessible.

If your code is unabel to be read by a tool then the .Net framework won't be able to read it either and the app won't run.

Some of the obfuscators sill make changes to the IL so that other obfuscators will fail to read it but at the end ofthe day they can't change it to the point where its non MSIL - thats a standard. So no matter what you do ILDASM will be able to give you the IL.

Mahdi Khodadadi Fard:

When you protect MSIL, no one/tool can access msil in your assembly and its metadata. even the unreadable code is not accessible.

But this is not possible in software!  Think of the Desktop CLR as a "tool."  It must be able to read the MSIL and metadata in the assembly in order to compile it to x86/x64 code.  If it can read the assembly, then so can another tool, like Reflector.  The only reason code protection schemes work on such systems as the Xbox (with code encryption) is because there is hardware and dedicated memory to support it.

ShawMishrak:

Mahdi Khodadadi Fard:

When you protect MSIL, no one/tool can access msil in your assembly and its metadata. even the unreadable code is not accessible.

But this is not possible in software!  Think of the Desktop CLR as a "tool."  It must be able to read the MSIL and metadata in the assembly in order to compile it to x86/x64 code.  If it can read the assembly, then so can another tool, like Reflector.  The only reason code protection schemes work on such systems as the Xbox (with code encryption) is because there is hardware and dedicated memory to support it.

Well, it is possible... But it isn't what you or I would consider protection, and it won't work on Xbox 360 for obvious reasons.

http://www.xheo.com/products/codeveil/default.aspx

I looked up the CodeVeil tool he used as an example. The reason Reflector says the assembly doesn't have a valid CLI header is because it doesn't - it is actually a native image! The tool creates a native application with the MSIL assembly embedded as an encrypted resource. When executed, the native code decrypts the embedded assembly. The idea is that the MSIL is never unencrypted until runtime. Combined with copy-protection mechanisms, this native image serves to protect the underlying managed assembly.

This will clearly not work on Xbox 360 assemblies created with XNA Game Studio because Game Studio does not allow the use of native code on Xbox 360.

Stephen Styrchak:

I looked up the CodeVeil tool he used as an example. The reason Reflector says the assembly doesn't have a valid CLI header is because it doesn't - it is actually a native image! The tool creates a native application with the MSIL assembly embedded as an encrypted resource. When executed, the native code decrypts the embedded assembly. The idea is that the MSIL is never unencrypted until runtime. Combined with copy-protection mechanisms, this native image serves to protect the underlying managed assembly.

It is not a native dll, but a .net assembly and needs .net framework to run. protected assemblies even run on WinCE (with some corrections by hand) and i am completely sure it is not native (at least i have read The Common Language Infrastructure Annotated Standard book and wrote a compiler for my own .NET-Language as final university project, is this enough ?).

EDIT: if it is a native image with the assembly encrypted as a resource, we must not be able to add the dll to our projects/solution (like Win32 which we use DLLImport and we dont add it to references). also we must not be able to install the assembly to GAC. but we are. so we have a .net assembly.

Zman, even ILDASM is unable to decompile the assemlies.

Why don't you guys download free demo version of Codeveil and see it yourself ?

EDIT: I hope someone had found a solution to this, otherwise i'll be the first one ;)

BTW, why email notification on this forums doesn't work ?

Stephen Styrchak:

I looked up the CodeVeil tool he used as an example. The reason Reflector says the assembly doesn't have a valid CLI header is because it doesn't - it is actually a native image! The tool creates a native application with the MSIL assembly embedded as an encrypted resource. When executed, the native code decrypts the embedded assembly. The idea is that the MSIL is never unencrypted until runtime.

This is still just obfustication, though, rather than true protection.  In order for the executable to run at all, the executable must start with instructions that say how to decode it. Therefore, anyone who knows how to use reverse engineering tools can easily look at these instructions, see what they do, and repeat those same operations themselves to extract the original MSIL.

Sure, this will require an attacker to do a little more work before they can load the code into Reflector, but this isn't exactly a hard problem for any remotely experienced hacker to solve.

The only 100% sure way to protect your code is through the legal system. There is no such thing as a technical solution that cannot be worked around (assuming your program is valuable enough for anyone to want to bother).

What you are describing (and what CodeVeil does) is basically another interpreter layer on top of the .NET framework. It takes your assembly and encrypts it. When someone wants to run the assembly the CodeVeil interpreter steps in between the assembly and the .NET framework and does the decrypting as needed. From the docs "When the assembly is loaded the CodeVeil runtime-executive assumes control of portions of the .NET runtime and manages decrypting the MSIL as needed."

You can't do that on the Xbox. You cannot hook into the Xbox .NET framework and have it run your additional wrapper layer executive  instead of loading the assembly. Not using XNA, anyway. End of story.

Shawn Hargreaves:

Sure, this will require an attacker to do a little more work before they can load the code into Reflector, but this isn't exactly a hard problem for any remotely experienced hacker to solve.

The only 100% sure way to protect your code is through the legal system. There is no such thing as a technical solution that cannot be worked around (assuming your program is valuable enough for anyone to want to bother).

Hi Shawn,
Sometimes this is enough to stop an stupid hacker. look BitDefender 2009 (i mean 2009 not 2008 or 2007) is one of the best antiviruses in the world. but with 5 minutes of Reflector one can disable its license checker and use a free and unlimited version of it.

OK, lets this 5 minute be 5 days. at least we have stopped millions of hackers.

Mahdi Khodadadi Fard:

It is not a native dll, but a .net assembly and needs .net framework to run. protected assemblies even run on WinCE (with some corrections by hand) and i am completely sure it is not native (at least i have read The Common Language Infrastructure Annotated Standard book and wrote a compiler for my own .NET-Language as final university project, is this enough ?).

Here's a section of the marketing spiel from the website I linked to previously (right at the top, easy to find):

With DeployLX CodeVeil you can encrypt your .NET applications and DLLs. DeployLX CodeVeil adds native code to the assembly to decrypt the assembly just before the .NET runtime needs access to the data.

Whether you want to call it a managed assembly or not, it uses native code to decrypt the encrypted parts. You can't use native code on Xbox 360. Even if you could, this product does not generate native code that will run on an Xbox 360 CPU.

Stephen Styrchak:

Mahdi Khodadadi Fard:

It is not a native dll, but a .net assembly and needs .net framework to run. protected assemblies even run on WinCE (with some corrections by hand) and i am completely sure it is not native (at least i have read The Common Language Infrastructure Annotated Standard book and wrote a compiler for my own .NET-Language as final university project, is this enough ?).

Here's a section of the marketing spiel from the website I linked to previously (right at the top, easy to find):

With DeployLX CodeVeil you can encrypt your .NET applications and DLLs. DeployLX CodeVeil adds native code to the assembly to decrypt the assembly just before the .NET runtime needs access to the data.

Whether you want to call it a managed assembly or not, it uses native code to decrypt the encrypted parts. You can't use native code on Xbox 360. Even if you could, this product does not generate native code that will run on an Xbox 360 CPU.

Yes. However, Codeveil keeps Metadata unchanged so other assemblies can see its namescapes and classes. this is how assemblies run:

Native Code to copy MSIL on memory -> .NET Framework -> Run MSIL

Codeveil changes the assembly to this:
Native Code to decrypt MSIL on memory -> .NET Framework -> Run MSIL

And i need an equivalent for xbox.

I just found a tool: http://www.smartassembly.com/product/whatsnew.aspx they claim it works for xbox and zune as well.
sounds only paid versions work for xbox.

Looking forward ...