Media encryption for AGK:

This simplified version i came up with handles everything silently behind the scenes. All you have to do is put any of the files in your media directory into a password protected ZIP or .dat file. All the media files can be loaded directly from this file without being exposed on the drive (They aren't temporarily unpacked) - they are loaded directly from the .dat file into AGK. The file extension used can actually be anything you want it to be.

In this solution - Whenever you call ANY of AGK's load functions, the file you are after is first looked for inside the datafile and it will unpack it with the password before looking in the normal places (Write folder/read folder). This means you can still read from normal unprotected files as well if you wanted. All file types and load functions are supported with the exception of video files so far as I havent got round to that yet.

You can have multiple dat files (say...one for each level?) and specify which one to load from or select none at all. NO additional libraries are needed and its still teir 1 code but with ONE extra command that specifies the dat file to load from.

Its really simple and works quick. It can be applied to finished projects with little or no changes.

The sample zip contains a DEMO which is just an exe and a data file....Thats ALL....if you run it it loads up a ton of resources as a demo.

http://s000.tinyupload.com/?file_id=36717364772643172450



If this turns out to be something TGC and users thinks is a good idea I can upload it to github...

If this turns out to be something TGC and users thinks is a good idea

it's been a good idea for a long, long time thanks, Bengismo!

and, thanks for the BOOM in your demo. i was able to play along with the music = added bonus!

Amazing, you should contact TGC about this.

+1 Very handy.

+1 that's a great idea, imo media protection is way up there on the list of "kinda very important"

Thabk you! Checking this soon.

P.s

Now we just need to kill Bengismo he is the only one with free passage to our Assets.

What would you like for your last meal? Maybe a beer Icecream?

Benisgmo you are a

I recommend Begismo for a "Life Saver Badget"

And offer him the Purplish Thanos Fruit Heart Medal. As Bengismo.probably saved our assets (all of them execpt videos)

Nice! Even though it won't stop anyone from ripping your assets using the right tools.

The idea is to make it harder for people to rip assets and not to leave assets unprotected on the disc. Its how most distributions are made.

Even if someone gave me their data file i still cant open it without their password. Thats the whole point - it becomes unique to you.

Give this man A MEDAL !

This kind of thing can work, but it's not a great idea to leave the password agk#251&$lllio89 as raw string.

Yes, but ive intentionally done that...as there's no point in hiding it in a demo. All those assets are freely available so If i posted the original project they would be given out anyway.

Ive a single function that encrypts the password meaning that its not openly visible in the bytecode... I just didnt bother with it in this case of a demo.


EDIT:
Ive re-uploaded the original project but this time with the password encrypted in the bytecode file rather than openly readable....also the bytecode is not in the exe anymore just so you can easily get at it if you wanted to see if you could find the password. The password is in there but not in readable form and you would need to reverse it to get it.

Also...if you wanted to, anyone can put the bytecode into the exe in my version...just get a resource editor (resource hacker etc..) and add the byte code file (bytecode.byc) as RC_DATA called "BYTECODE" to the exe... and it works

The bytecode can be in the media folder or packed with the exe file - your choice. im not sure if I made that clear above.

ven if someone gave me their data file i still cant open it without their password. Thats the whole point - it becomes unique to you.

I get the idea and appreciate your work. Just want to say that the common tools out there don't care about what's on disc but just intercept the stuff on the way to the graphics card.

Of course, its fairly easy to get any graphics straight off the graphics card while it is running, intercepting opengl glTexture() commands is very easy ....same with directx ....doesn't matter how well it is protected on disk. This can be done for ANY pc AAA title if wanted. Same with memory sniffers to get sound resources etc...

As i said, its still just a case of not making it easy to do straight from files at least. it just looks unprofessional to have all your media in separate files in the media folder.

And that is really great! So thanks for that.

Have not checked it yet it will work on Android right?

So the idea is that it packed everything into one file then it read from that file and not open it on disc right ?

If so, i could potentially increase its securtiy.

On android, everything IS already placed in one file.... The .apk file holds everything including the exe, classes, runtime and resources etc...and it is technically a zip file but can be opened too.

What i am asking is, An APK is uncompressed when installed on an android. Right? Am i wrong?
So if it is uncompressed the zip file you present is as is right ? Then the bytecode interpreter is reading stright from that zip file.

Right ?
If so i can make a total headec to anyone who will trt to open it. Or even fetch the data stright from the gpu.

P.s

First thing i learned about the cyberspace is that if you have something password protected you should always create layers.

Meaning, you have one passworded zip file inside it you have about 2 more password protected and then you have another 10 protected zip files for the actuall stuff.

Thats just the first theory when it comes to layers.

Think about ti, if you have 3 different passwords to open your phone, it should be harder to crack not impossible just harder.

The only question i have is how fast does it unpack/load media compared to reading from raw files or extracting from zip, then loading large amounts of media? Otherwise, this should do well (while no one should expect it to be fully secure).

Well I have the comparison of loading direct from Password protected zip vs from files in the media folder...



about 8% slower to decrypt and unpack from a zip over a range of file various file types. (weirdly - some were quicker direct from a data file? - id have to repeat this more than 3 times to get accurate figures)


The ExtractZip() function in AppGameKit takes 0.367 Secs in my example case to extract the whole file so extracting all the files to disk then loading one by one would make the whole thing slowest by approx 65% - plus that doesnt include deleting these files after loading them.

From individual media: 100%
From password Zip: 108%
Extract all then load: 165%