koobas.hobune.stream
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.
Please note that nothing is unhackable! It's only a matter of time. And the more you are trying to encrypt, the more someone will try to decrypt. Plus, none the less, everything can be reverse engineered. Like, models can be rebuilt polygon per polygon too, involves a lot of time again, but possible.
But how can I download the file.unity3d from webpage ?
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:
- Your game needs to be able to access the assets.
- You need to put this game in the hands of players.
- The executable needs to have the key included to decrypt the encrypted assets.
- 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:
- You'd need the Unity plugin to support your asset encryption/decryption scheme.
- 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.
- 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.
thank you ricardo! you are right but having multiple algorithms for encryptions and multiple keys can help us in some situations. at least a general viewer for all of our game archives can not be written. i use RC4, you use AEs and others use other algorithms. it's not completely safe but it's safer.
I appreciate this theoretical answer, but, just to be clear, are asset bundles (.unity3d) files encrypted in any way? I would suspect not. Is there a way to protect an aribtrary unity3d file that a user can download from being used in their Unity game?
Not the unity3d itself, as you would need to have your decryption code integrated with the webplayer for it to know how to open it. And not for the assets, since it needs to be able to get those as well. You could place the bulk of your code into an obfuscated DLL that your $$anonymous$$onoBehaviors then reference, but you can't obfuscate the $$anonymous$$onoBehaviors because Unity doesn't support having them in DLLs. All schemes will be defeated sooner or later (usually sooner), and they only need to be defeated one. Do you want to spend your time in a futile attempt to hide your assets, or making a game?
Thanks Ricardo. This is what I understand. Just to clarify I am less interested in protecting our code and more interested in protecting third party skeletons/meshes/materials that are encoded in asset bundle files. If the asset bundle has a fully skinned character (and you can get ahold of the bundle file), it is trivial to use it in your own Unity game.
Certainly Eric. But as it is Unity's engine that ends up decoding the resources, and as far as I know you can't plug hooks into either Resources.Load or Application.LoadLevel, that means you're at the mercy of however Unity encodes the assets. Do contact Unity, they may have a way, but I'm afraid that's the extend of what is evident from the API.
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?".
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: http://unity3d.netobf.com/Unity3dObfuscatorSetup.exe
Use this software to dump the .NET MSIL code: http://reflector.red-gate.com/download.aspx?TreatAsUpdate=1
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.
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.
