Resource files

Hi djkarstenv,

I don’t know if a resource DLL will help you terribly much when hiding images. If you have a player who has visual studio, they can extract the resources from it anyway, modify them, build another DLL and save it over the top of yours.

If you do want to go down this path, building a resource DLL limits you to only being able to use Windows - I’m not sure if there are Linux/other OS equivalents.

I know of some games that don’t bother hiding images from the user. One example is Sid Meier’s Alpha Centauri, where the game is extendable by adding a new “faction”, and you need to create a bitmap with a specific layout in order for it to load properly.

Some others hide by using pre-defined library resource types (thinking of some notable FPS game engines). If you go to the SDL library page (http://www.libsdl.org/libraries.php), you’ll see the first entry to show up is a 3DS parser (if you’ve got access to Autodesk software, if not, I’m not sure what free/cheap options there are for generating 3ds files and I haven’t searched).

Alternately, you could just have everything packaged up into an encrypted zip file of some kind and perhaps use an archive library to extract the stuff you need? (see http://www.freeprogrammingresources.com/complib.html for some libraries you may be able to use)

HTH,
-J

If you’re using C++, I just noticed that the boost library’s IOSTREAMS library supports compression and encryption on standard streams, see http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/home.html for the 1.47.0 version.

If you’re willing to spend some time and effort on it, you can build
an ‘in-app’ file system, and store each actual resource as a static
array; that should hopefully hide them from anyone that doesn’t know
what the file type’s magic numbers look like: with encryption, this
can be made to work even better.

If you compress the files you can use sdlrwops or some library like physfs to load ressources from the archive. And compressing might actually improve loading times.
But encrypting is totally useless it wastes processor cycles for a false sense of security and since your application requires the key to unencrypt them every user can look into the .exe and find out what the key is.
And even using a private key for encryption and a public key for decryption is time that you could better spend elsewhere. What stops the user from modifying your binary and insert his own key.

thanks for all ur input guys i will give it all a shot :slight_smile:

On the topic of embedded files, my advice is to make a zip archive, stick it on the end of the exe and load it from there - this is easy because opening your own exe file and scanning back from the
end a bit finds the end of central directory data, which has the offset to the beginning of the central directory (file listing) and just seek back to there and begin parsing it.

Note however that tools like unzip and winzip and so on are more than happy to identify exactly such an exe and extract the zip on the end, they think of it as a self-extractor (as that is how they
are made).

Data hiding is futile in any case.

On the plus side as Cristoph points out, loading data from a zip is generally faster than from raw files on disk, for a couple of reasons - 1. the files are packed together (no empty space between
them) which means file cache is better utilized (rather than rounding up to the cluster size), 2. the zlib inflate algorithm is one of the most finely tuned algorithms out there, and comes close to
the performance of memcpy, this means that it takes significantly less time to decompress the file than it would have taken to read a longer file from the (often slow) physical media.

If you really would prefer embedded files inside your executable, you may find my tool useful:
http://svn.icculus.org/twilight/trunk/lhbin2c/

This tool (lhbin2c) produces not only a series of initialized arrays containing the file contents, but also an array of file information so that you can simply scan through it for a requested filename
and return the address of the file data (the plus side of a memory file is that it is already loaded).On 10/18/2011 05:20 AM, Christoph Harder wrote:

If you compress the files you can use sdlrwops or some library like physfs to load ressources from the archive. And compressing might actually improve loading times.
But encrypting is totally useless it wastes processor cycles for a false sense of security and since your application requires the key to unencrypt them every user can look into the .exe and find out
what the key is.
And even using a private key for encryption and a public key for decryption is time that you could better spend elsewhere. What stops the user from modifying your binary and insert his own key.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier