It would be great if the new Addressables solution could incorporate a basic level of encryption on the asset bundles as they sit on the client PC. When a bundle is loaded, it would be decrypted before loading into memory. Maybe some hook for those who want the feature as I am sure this would have a minor performance hit.
As we are more concerned about PC-based asset security verses mobile, maybe the asset bundle package could have a flag showing encrypted or not. This way the developer could choose to encrypt only the PC-based bundle builds verses the mobile ones.
@Kirsche Of course, any data which can be decripted by client can be cracked. But making harder it is very important and works well.
I want to hooking method on building assetbundle, like OnAssetBundleSerialized(byte[ ] bytes), OnAssetBundleDeserialized(byte[ ] bytes) for custom encryption.
@Kirsche As a hoster of other people’s content withing our media, it our responsibility to try to prevent the asset from being cracked on the client. If someone does in fact crack the client, then they have violated US law and our company is no longer liable for the acts of a criminal.
I have a very reasonable objective (not trying to make something bullet proof to advanced hacking): just trying to prevent people from getting the assets by simply using a tool like uTinyRipper.
I really don’t agree encryption is something developers should have to roll themselves. Consider that every developer is potentially looking at a terms of service violation even for Unity Asset Store assets if assets are distributed in a manner that can be easily extracted. The addressables system is inducing developers to violate Unity’s own agreement.
It’s absolutely bizarre that it seems reasonable that tens of thousands of developers should all independently create exactly the same encryption script. The whole point of a game engine is to absorb the common tasks so everybody doesn’t have to build their own roads to drive on.
Asset bundles should have basic encryption baked in. Unreal has this. It’s probably just AES-256 with a pre-shared key. It’s encrypted when packing, decrypted when unpacking, with a key that’s baked into the project. It’s transparent to the developer. Just create a key, click a checkbox, and you’re done.
Bill, I think you’re a smart guy, but your rationale for why every single developer should duplicate this effort is wild.
You are reading too much into the terms and conditions.
Most AAA games don’t have their assets encrypted, you can generally just extract them.
“Exposing” assets to extraction by having them in asset bundles or built in game data (remember, those are not encrypted either) does not open you up to these clauses. Chucking them on the customer’s drive as png and fbx or what not would.
Also remember that let’s say for the sake of argument you encrypt them, if you use Mono decompiling your code back to C# and even debugging your symbol-less release build is entirely trivial with dnSpy and the like, so extracting your keys is just going to happen. Even if you use IL2CPP, it would not be difficult for someone to extract your decryption keys, people do.
To reiterate: practically every Unity game in existence that uses third party assets would be violating the T&C’s in this case.
Indeed, you’re probably not in violation of the terms of service. I’m only interested in increasing the level of skill needed to extract the assets, and it’s not black and white. Someone who can extract unencrypted assets might not have the skills to decompile and locate a key, and it’s not certain the key is even in the binary. I’m not trying to protect against a nation-state attack, only casual extraction using off-the-shelf tools. Unreal Engine does provide this.
But I guess the correct standard for enough obfuscation is that it should be more difficult to extract the asset than to obtain a torrent of the same asset in its original form.
It’s using compression anyways, most of those libraries have an encrypt option builtin, tick box, password. Done.
Just another step in loading. Maybe it’s a speed concern, not every application is going to care though.
Because return for investment is very low. Why waste your time and making things difficult for you and your team by adding another layer that you need to maintain and worry about.
It is perfectly valid reason to wanting to discourage malicious activities and you should if you have the means for it. However, anyone with enough motivation and determination (e.g. steal or reverse engineer your product for financial gain) WILL get to your data. Most (I am going to say 99.99%) other developers don’t bother with trying to sort through your garbage and figure out how your app works and try to steel it. They would just play your game and make something better. Yes, we definitely copy/paste code, but we don’t copy and paste applications :p.
If its like a multiplayer game and all it takes is checking one box (encrypt) and entering a key somewhere I’d do that to deter hackers and cheaters (ironically they will still figure out ways). And maybe invest more time architecting anti-cheat systems. But if it is a single player game I could careless if some kid tries to tinker with my game.
I think, best way to “protect” yourself is by making new content and continuously updating existing content.
I not a lawyer and maybe someone from Unity should clarify, but I think what they mean is don’t just leave it as a unity package outside of you bundles or as raw files (Textures, FBX, audio etc…) so all it takes is just opening your folder.
Aaand again - push.
It’s - at the moment - really ridiculously easy to extract all assets, textures, scripts from the content bundles.
On the other hand - browsers made it increasingly more difficult to grab/rip assets while they run onscreen. So while the whole “just grab mashes from gpu-memory” gets increasingly safer…the content itself from a unity application can simply be downloaded…