Jump to content


Photo

External Sprites. Preventing users from accessing.


  • Please log in to reply
17 replies to this topic

#1 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 13 May 2012 - 07:34 PM

Hello.

So I know this has been asked a million times but hear me out. Firstly, I have searched around for a DLL that will do the job but haven't had much luck with the ones that I found.

1) Ultracrypt DLL: This dll worked fine. But it had two problems. One, it could only encrypt individual files, not a whole set of them. Two, after decrypting and running the sprite in the game, they become vulnerable since the user could just minimize the GM window and access the sprites while the game was running. People also said that this was better than the Supercrypt dll which I have not tried though.

2) TARC DLL: The download link was dead. PMed the author but no reply yet.

3) Revel's Cypher DLL: This dll used packaging for sprites. It was great but there was just one problem: there was no command or function to actually use the sprites in a package file. Plus I had some other queries about the DLL which were not given since there was no documentation. Again, PMed the author but no reply.

There are some other DLLs out there but people supposedly say that the above are the best. Yet, they are not working out for me.

On to what I actually hope for:

I am not too concerned with encryption of external sprites. What I basically want is that the external sprites should be present in the game package in such a way so as to discourage the user from accessing them. Simply having the sprite folders in the package with 0 protection will allow the user to see the content and access it. This is essentially what I would like to avoid and not protection from ripping per se.

I've read on some other alternatives like changing file extensions and the like but those giving such suggestions never really elaborate.

Is there any way to provide some protection but more importantly, ways of preventing users from accessing and viewing the external sprites?

Thanks for any kind of help.

Edited by Energy Engine, 13 May 2012 - 07:37 PM.

  • 0

#2 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 16788 posts
  • Version:GM:Studio

Posted 13 May 2012 - 07:56 PM

If you are using GM8 or 8.1 then you can save the sprite from the IDE as a *.gmspr. This effectively renders it encrypted to anyone without a copy of gm to open them and they can easily be loaded into a game at runtime with :


sprite_add_sprite(fname);

I know this may not be the ideal solution, but I remember looking for just what you are wanting a good while back and coming to the same conclusions as you... No dll exists that gives decent functionality in this respect!

  • 0

#3 kburkhart84

kburkhart84

    GMC Member

  • GMC Member
  • 1605 posts
  • Version:GM:Studio

Posted 13 May 2012 - 08:15 PM

What about my kbzip extension? It isn't the best, but it's pretty simple and I would say does the job. It also allows for "packs" of sprites to be loaded and unloaded into variables, global or not. It doesn't have encryption, but you can name the files however you feel like, so even though they are zips, at the least they don't directly look like it.

One method allows you to put whatever files you want, and then you would extract a file, load it, and then delete the extracted file, and there is no time for the player to do anything with it because the file is gone by then. This could be used for anything you need externally.

The second method allows for sprites and backgrounds to be loaded from "packs" that internally work the same as the above method, but all automatic. It only uses GM's file formats(*.gmspr/*.gmbck) though because that allows the sprites properties to have already been defined.
  • 0

#4 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 13 May 2012 - 08:24 PM

Thanks for the reply. :happy:

Well.... that is unfortunate. I'll be releasing a Beta WIP of my game real soon. So I guess it won't matter too much if people can see the sprites. Hopefully though, a DLL which does what we need will be out before the final version of the game...

As for the encryption, using GM 8/8.1 sounds like a good idea. Might try that.
And with the amount of sprites I use at any given time and the decryption process all combined would slow the game down anyway. Guess I'll have to use the good ol' license/permission thing. :biggrin:

Still, if anyone has any more suggestions, I'd like to hear them.

Thanks again.

EDIT: Posted a few minutes after kbhurkart's post.

Thanks for the reply kbhurkhart. I'll try your extension and will post back feedback. :biggrin: One thing I just remembered though. I actually did try using your ext but the link was dead... :tongue:

Edited by Energy Engine, 13 May 2012 - 08:28 PM.

  • 0

#5 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 16788 posts
  • Version:GM:Studio

Posted 13 May 2012 - 08:28 PM

What about my kbzip extension? <SNIP>


Now why haven't I seen that before? That's a handy little extension you have there for those that use 8 and 8.1. Good job!

PS: Link worked for me.



  • 0

#6 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 13 May 2012 - 09:42 PM

Nocturne, I was talking about the link not working during my search. :tongue:
It is working fine now.

Okay, finally got hold of a friend's GM 8 Standard edition. Tried the extension and appears to be very nice but I'm having an issue that hopefully KB can respond to. How exactly does one use the sprite_index to run a sprite with the kbzipLoadSprite function?

Firstly, just created a mock archive and gave it some random extension (file.tr). This contains a single gmspr. This was named as "br" in the graphics archive tool.

Next, I have this:

Create Event:

test=kbzipLoadSprite("file.tr","br.gmspr")

enter key press event:

sprite_index=test

However, I just get a blank screen. What am I doing wrong? (btw, the package 'file.tr' is in the same directory as the Gm save file so there should be no directory issues.)

Thanks for the help. ;)
  • 0

#7 dannyjenn

dannyjenn

    GMC Member

  • GMC Member
  • 2041 posts
  • Version:Mac

Posted 14 May 2012 - 12:30 AM

Still, if anyone has any more suggestions, I'd like to hear them.

You could have Game Maker make a copy of the encrypted files, and have it create the copy in some other directory which has nothing to do with your game, such as the temporary internet files folder or even a temporary folder created just for this purpose.
Then use the Ultracrypt DLL to decryt the duplicate files while the game is being run and have the duplicates encrypted again and deleted entirely as soon as possible.

That would make it more likely that the player won't have access to them... he could minimize the game but the original files (which have never been decrypted) would not be able to be opened. While he could always stumble across the duplicates (which he then could open), it's not very likely that it would happen on accident. He'd have to be looking for them, and if you don't give them obvious filenames then it would be difficult for him to find them without some sort of tool or without knowledge of their location.
  • 0

#8 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 14 May 2012 - 01:28 AM

thanks for the reply danny. :)

That is a good suggestion.

But a few things. Would game maker have to create duplicates every time it runs? Would it be feasible with the game's loading (there are lots of sprites, each of which are gifs)? Also, there is the issue of having all the sprite files getting encrypted. Ultracrypt only does one file at a time, not an entire directory, right? If not, then how would it be done?

I'll keep your suggestion in mind but would like to know about these issues.

In the meantime, I am still waiting for KB to inform me on how the sprite_index function will work.

Thanks for the help.
  • 0

#9 dannyjenn

dannyjenn

    GMC Member

  • GMC Member
  • 2041 posts
  • Version:Mac

Posted 14 May 2012 - 02:21 AM

The loading could be a problem... not sure how fast Game Maker could handle copying multiple files (especially if the files are pretty big). However, you might be able to space it out a little... load only the ones needed for the first room in the beginning, then while the player is in the first room (playing the game) then have an object running in the background loading sprites for later rooms, etc. Not sure if that would create any lag or anything though...
As for encrypting more than one file at once... not sure about that either (I've never used that DLL). Couldn't you just repeat the encryption function several times? Or are you thinking that that could slow the game down?
  • 0

#10 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 14 May 2012 - 03:11 AM

Yes. The loading times... that's what I was afraid of... :confused:

Also, the thing with ultracrypt is that it doesn't actually check whether a file is encrypted or not. It basically does a encrypt/decrypt type function. If it is encrypted, it decrypts. If it is decrypted, it encrypts. No checking in-between. This can problematic since I'm using a particular number of sprites in a particular part and deleting them when not needed. Ultracrypt could probably have issues with that. Otherwise, it encrypts very nicely.

Still, my thanks for that suggestion dannyjenn. I will definitely keep it in mind and might have a need for it sooner or later. :biggrin:

The best solution I think would be using a pack system where the sprites are packed into a file type and only the DLL could read that packed file type (since that is what creates it in the first place). I saw revel's Cypher engine and now Kburkhart's kbzip, both of which use this system.

Unfortunately, the ONLY problem, I'm having which has thus far prevented me from testing their DLLs, is that there are no instructions pertaining to HOW one could use the sprites in the created pack files using game maker's sprite_index function. I tried PMing revel but did not get any reply from him. And with kburkhart.... hopefully a reply will come soon... :mellow:
  • 0

#11 kburkhart84

kburkhart84

    GMC Member

  • GMC Member
  • 1605 posts
  • Version:GM:Studio

Posted 14 May 2012 - 05:30 AM

Yes. The loading times... that's what I was afraid of... :confused:

Also, the thing with ultracrypt is that it doesn't actually check whether a file is encrypted or not. It basically does a encrypt/decrypt type function. If it is encrypted, it decrypts. If it is decrypted, it encrypts. No checking in-between. This can problematic since I'm using a particular number of sprites in a particular part and deleting them when not needed. Ultracrypt could probably have issues with that. Otherwise, it encrypts very nicely.

Still, my thanks for that suggestion dannyjenn. I will definitely keep it in mind and might have a need for it sooner or later. :biggrin:

The best solution I think would be using a pack system where the sprites are packed into a file type and only the DLL could read that packed file type (since that is what creates it in the first place). I saw revel's Cypher engine and now Kburkhart's kbzip, both of which use this system.

Unfortunately, the ONLY problem, I'm having which has thus far prevented me from testing their DLLs, is that there are no instructions pertaining to HOW one could use the sprites in the created pack files using game maker's sprite_index function. I tried PMing revel but did not get any reply from him. And with kburkhart.... hopefully a reply will come soon... :mellow:


I just got home from work...

I'm not fully sure what the situation is with you using my extension, but I'm guessing you aren't giving the full file path. My extension(and other dlls/extensions) don't always attempt to work based off of the current "working directory" so you have to provide that to the functions as part of the file name. The easiest way is to use either variable between program_directory and working_directory. In fact, I would put one in a constant so that it never changes. The working directory can change if your game ever uses file accessing functions, so you want to somehow store the directory when you start, and don't forget the slash after the "working_directory" because it doesn't include it.

Also, for your testing object, try assigning a test sprite to it, and then see if it shows the first sprite. If it doesn't, the error happens before you ever try to set the sprite from my extension function. It's a long shot, but worth a try.

If you can't figure it out, you can PM me, or post in the kbzip topic. Also, if you try the directory part and it doesn't work, you could upload your project(or email it to me if you want) and I'll take a looksy.

@Nocturne-if you are looking anyway...

Yeah, the only reason I haven't really tried much to add features is because I'm focusing on GMStudio and cross-platform dev, which makes my extension somewhat useless. Also, it will end up fully obsolete as GM advances because they may make a similar integrated feature, or the speed will no longer warrant loading anything externally.

EDIT** My extension does have a .chm file that explains the functions in detail.

Edited by kburkhart84, 14 May 2012 - 05:34 AM.

  • 0

#12 wickedsunny

wickedsunny

    GMC Member

  • GMC Member
  • 128 posts
  • Version:Unknown

Posted 14 May 2012 - 05:39 AM

If you are using GM8 or 8.1 then you can save the sprite from the IDE as a *.gmspr. This effectively renders it encrypted to anyone without a copy of gm to open them and they can easily be loaded into a game at runtime with :


sprite_add_sprite(fname);

I know this may not be the ideal solution, but I remember looking for just what you are wanting a good while back and coming to the same conclusions as you... No dll exists that gives decent functionality in this respect!


Nocturne

I am already reaching a point where I will require to put my head in encrypting for my game.

Where to use this code. like when the room starts or game starts? Should I add an invisible controller and add this?

For every individual sprite do I need to use this code?
  • 0

#13 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 14 May 2012 - 07:58 AM

First of all, I have to ask; does the kbzipLoadSprite function work similar to game maker's own sprite_add function? Because if I use either sprite_add(fname,bla,x,y, ... ect) or simply sprite_add_sprite("br.gmspr"), both work fine. So I'm quite certain there is no issue with the directory unless I'm missing something required specifically for your extension.

Also, doesn't your dll 'pack' sprites into a pack file and then allows game maker to load the sprites that are in that pack file? I would simply pack all the sprites first then when I was to make the game available to others, the sprite resources would come to them 'packed' instead of being open folders with easy access. Is this not how it is to be done?

If so, the last part I need help with is how to actually use the sprites that are in the pack. I assumed we'd simply do it like we would normally do it when loading sprites externally, i.e, attach the loading function to a variable then link that variable with the sprite_index function. There is a sound dll called FMod. I load the sounds externally the same way but instead of using Game Maker's sound_play function, FMod has its own function to play loaded sounds. I was thinking maybe your extension may have a similar function for running the sprites, like kbzipSpriteIndex or something but I didn't find anything.

In short, I am asking, after creating a pack file with the sprites using your Graphics Archive Creator, how one could use the sprites in that pack file in Game Maker.

Some instructions maybe?
  • 0

#14 kburkhart84

kburkhart84

    GMC Member

  • GMC Member
  • 1605 posts
  • Version:GM:Studio

Posted 14 May 2012 - 03:05 PM

First of all, I have to ask; does the kbzipLoadSprite function work similar to game maker's own sprite_add function? Because if I use either sprite_add(fname,bla,x,y, ... ect) or simply sprite_add_sprite("br.gmspr"), both work fine. So I'm quite certain there is no issue with the directory unless I'm missing something required specifically for your extension.

Also, doesn't your dll 'pack' sprites into a pack file and then allows game maker to load the sprites that are in that pack file? I would simply pack all the sprites first then when I was to make the game available to others, the sprite resources would come to them 'packed' instead of being open folders with easy access. Is this not how it is to be done?

If so, the last part I need help with is how to actually use the sprites that are in the pack. I assumed we'd simply do it like we would normally do it when loading sprites externally, i.e, attach the loading function to a variable then link that variable with the sprite_index function. There is a sound dll called FMod. I load the sounds externally the same way but instead of using Game Maker's sound_play function, FMod has its own function to play loaded sounds. I was thinking maybe your extension may have a similar function for running the sprites, like kbzipSpriteIndex or something but I didn't find anything.

In short, I am asking, after creating a pack file with the sprites using your Graphics Archive Creator, how one could use the sprites in that pack file in Game Maker.

Some instructions maybe?


In the download of the extension there is a help file included. I was never able to get the help file as part of the extension file(to integrate with GM's IDE) but the help file is there in the zip file that you downloaded to get the extension.

In said help file, I put for the loading functions that you have to put the full filepath, which would include directories. I'm guessing that I ran into the same issue and so that was the fix, hence the statement in my help file. Also, the current working directory can change for a number of reasons, so you can't depend on it.

About the sprite "packs," that is the easiest way to do it. You saw the external programs. Notice how with the one for the sprite packs, it makes you choose a variable. For simplicity, I would put the "global." in front of all of them. Then when you call kbzipLoadArchive("fullpathtoarchivefile"), and then you access sprites like "global.nameofspriteIChose". The method for doing them individually also should work, but as I said, you have to provide the full path to the files, because the zip API I'm using doesn't know about the working directory like some do.

Also, just FYI, pretty much every function returns a -1 value if for some reason it didn't work right, so check the returns to confirm if things aren't working. The individual loading functions return either -1 or whatever the sprite index is(that you put into the variable) and the full pack loading function returns -1 if unsuccessful, and 0 if successful.
  • 0

#15 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 14 May 2012 - 08:26 PM

Thanks for the reply. :thumbsup:

I'm still having problems though. I checked debug mode and you are right, the variable is showing as -1. Problem is, whatever I do, it doesn't fix it. I tried the working directory also but still no luck. I will post the gmk and maybe you can see what the problem is? :confused:

http://www.2shared.c...uRaOk/Test.html

I would really like to know what I am doing wrong here. :wacko:
  • 0

#16 kburkhart84

kburkhart84

    GMC Member

  • GMC Member
  • 1605 posts
  • Version:GM:Studio

Posted 14 May 2012 - 09:08 PM

Thanks for the reply. :thumbsup:

I'm still having problems though. I checked debug mode and you are right, the variable is showing as -1. Problem is, whatever I do, it doesn't fix it. I tried the working directory also but still no luck. I will post the gmk and maybe you can see what the problem is? :confused:

http://www.2shared.com/file/QR-uRaOk/Test.html

I would really like to know what I am doing wrong here. :wacko:


By your test, it seems to be working just fine. I outputted the test variable right after the loadArchive function call in the create event, and it is '0', which means the function was a success. Then I tried it pressing enter first, and then down, and suddenly is see the "cityscape" sprite you have there.

I think your mistake is in using it. For the archive one that creates the packs, you have to specify a variable in the actual archive creator. You specify the filename,and the variable. I don't see any global variables, and I didn't see any additional local variables either on the 'a' object, so I'm guessing you didn't do that part. But then the 'enter' event makes the test variable into the sprite index loaded directly, and the down event changes the sprite_index into that one, and that part works fine.

Question...are you by change not on WinXP or later? A user had posted in the extension topic that it wasn't working in Win2k but that it worked in WinXP fine for him.
  • 0

#17 Energy Engine

Energy Engine

    GMC Member

  • New Member
  • 156 posts

Posted 14 May 2012 - 10:25 PM

Interesting... at least there is assurance that it works.

I am using Windows 7 32 bit (x86). I hope this will not cause it to not work. :confused:

Also, did you make any changes to the gmk I have provided?

You have said:

I think your mistake is in using it. For the archive one that creates the packs, you have to specify a variable in the actual archive creator. You specify the filename,and the variable. I don't see any global variables, and I didn't see any additional local variables either on the 'a' object, so I'm guessing you didn't do that part. But then the 'enter' event makes the test variable into the sprite index loaded directly, and the down event changes the sprite_index into that one, and that part works fine.


I could use a global variable. But what do you mean by "any additional local variables" on the 'a' object? What other variables would it need?

Like I've said, have you made any kind of changes? If yes, please let me know so I know what the problem is.

Thanks for the help. :biggrin:

EDIT: ha ha ... victory. :biggrin:

Found the problem. Didn't realize that the variable assigned in the Graphics archive creator was supposed to be the SAME as the one we had to assign in game maker. I was constantly using "test" as the variable while it should have actually been "br" (the variable assigned in the creator). Can't believe I overlooked this.

Thanks for all the help people and thanks kburkhart84 for suggesting your dll and making it available for download.

I'm going to post this important but easily overlooked issue in your thread. Is that fine by you?

Edited by Energy Engine, 14 May 2012 - 10:40 PM.

  • 0

#18 kburkhart84

kburkhart84

    GMC Member

  • GMC Member
  • 1605 posts
  • Version:GM:Studio

Posted 15 May 2012 - 02:14 AM

Interesting... at least there is assurance that it works.

I am using Windows 7 32 bit (x86). I hope this will not cause it to not work. :confused:

Also, did you make any changes to the gmk I have provided?

You have said:

I think your mistake is in using it. For the archive one that creates the packs, you have to specify a variable in the actual archive creator. You specify the filename,and the variable. I don't see any global variables, and I didn't see any additional local variables either on the 'a' object, so I'm guessing you didn't do that part. But then the 'enter' event makes the test variable into the sprite index loaded directly, and the down event changes the sprite_index into that one, and that part works fine.


I could use a global variable. But what do you mean by "any additional local variables" on the 'a' object? What other variables would it need?

Like I've said, have you made any kind of changes? If yes, please let me know so I know what the problem is.

Thanks for the help. :biggrin:

EDIT: ha ha ... victory. :biggrin:

Found the problem. Didn't realize that the variable assigned in the Graphics archive creator was supposed to be the SAME as the one we had to assign in game maker. I was constantly using "test" as the variable while it should have actually been "br" (the variable assigned in the creator). Can't believe I overlooked this.

Thanks for all the help people and thanks kburkhart84 for suggesting your dll and making it available for download.

I'm going to post this important but easily overlooked issue in your thread. Is that fine by you?


I'm glad you figured it out. You don't have to use globals, but you can if it is easier. If you don't, then the variables will be local to whatever object is calling the functions.

Sure, you can post the fix to my topic as well.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users