Game Development Community

Torque and passworded zips?

by Very Interactive Person · in Torque Game Engine · 04/30/2005 (3:33 am) · 30 replies

I want our game to use passworded zips instead of regular zips. You know, much like in Director for example you can pack all the assets in .dcr or .cct files, I would like to make packages that "can't" be opened, containing all the assets and scripts.
Currently only regular zip files are supported, so I would like to entend that to support passworded zips and compile a password in the engine.
The programmer helping me out has been trying to add this functionality for the past week, but no succes yet. So.... anyone has any ideas? Usefull links? Anyone coded this before?
Page «Previous 1 2
#1
04/30/2005 (5:02 am)
I think Akio put password zips on his ODE implementation demo. Looks for the ODE implementation 2 thread and check it out.

I'm only going from memory, but if I'm right and its him he may be able to help you.
#2
05/01/2005 (10:15 am)
Thanks for the reply, but its not really helping me out, as we've already tried to contact him.

So, anyone else any ideas? Any free libs out there that would be "easy" to integrate in Torque? Or would it be better to just develop our own package format? But that would mean we'd have to program a new tool to make those packages....
#3
05/01/2005 (10:43 am)
Torque uses zlib. Zlib supports (iirc) passworded zips. Just add the API call in the right place to give it the password and Bob's your uncle.
#4
05/01/2005 (7:47 pm)
I've checked the Zlib Library, there is no support for encrypted zip, on the website they say the library doesn't support encrypted zip file either. Are you sure about this?
#5
05/01/2005 (10:07 pm)
Yup, good call. From the FAQ:

Quote:
zlib doesn't support encryption. The original PKZIP encryption is very weak and can be broken with freely available programs. To get strong encryption, use GnuPG which already includes zlib compression. For PKZIP compatible "encryption", look at InfoZIP.

There are some resources however to add a limited amount of protection. Or you could just do your own custom obfuscation to the zlib code so that it can only read specially generated zips. There's a lot of stuff to be done, using an off the shelf solution for security isn't really the best thing in the world, when you're doing security through obfuscation.

No, there is not a secure way to encrypt client side data. Take what you can get. :)
#6
05/02/2005 (7:14 am)
And, just like the pkzip encryption the director .dcr's and .cct's can be 'cracked' with utilities widely available on the internet, allowing access to the sprites and scripts! (One of many reasons I moved away from shockwave). As Ben suggests, custom obfuscation will get you a lot further with less work.
#7
05/02/2005 (7:56 am)
Have you tried this?

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7276


It works well when you can get it work, which thus far for me at least has been hit and miss. :(
#8
05/02/2005 (9:53 am)
Just about any system you come up with can be broken... it just becomes a matter of how much work is involved.

You can slap a symetric cypher (same password to encrypt and decrypt) of some sort on your files (AES for example)... but at some point your code has to have the plain password in memory, and a cracker can grab it and do what they like with your files.

You can slap an asymetric cyper (two passwords, what one encrypts, the other decrypts, and visa versa) on them too. A cracker using the same method would still be able to access your files, but would have to replace that password with one of their own if they wanted to change them.

None of this cracking is easy, but it is possible. You can throw various road-blocks in their path, but in the end:

If its running on their machine, they can do whatever they like with. It's just a matter of being willing to work hard enough.

You can keep the vast majority out, but there is always someone who can get by any protection you create.

Having said all that, here's a great crypto library I've used in the past:
www.eskimo.com/~weidai/cryptlib.html

It supports just about every crypto algorithm you may have ever heard of, and quite a few you probably haven't.
#9
05/02/2005 (10:39 am)
Keep in mind that while an asymmetric cipher may sound like a good idea in theory - the heavy computational requirements tend to make them less than ideal for use in a game.
#10
05/02/2005 (5:04 pm)
Im current working on a program to encrypt the zip file, with a custom encryption method, probably gonna be AES or something havn't decided yet. Im almost done with it, ill post a resource for everyone to use once im done tho.
#11
05/02/2005 (5:16 pm)
There are also a few encrypted container file resources out there. At least one.
#12
05/02/2005 (7:14 pm)
Aside from the speed issues Mark mentioned, using an asymmetric cipher is kinda pointless. The client still has to have the right key to decrypt, and that key can still be recovered, and thus so can your assets. A server based thing may be more secure for that, but aside from the obvious requirement of being online to play the game, the client still has to have the decrypted assets to use them, so once more, they can be recovered. At best, an asymmetric cipher would prevent the end user from injecting assets into the game if you refused to load unencrypted assets, but that is probably not what you're after :)

Given that anything you do is breakable, if you really want to go down this route, the best course of action is that which is quickest to implement. I would say that would be leveraging existing tech, perhaps through the use of the aforementioned already existing resource(s), or perhaps by obfuscating the file formats. Whatever you do, all you're going to be able to "prevent" is casual copying, and that is only going to last as long as it takes a skilled person to break the system. Once the system is broken it is trivial to create a tool to decrypt all the assets and thus make them available to the casuals too.

Of course, all this depends on whether what you are "protecting" is worth having. The most insecure system can remain secure for years if nobody wants what it's "securing" :)

T.
#13
05/02/2005 (7:30 pm)
Write now basicly i wrote a program to do a simple XOR encryption on the files inside the zip... and added code to the engine to read it. Once i finish cleaning this up i entend to encrypt the headers on the zip file also... maybe with a different pass... that way you can't use the crc in header to brute force it. I know this is very simple encryption method and anyone with some hacking knowlege can disassemble the .exe and find out the pass and method used... however, there are loads of programs out there to "pack" the executable which of course isn't 100% secure but adds another layer of protection making only more experienced hackers access to the file. Using this method will prevent 99% of the people out there from access to our files. But still if someone REALLY REALLY wants it, and are able to get passed all this security, there isn't much more you can do. I might keep using a XOR encryption, since its fast, but i'm still debating if there might be something better out there thats just as fast.

Thoughts?

- XoCluTch
#14
05/02/2005 (7:38 pm)
Since you're working client side anyway, XOR is about as secure as you're going to get. You could go whole hog and add in AES or Blowfish or something, but the means to defeat it is going to be the same - picking the key out of system RAM.

So don't spend a lot of time coding encryption that's not going to buy you anything beyond what you've already got, would be my advice.
#15
05/02/2005 (8:19 pm)
Packed executables are no security at all. Pretty much all the existing packers have an unpacking utility. Also, there are a ton of utilities that will automatically unpack an executable packed with an unknown packer. The amount of time for even a relatively unskilled person to get around a packed executable can probably be measured in seconds, possibly even less.
#16
05/02/2005 (8:31 pm)
The Latest version of nprotect, is very hard to get around, there arn't any unpacking utilties to unpack it yet, only way to do it if your skilled and do it manually. Obviously you would have to use a packing util that is kept upto date with the latest encryption technics, but of course you're right it will eventually be cracked, but it just adds that extra layer to make it more difficult to crack. My biggest concern is the common person stealing the artwork or code.
#17
05/03/2005 (4:06 am)
I finished my code to Encrypt a Zip with XOR encryption, I think its pretty secure, only way you'll be able to decrypt it is if you disassembly and get password... Would you guys like me to create a resource for this? Obviously Releasing the Source code will make it less secure, since the proggy that comes with it can decrypt files also if the the correct password is given...

it basicly has takes 2 different passwords, and encrypts the headers of the zip file with one, and encrypts the data with the other then you just add the passwords into the game engine and it will run like normal
#18
05/06/2005 (11:18 pm)
Go for it! I suggest offering a small prize to the person who cracks it first... Say $20, about the cost of a game. :)
#19
05/06/2005 (11:24 pm)
Lol I dont have 20 bucks im just a poor college student ;)
Ill post a resource for it tho, once I got it all tested, and am happy with it...
its a little more complex then just XOR now, Its probably just about as secure as a zip file with a password. More so , because there arn't a zillion programs out there to crack it =P
Ill sure post a challenge tho, and any comments on how to make it more secure ill gladly accept and put it into my code.
#20
05/07/2005 (4:53 am)
XoClutch


Great work, I'd love to try it out. I'm only concerned with casual user security anyway. If this will stop my mom from opening the zip, that's good enough.
Page «Previous 1 2