Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Studio Chat / thinking of protecting my assets

Author
Message
haliop_New
User Banned
Posted: 26th Apr 2019 16:19
Came up with an Idea.
what if I take all of my assets lets say images, turn them into separate memblocks where each 3x3 pixels is randomized trough all the memblocks assigned for this by developer and the script that built the randomization is the script that will load it back up again only that it won't "save" or "export" these files to stay as valid files on android or Ios or even Windows... the memblocks will be saved into separate files and will be loaded up every new runTime, will create images on the fly.and perhaps rebuild the entire randomized memblock from time to time as the user plays the game so even if he finds a way to assume the x y and size of the image randomizations he will need to reconfigure it, when and where at the start of the downloaded application meaning the first time run will build and randomize all factory default randomization.

any thoughts?
would this work, is there a safer way?
any plugins for guarding our assets?
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 26th Apr 2019 18:03 Edited at: 26th Apr 2019 18:10
Certainly keep trying, you may come up with a nice custom option. However, I've experimented with a variety of approaches myself and have generally run into performance problems (especially when trying certain techniques on mobile devices) and/or excessive size issues. Consider that to save out to a memblock means you're basically writing out a bitmap which takes up an enormous amount of space compared to a lossless PNG. Sure, it/they can be zipped, but I've run into crashes/reliability problems trying to use the built-in ZIP operations on Android 8 devices (Google Pixel) for whatever reason(s) and you still can't extract individual files anyway, so you have to extract everything (either your memblocks or any other files), taking up more internal space and/or leaving the media open anyway.

Plugins can have their own issues. Some are only written for Windows and even then, often only for one bit format (ie 32-bit, rather than both 64 and 32). So you can sometimes only use them in a narrow scope of only one lone platform, which isn't good for a cross platform development system (where plugins should support, at least most of, the platforms the development system does). Plugins also need to be compiled correctly as well, otherwise they risk introducing unwanted dependencies that didn't previously exist for your game/app and require installing separate runtimes. So while a plugin could be an effective solution, it would need to be done within the operational conditions of AGKS itself to be very useful for much of the userbase, imo.

Asset protection should be something done internally by AGKS in the first place (as with other game development systems). It's on the request list ( https://github.com/TheGameCreators/AGK-Studio/issues/176 open for upvoting and commenting) and has been asked for going back to the early years of AppGameKit So hopefully, there will be an official implementation of some form of basic load-direct-to-memory asset protection option soon.
Takis76
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location: Greece
Posted: 26th Apr 2019 18:41 Edited at: 26th Apr 2019 18:46
In Blitzmax there is one library with name Koriolis ZipStream. You can read directly from inside a zip file and you set and password for this zip file too.

It uses functions like.

The file will be in zip format but you can use any kind of extension.
You can just zip your all data, including and not supporting data not only images, objects and sounds.
Then you call your images directly from inside the zip file.

The Application Game Kit code should be something like this.


I have uploaded the library source code which is in C (It was compiled with MinGW) and someone needs to port it to Application Game Kit.

And there is and another one library which creates zip files and your data files in this zip file and you lock them with password. The name of the library is zipEngine.
I have upload it too.

BUT. If you try to unzip the file which was created with this library even if you know the password with regular unzip or winzip programs it will present you an error.
But the library can restore your zip files correctly. Also if you load your data from the locked zips the data loads correctly in the program.

The Application Game Kit code should be like this.



If you see the source code you will see all functions.

Someone needs to port both of these libraries from C to Application Game Kit.
The current versions are for BlitzMax and C.

This should be nice for creating resource makers for your games or add your data on run time. I use these libraries to save and load my games and my data for my BlitzMax projects.

Attachments

Login to view attachments
fubarpk
Retired Moderator
19
Years of Service
User Offline
Joined: 11th Jan 2005
Playing: AGK is my friend
Posted: 26th Apr 2019 20:36
As nice as it would be to have the ability to protect assets
the safest way is to have your own method this would mean a decrypter would have to be specific for your game

From memory the shader pack includes asset protection

There is also several threads about protecting your media such as watermarks etc which wont show when you use them

at the bottom of this page uses a watermark and rot13 for protection there is also a method there by puzzler which does other media
https://forum.thegamecreators.com/thread/222027?page=1

fubarpk
fubarpk on Itch...………...https://fubarpk.itch.io/
fubarpk on googleplay..https://play.google.com/store/apps/developer?id=fubarpk
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 26th Apr 2019 20:51 Edited at: 26th Apr 2019 20:59
AppGameKit can unzip a password protected ZIP file already via built in commands. So this whole thing is a LOT easier then people think it is.

You simply

1) Put all you level assets in a standard password protected zip. Say "Assets.zip"
2) Change the extension just to discourage people from attempting to open it eve though its password protected ...So "Assets.dat" and place only this in the media folder that is shipped with your game
3) At the beginning of your level loading code, extract the password protected zip file to a temporary loaction in the write directory ....ExtractZip("Assets.dat","/temp","password") - and call setfolder() to read from this folder
3) Do your normal loading of images and these are automatically read from the write folder (instead of media folder) as its all built in to read from the write folder before attempting to find the file in the media folder.
4) Then delete the assets with multiple deletefile() and a single deletefolder("/temp") - I wont cover here how to iterate through a folder and delete each file but it is simple

So basically the files only exists on disk for a fraction of a second (while loading) and are deleted immediately after they are loaded. Zip->tempfiles...->deleted all in <0.5seconds

So instead of the normal coding practice

im = LoadImage("")
im2 = Loadimage("")
ob = LoadObject("")
etc...

You have to surround your loading with

ExtractZip("Assets.dat","/temp","Password")
im = LoadImage()
im2 = Loadimage()
ob = LoadObject("")
etc....
LIBDeleteFolder("/temp") <- where this iterates through your temp folder and deletes everything in it

I intentionally put the files in a "temp" folder so that save games or other written files can be kept in the write folder and are not deleted automatically.

Its not as perfect as loading directly from the zip, i would agree that..... but as the easily readable files (png,jpg,.3ds.fbx) are only available in a well hidden location for a fraction of a second then its not a problem and someone would find it pretty hard to get at the assets without knowing exactly how.

So...
Just write the folder delete function or just manually delete the files after you read each one in turn much easier then doing custom decryption.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 26th Apr 2019 22:31
Much of what is presented in the responses above illustrate why AppGameKit needs an internal asset management system. That is:

- Platform issues with AGKS' internal ZIP operations (Android 8).
- Problems associated with custom bit scrambling encryption methods within AGK/S (such as weak nested loop performance = long delays for media files of significant size - this was a show stopper for me writing my own).
- Doubling or more of used memory/storage space upon extraction (games with significant media could even risk an out of memory crash, leaving media exposed after such an event).
- Difficulty/impracticality for runtime media loading/swapping (without leaving media exposed at least).
- Excessive time delay in extracting an entire single massive ZIP archive.
- Global extraction exposing all media for however long or short a time.
- Lack of individual file access.

Part of my request for AES256 on GitHub incorporates one component of this potential objective. Some form of integrated archive bundle in any format with encryption that is loaded directly into memory would work.
Takis76
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location: Greece
Posted: 26th Apr 2019 23:15
Quote: "
Much of what is presented in the responses above illustrate why AppGameKit needs an internal asset management system. That is:

- Platform issues with AGKS' internal ZIP operations (Android 8).
- Problems associated with custom bit scrambling encryption methods within AGK/S (such as weak nested loop performance = long delays for media files of significant size - this was a show stopper for me writing my own).
- Doubling or more of used memory/storage space upon extraction (games with significant media could even risk an out of memory crash, leaving media exposed after such an event).
- Difficulty/impracticality for runtime media loading/swapping (without leaving media exposed at least).
- Excessive time delay in extracting an entire single massive ZIP archive.
- Global extraction exposing all media for however long or short a time.
- Lack of individual file access.

Part of my request for AES256 on GitHub incorporates one component of this potential objective. Some form of integrated archive bundle in any format with encryption that is loaded directly into memory would work.
"


That's exactly. Just unzipping a huge asset zip will take long time which is enough for someone to switch in the extracted folder of your game and copy them.
Even if you extract them one by one. Extract one, load one and delete one it will take longer time from just loading them directly from the zip file.
And why to extract everything from the zip and use only one when it will be needed? Do I will need to extract and delete everything each time I will need few to be loaded? Is silly.


The libraries I present do this but they need to be ported in Application Game Kit.
Dark Lord Beholder Project.
Role Playing Game like Lands of Lore 1 and Eye of the Beholder 2.
https://facebook.com/darklordbeholder

Takis76
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location: Greece
Posted: 26th Apr 2019 23:23 Edited at: 27th Apr 2019 00:10
I remember there was one library from DarkBasic Pro which did this, it loaded an image from a zip file without need to unzip everything.

I found some old DarkBasic Source code here and the plugin was about load images from block.



It seems the old DarkBasic Pro had more nice plugins.

I think the DarkBasic Pro Enhancement pack plugin had these functions. So the Game Creators could easy convert this plugin from DarkBasic Pro to Application Game Kit Studio. Both are Basic code.
Dark Lord Beholder Project.
Role Playing Game like Lands of Lore 1 and Eye of the Beholder 2.
https://facebook.com/darklordbeholder

Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 27th Apr 2019 00:23
Very nice write up, Bengismo. That is helpful. Thanks!
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 27th Apr 2019 00:57
Takis76 wrote: "I remember there was one library from DarkBasic Pro which did this, it loaded an image from a zip file without need to unzip everything.

I found some old DarkBasic Source code here and the plugin was about load images from block."


Indeed, I actually use(d) file blocks extensively for DBPro media. Fast, lean, encrypted (although older), and accessed files on-demand individually. Putting that kind of system together with AES256 as part of a project's compile options would be an excellent solution.
Takis76
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location: Greece
Posted: 27th Apr 2019 01:27
I am thinking to post a feature request in Github for the Game Creators to put this in the Application Game Kit Studio.
Dark Lord Beholder Project.
Role Playing Game like Lands of Lore 1 and Eye of the Beholder 2.
https://facebook.com/darklordbeholder

SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 27th Apr 2019 03:24
That, or you can add it in a post to my existing request for the same kind of thing at the link I posted above.
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 27th Apr 2019 12:09 Edited at: 27th Apr 2019 12:11
It is already possible in teir 2 to load a single file directly from a password protected zip into an image. You can call unzReadCurrentFile() and then loadPngImageFromMemory() to achieve what is being asked for above but these functions are not currently accessible via teir 1 and this method just covers PNG images when we would all want to be able to load ANY assets directly from a zip. PNG,JPG, GIF, and all 3d and sound formats.

I'm not sure how easy it is to use Assimp to load 3d objects directly from zip (I dont see any easy way from a quick glance at the source even via uncompressing to memory then loading into the engine) and the sound loading functions would also need to be adapted too. There would be a fairly large amount of changes to be able to support the direct loading from zip files looking at the current source files so it might be done but id imagine the vulkan update will be done way before anything like this. So....I doubt this will happen any time soon.
Takis76
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location: Greece
Posted: 27th Apr 2019 12:46
I posted a feature request in GitHub.
Dark Lord Beholder Project.
Role Playing Game like Lands of Lore 1 and Eye of the Beholder 2.
https://facebook.com/darklordbeholder

Login to post a reply

Server time is: 2024-04-18 18:05:59
Your offset time is: 2024-04-18 18:05:59