Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
add comment

5 Answers

up vote 6 down vote accepted

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.

share|improve this answer
    
Someone recommended physfs to me the other night. Nice little library. –  greyfade Sep 28 '10 at 16:25
add comment

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.)
share|improve this answer
    
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. –  Brett Powell Sep 28 '10 at 2:49
    
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) –  Brett Powell Sep 28 '10 at 2:51
4  
Out of curiousity, does this contract mention how you are supposed to protect their content? –  Blair Holloway Sep 28 '10 at 4:53
2  
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). –  Lohoris Sep 28 '10 at 15:15
add comment

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.

share|improve this answer
1  
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. –  Kylotan Sep 28 '10 at 14:37
    
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.) –  user744 Sep 28 '10 at 15:09
    
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. –  Lohoris Sep 28 '10 at 15:12
    
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. –  Kylotan Sep 28 '10 at 15:44
1  
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). –  Lohoris Sep 28 '10 at 18:24
add comment

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.

share|improve this answer
    
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. –  Brett Powell Sep 28 '10 at 1:57
    
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? –  Neverender Sep 29 '10 at 5:39
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.