Custom Content Package for Files

Question

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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.

Answer 4

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.

Answer 5

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.