🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Encrypting or hiding your graphics?

Started by
7 comments, last by hplus0603 2 years, 7 months ago

Hello,

Quick question, because I'm not even sure what to search for. When small teams make their own sprites, what do they do to hide it from being accessed? I'm assuming some type of encrypting of the file or having it come out in your own format?

Any github examples, links, ect would be greatly appreciated.

Take care, thanks.

Advertisement

They requiere everyone to sign an NDA to not publish them!?

What do you mean by “Access”? If you're working on a public repo, you can't unless you make the repo private, if you're publishing them with your game, you can't as your game engine needs the sprites to be … well … used in the game ?

Putting effort into “hiding” assets is a waste of time unless you have really good experts in crypto and cyber security. Putting it into your own file format will work for usual gamers but hackers and data miners won't be stopped from analyzing your file, there are so many different file formats out there used in games and nearly all of them already have some tools to get the content out of them. All you can do is give a propper license and if someone contravenes it,you have to get a lawyer, that's live.

Some companies however perform some actions against modding their game for example, they use Asset compression along with some kind of crypto signature scheme like elliptic curves. This way, the game can verify that an Asset is unmodified but you still have to use a DRM protection to make sure the game itself isn't modified to simply skip the check

On the web, with javascript, you can generally hide a sprite sheet by processing it pixel by pixel into a canvas. PNG-JS can be used to do such.
You could have the base64 string, break it into pieces such as to not have it all in one obvious place, then process the pieces together to get each pixel, then apply each pixel one at a time to the canvas. This process keeps the image from showing up in devtools. In my tabageos library I've created the tabageos.loadSpriteSheetAndStart method that does all the above.

None

Tadstergames said:
On the web, with javascript

But you now that browsers like Firefox have debug tools and those tools reveal everything you load as a resource? You can't defacto hide something if you want to use it for rendering

@Shaarigan As I said, the process keeps the image from showing up in dev/debug tools.
I had posted a link with a working real life example for proof, but that was taken down.

None

You can certainly make it more difficult to find the assets in your games build, but not impossible. As long as the game itself is executed on the users PC, he could look at the sprites when they are loaded into the graphics-API like DX. Just don't let them lie around in the open so that anyone can stumble open them by opening a folder in the game. Just compress/package them with the tools of your game(engine) at your disposal, everything you do on top of that is not going to keep anyone who really wants to get your sprites from getting them.

In my own engine, textures are stored in a binary format that can be loaded into the graphics-API diretly for efficiency (thus you couldn't directly extract a file that is viewable in a programm without some additional engineering), plus assets are bundled in a custom binary package-format, and compressed afterwards. So you'd need to correctly undo the compressing, understand the binary format exactly, and then manually load the binary data with the right parameters. Thats enough to keep the average user from just copying the files; of course somebody with enough technical know-how could just reverse-engineer everything, but as I said, thats hardly avoidable.

There exist tools that can connect to the graphics card and suck the rendered asset right out of video RAM. There even exist virtual machines that let you pretend to the program as if it's not being debugged, and as if time is progressing, even when it's actually stopped in a debugger.

Because the user needs to be able to see the pictures, it is possible for software to “extract” the pictures.

My advice is to not sweat the small stuff. It's five orders of magnitude more important to make a fun game, that people want to play, than to try to keep your sprites from being “stolen.”

First: Anyone stealing sprites is highly unlikely to actually make a fun game that people want to play.

And, second, if they somehow DO make a successful game, based on sprites that they stole from you, then you can trust the copyright law and legal system to actually get rewarded from that in the end. But that's … just very, very, unlikely to ever be needed. “Asset rips” for actual games being sold and successful, are super rare. Focus your energy on the risks you can control, like “is my game easy to find, easy to install, easy to play, and fun?”

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement