Hi guys,
I am an indie developer.
I just wanted to know if anyone had an experience with the Amazon S3 bucket security.
The issue is I don’t want to expose my bundles as public.
Is there a workaround to keep the addressable bundles as private but accessable via code?
Couldn’t find a thread or post on internet.
Does Amazon SDK for Unity have a solution for this?
I would be grateful if you could help me with this issue.
Cheers
Fau
With S3, when you make your bundles public, that just means they are read-only to the public. You can only write to them with an authorized user. You should also use a CDN on top of S3 so no-one is going directly to S3. You might be able to keep them private and give your CDN authorization to access them, but I’m not sure if that’s possible (I don’t have enough experience with that) and I’m not sure what problem that would solve, either.
Why do you need your bundles to remain private?
@ProtoTerminator Thank you very much for the reply.
The motivation for keeping the bundle private is to shrink the surface exposed to the public access due to security concerns.
I don’t know the structure and encoding algorithm of a “bundle”, maybe there is a security breach and it could be reverse engineered.
Let me put it this way.
In a bundle virtually anything could be inserted right?
If the bundle is decoded, the inner structure of the code or maybe the inner workings of the logic could be reverse engineered.
Let’s make it concrete. Maybe there will be in a scenario I will have to put a critical manager prefab inside the bundle. Hope, I won’t be doing it. But let’s think for a second it happened and I had done such a terrible thing. 
As a result, in such a specific scenario a part or the general structure of the management system is exposed.
That’s why I am sceptic about using bundles without certain security measures.
At least I have to be able to tell myself that I have tried to make things harder for the possible attempt.
Shortly, as mentioned, my goal is to decrease the publicly exposed surface of the application thus keeping things relatively a bit preserved.
Thank you indeed for the reply.
Cheers
Fau
So, bundles do not contain any code or logic. They purely hold the structure of the data so that it can be built at runtime in the player. The player contains all of the code/logic. Any components on gameobjects are just stored as a guid reference to add those components while it’s being constructed. So if anyone gets ahold of your bundles outside of the application, all they will see is that it has a management script that will be attached to it (maybe not even that, possibly just the guid) and will not be able to see the code. Of course, if someone has the player (which they have to to be able to use it anyway), then they will be able to see all of your logic, and there’s no getting around that unless you store all of the logic on a server and the client is just a dumb renderer.
Hi Fau
I think you might be overthinking stuff a bit too much. Although security of your assets and code is certainly something to keep in mind, having your bundles being accessible from a server using a public URL in itself is not a big problem and is completely normal. Unity will download your bundles from a remote location using pretty standard HTTP(S) calls (it’s basically functioning a bit like a web browser). You can create your own protocols etc., but this will be most likely be wasted effort. Because as soon as someone downloads these bundles because they got your app running, they have access to it anyway…
You can’t open up bundles just using your file browser on your system, you need some advanced tools to open them up and extract content, and even if it was protected on a file-level, one could still run your app, have a look at what’s in memory and extract and save it out as well. It becomes increasingly difficult each step, but none of those are impossible if the ‘hacker’ wants it bad enough.
Your most precious asset is possibly your code, depending on which platform you build for, you have some options there. By default, your code is assembled in something called ‘intermediate language’, which is some flexible code that is able to run on a ton of systems. This code is pretty easily readable using tools such as ILSpy. To counter this, you have some options depending on the system you build for. For desktop systems such as Windows, mac and Linux, you can compile to IL2CPP, which translates your code to C++, which is compiled to native code for the platform you’re running on and is difficult to reverse engineer. One big downside of this approach is that you need to run the editor on each platform and make a build for that platform. You can’t compile the code on Windows to make it run on mac or Linux and vice versa. For consoles, you can depend on the platform that it keeps those files save from prying eyes. I’m not sure what the options on mobile phone devices and tablets are though.
If you find IL2CPP too big of a hassle, you can look into obfuscating your code. This basically takes the easy to read ‘intermediate language’ code, and just scrambles it with extra pieces of fake code and replaces all readable symbols with gibberish. In our codebase we use BeeByte Obfuscator and has some pretty cool options. In essence, all of our code is now compiled to double and single quotes, that is, for example: public class ''"''''""''''""''''"''''""''' : MonoBehaviour. Depending on the selected options, it can significantly increase build times though, but you can at least build for all platforms in the same editor instance.