I am about to purchase quite a few model packs from a website for prototyping my game. In the contract it states that I must protect them as to prevent the public from gaining access to them.

I remember working with the Valve games, they used .gcf (game content file) that basically was an archive of all the content for each game. They packed in sound/materials/models/maps/etc. I figured it might not be a bad idea to develop something similar to this, and just write a small tool to let me add/remove files from it.

Problem is I really have no idea how to go about starting on something like this. I tried Google but I didn't even know what to search for. If anyone has any ideas, links that might be of use, or anything else I would greatly appreciate it.


5 Answers 5


Store your data in a slightly obscure archive format such as 7-Zip.

Give them a different file extension so that a casual user can't easily open them with their zip program.

Use physfs to read and access those files. It also lets you work with files in your local directory too, so you can easily test new resources without rebuilding your packages. Highly recommended.

Consider very trivial encryption on the content, eg. XOR encryption. Write a little batch file or script to build your packages, encrypting the data as it goes in, and use the same function to decrypt the data in your game.

This won't keep a determined user out - nothing will. But it will be good enough to satisfy the requirements of your model packs.

  • \$\begingroup\$ Someone recommended physfs to me the other night. Nice little library. \$\endgroup\$
    – greyfade
    Commented Sep 28, 2010 at 16:25

If you're just prototyping, then I wouldn't worry about packing your assets into a GCF/ZIP/PAK file; the public isn't going to see your prototype!

Furthermore, Valve's GCF provides as much protection for your content as a ZIP file would - i.e. zero. The file is not encrypted; you can download GCFScape to browse and extract its contents.

It's not worth putting the effort into creating your own pack file system unless you have specific needs right now that aren't being met by ZIP files or the OS's own file access mechanism; in fact, the only reasons I can think of are:

  • Content obfuscation (keeping your files free from tinkering has its uses; I still suggest its overkill for your current needs),
  • Storing additional per-file metadata in a game specific way to help data-drive your content in some way,
  • Getting around the OS's filesystem limitations, such as needing to access thousands of small files quickly, or ensuring contiguous data access. (This is a defacto need when working on consoles.)
  • \$\begingroup\$ I agree completely. Problem is, I won't be able to release a demo without some form of protection in place. ZIP is too well known, PAK is about the same. Atleast with a custom format (Valve requires a CTX key which is hardcoded into the game engine to access GCF files) the average joe won't just be able to run an extraction tool on it and get in. \$\endgroup\$ Commented Sep 28, 2010 at 2:49
  • \$\begingroup\$ Woops, didn't realize enter wouldn't go down a line. Anyways, I found this nemesis.thewavelength.net/index.php?p=35 which seems to be an open source Lib that provides GCF functionality independent of Valve games. Problem I see here is that it is much too robust, and I was looking for something a bit more simple just to create a basic version to expand upon later. (To be honest, the way he codes makes my head hurt) \$\endgroup\$ Commented Sep 28, 2010 at 2:51
  • 4
    \$\begingroup\$ Out of curiousity, does this contract mention how you are supposed to protect their content? \$\endgroup\$ Commented Sep 28, 2010 at 4:53
  • 2
    \$\begingroup\$ that's the point! Since you can't really secure it, it is mandatory for you (if you are not stupid) to exactly know what these incompetents want you to do. Otherwise whatever you do, since it won't work, you can be held liable (of not doing something that couldn't be done in the first place). \$\endgroup\$
    – o0'.
    Commented Sep 28, 2010 at 15:15

This requirement is, well, bullshit.

Since the game can access the data, and the user has access to the game, if he is skilled and determined enough he'll manage to reverse-engineer the format you used to store the data and grab the eventual key if you were fool enough to encrypt it.

You cannot add security. I repeat: you just CANNOT add security. You can only add obscurity, and obscurity is totally pointless, since - as I said - an user with enough skill and determination will just break it.

Don't sign anything that asks you something that can't be done.

  • 1
    \$\begingroup\$ Obscurity isn't pointless because most users don't have "enough skill and determination". The same goes for securing your home: anybody who really wants to get in can do so, but it's still considered worthwhile making it awkward for them. \$\endgroup\$
    – Kylotan
    Commented Sep 28, 2010 at 14:37
  • \$\begingroup\$ Counterpoint: Obscurity is pointless because unlike breaking into your home, once someone has broken into your game they can make it trivial for anyone else to do so. (On the other hand - Obscurity is not pointless, because Brett needs the models. I just don't think the analogy holds up well.) \$\endgroup\$
    – user744
    Commented Sep 28, 2010 at 15:09
  • \$\begingroup\$ If someone steals a piece of gold from your home, he has your piece of gold. If someone grabs your precious model from your datafile, he can do as many copies as he wishes. So, no, this example doesn't work since here it totally doesn't matter how many people crack through your worthless protection: one is enough. \$\endgroup\$
    – o0'.
    Commented Sep 28, 2010 at 15:12
  • \$\begingroup\$ One is enough, assuming the others care enough to stop looking at their local files and go online to look, and providing someone went to the effort of posting the stuff online (which is illegal, whereas viewing your local copy is not), or posting instructions, which assume you have the patience to go through with them. Every little helps. \$\endgroup\$
    – Kylotan
    Commented Sep 28, 2010 at 15:44
  • 1
    \$\begingroup\$ Every little helps for what? Preventing users from watching your data and doing nothing about it is so utterly pointless that makes me sad. This idiotic requirement most certainly exists to prevent other people from re-using those data, so you only have to care about determined people who will try hard and succeed (because, as I said, in the long run they just can't fail). \$\endgroup\$
    – o0'.
    Commented Sep 28, 2010 at 18:24

A lot of times I notice that custom content packages tend to be a .zip or .rar archive with a different extension. Of course, this is no good if the web site wants custom encryption of some sort.

  • \$\begingroup\$ Yeah, Ogre already supports loading in resources via zip file. Someone mentioned in a chat room just passwording the zip file, but with the amount of tools around to crack them, it really isn't my first choice. I would really like to do something similar to the .gcf files that Valve uses, but I don't even know what to search for as far as getting started. \$\endgroup\$ Commented Sep 28, 2010 at 1:57
  • \$\begingroup\$ If someone cracks your zip file, how is that your problem? Really. They can crack anything you can throw at them. You tried. Where do you draw the line for what these licensors can hold you responsible for? \$\endgroup\$
    – Zach
    Commented Sep 29, 2010 at 5:39

A few ideas:

1] Have you used a standard model format (eg .obj, or .x) or do you use a custom model format when loading directly into your game? If you've got a custom format, and one would have have to reverse engineer your model format to get it into a useful form, then you've already got some level of protection against the opportunistic asset ripper.

2] Kylotan's point about XOR encryption is excellent, except to note you can encrypt using a pseudo-random number generated sequence (possibly seeded by a hash on the filename) to avoid long sequences of zeroes in your source data showing your encryption string. Of course you'd have to in-place decrypt your files immediately after they're loaded, but breaking your encrypted file into restartable blocks will allow you to kick off in-place decryption on multiple threads if this really became a load-time burden. But I seriously doubt this level of "protection" is required - particularly, as others have said, the determined ripper will get around it. eg. by intercepting the draw calls by using a DLL detour library, and reading back the vertex buffers/index buffers directly.

3] You'd have to ask the original asset provider about their requirements for protection, but it could just be a matter of adding a blurb about asset copyrights to your program splash screen and/or to your EULA.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .