GP2X Simple Way To Protect Assets?


synkro

0xdeadbeef
Joined
Aug 26, 2003
Messages
823
Location
Germany
Website
Visit site
Hi There!

I use SDL to load my sprites form BMPs. Those are easily relpaced/altered. I need a simple way to prevent that. Any ideas?
 
You could calculate a hash of the files at runtime and compare them to previously stored values and complain if the images have been changed, but really, I would just let people fiddle with them - it is a hastle to stop it happening when really changing the images does no harm.
 
there are many ways..
you can get the latest sdl sources, patch loadbmp function and create your own gfx format..
or xor the bmp and xor back while loading.. etc..

synkro posted on Oct 7 2006 at 04:09 PM said:
Hi There!

I use SDL to load my sprites form BMPs. Those are easily relpaced/altered. I need a simple way to prevent that. Any ideas?
 
Last edited by a moderator:
Convert the bmp to a char* with bin2h or something, then use
Code:
SDL_RWops *rw = SDL_RWFromMem(bmp, filesize);
SDL_Surface *surface = SDL_LoadBMP_RW(rw, 1);
 
bin2h and use SDL RWOPS to laod it in memory...

but if someone _wants_ to get to them, they will no matter what you do...
 
Thanks guys! Nice ideas :)

Orkie posted on Oct 7 2006 at 05:57 PM said:
You could calculate a hash of the files at runtime and compare them to previously stored values and complain if the images have been changed, but really, I would just let people fiddle with them - it is a hastle to stop it happening when really changing the images does no harm.

I don't want perfect protection, just not that obvious. Because currently I am thinking about some kind of internet highscore system with passwords. I just want fair chances for everyone. Also I might ditch that idea (as I would need a site and input and enctryption system etc.) and go for a kind of "QUEST"-system.

woogal posted on Oct 7 2006 at 08:01 PM said:
Convert the bmp to a char* with bin2h or something, then use
Code:
SDL_RWops *rw = SDL_RWFromMem(bmp, filesize);
SDL_Surface *surface = SDL_LoadBMP_RW(rw, 1);

*hits fore head* yeah the simple ideas are still the best :)
 
Last edited by a moderator:
Well, you can make things harder. Security through obscurity only stops the inexperienced...

Start by XORing each byte before you write it to file, and then when loading into your engine XOR each byte using the same value. You can get clever with this and change the XOR mask for each byte, up to a finite or infinite length.

eg. You could add 1 to each XOR mask, or you could use your own key. eg. first = 1, second = 32, third = 55, fourth = 99, and repeat. Another nice idea is to XOR an image against another image (taking size into account and wrapping back to pixel 0 in the source image if needed) Make it as simple or as complex as you like. Also also mentioned in here earlier, you can hash and cross check stuff. Have a file that contains the hashes / checksums of each image and disallow anything that fails the checks. You can even mix up you bitmaps, either on a pixel by pixel basis or a scanline by scanline basis. First scanline could be left to right (pixel order), next could be right to left, using a different XOR mask or some other obscuritity system.

If you delve into ASM you could make use of ROR & ROL to rotate the bits on some pixel / scanline combinations. You can store checksums within the pixel data itself by subtly changing the first / last pixels in a bitmap to contain a 'watermark'. When I refer to bitmap, I don't mean a .bmp file which contains a bitmap header, I am talking about the raw image surface data. Another nice trick could be to 'bolt on your images onto the end of another valid file format. You can hide images within another file format if you know where to hide it. I believe if you write a valid bitmap file, and append your encrypted image to the end of the file, it would show as a bitmap but contain your image. I have to be honest, I haven't tried a bitmap myself this way, but I can't see why it wouldn't work. It sure as hell would confuse people when they view it and it's a different image to what it really contains...
 
You could go farther and add the images to the end of the executable - have an index at the very end... kind of like how self extracting zip files work. In fact, you might even be able to use a normal zip library to read out the data if you append an actual .zip.
 
by using read-modify-write procedures you one can easily enlarge the memory usage of a program, the decrypted version of the bitmap will have to be stored in anonymous ram pages (malloced, not mmaped, mem so anonymous pages will remain in memory if not accessed), in the other hand you can decrypt it (if the decrypt proccess is byte/character based) directly on the bitmap draw function (providing better security, saving ram but also wasting some cpu usage) over mmaped centent

best option would be integrating decryption and drawing in the same thing (saves ram, makes it more secure but a bit less cpu-hungry), but that will require a little more of patience to do imho..
 
Shikaku posted on Oct 8 2006 at 02:18 AM said:
The law of copying electronic data (in general):

If I can access it, I can copy it. End of story.

If I can hex edit well enough, I can probably change pictures as well.

So... your request is silly =)

More proof of concept, what your saying. Sure, If I paid for a small army to break into fort knox, it'd be possible, but it'd be a GIANT pain in the ass to do so. What he wants to know is how to make it harder for someone to get at it.
 
Last edited by a moderator:
Why would changing bmps affect the game mechanics, just keep you bounding boxes the same (You using sprite collision?) and the physics in the code, if someone changes the images, they will still paly in the same way but with different graphics.

If you want sprite collisions, why dont you encode the masks to the binary so if they change the sprite collision will be the same, so people can improve the gfx if they want but not to dramatically (keep the bounding box region you have specified.).
 
Back
Top