is it possible to hack/decode asset files?

is it possible to hack built asset files? i know in theory all encrypted files can be decrypted. is the algorithm a strong one? is there any way for us to choose the algorithm that unity uses for encrypting .asset files in the exe build or web player build? did anyone hacked these files before? many archiving formats like EA's big is hacked and can be modified now and it's a good idea to have the ability to change the encryption algorithm.

It's not a matter of the encryption algorithm, it's a matter of the decryption key being compromised the moment you distribute your game.

Suppose you determine that Unity is currently storing assets encrypted with ROT13. You decide you're going to plug in AES and encrypt all asset bundles with it. You now need to distribute your game to players. You've basically run into the same problem that DVD encryption runs into, which is:

  1. Your game needs to be able to access the assets.
  2. You need to put this game in the hands of players.
  3. The executable needs to have the key included to decrypt the encrypted assets.
  4. Anyone can dig into your application for the key.

Now, I'm doing it with a web-based game, you say. I'm not distributing an executable at any point, so I can distribute the key securely via https! That does not save you, for several reasons:

  1. You'd need the Unity plugin to support your asset encryption/decryption scheme.
  2. You're still sending the asset password over the wire, even if over https, so someone could pretend to be the Unity webplayer and just grab the key from you.
  3. If you were to convince Unity to do some sort of public-key approach where you can encrypt your asset password so that only the Unity webplayer can read it... well, now the Unity webplayer plugin needs to have their own private key stored somewhere, doesn't it? You're back at square one.

Even if you were to do something crazy, like having a .unity3d file server that responds solely to signed requests from the webplayer, and sends then a just-packaged copy encrypted with a one-time key agreed by both parties via something like Diffie-Hellman; do you really want to run that much computational expense on your server, knowing that at some point the webplayer will need to decrypt your assets in order to play them, which means they'll be decrypted somewhere in memory (and maybe the temp files or swamp)?

It doesn't seem to be worth it. Any approach that doesn't involve a trusted third-party server ( la having a Unity Certificate Authority) can be bypassed without that much grief, and the worst thing is that it only needs to be circumvented one and it's broken, forever.

I guarantee you that the reason because the film industry can't solve the problem is not because they're incompetent, but because it's not a trivial one, even when you have their pockets.

This gets hashed out on the forum from time to time. You can search there for details but the short answer is: "You're pretty safe from casual hackers/thieves but someone who is determined can steal from you". The question you have to ask yourself is "how big of a threat is this really?".

To my knowledge and as stated in the forums, there is no evidence that anyone had successfully open and decrypted the assets part of an Unity 3D package. It is not the same for the code, as it is based on .net and as everyone knows, .net can be opened and hacked in many ways. But so far, unless someone come with a demonstration that he did it successfully, it is not yet the case and your assets are protected.

Taking apart a .unity3d file is a pretty well documented exercise in the hacker community these days. Source code and assets to games are easily obtainable.

Use this software to pull out the DLL from the .unity3d package:

Use this software to dump the .NET MSIL code:

Rename .assets to .asset and then in Unity just import new asset to access all of the models, textures, etc. Not all assets are obtainable but most of them are.

Practically the best way to defeat this is not to have an unhackable encryption scheme, but rather one that gets updated frequently and changes constantly. If your game gets updates every week and the encryption scheme is changed each week, you make it very difficult and frustrating to keep hacked versions of your game from working. Typically in the industry, they are not concerned about files being ripped etc, but rather from players being able to cheat using known vulnerabilities usually by using bot programs/hacks made by actual hackers and distributed enmasse. The idea is not to prevent hacking altogether, but rather to prevent casual hacking or “click ‘hack’ button” hacking. If the person trying to hack your game knows their way in and out of low level pointers, c, and hex editors they’re going to get in, if they just know how to google search a wall hack and then download a program and run it, you can keep them out with frequent updates.