Tag Info

Hot answers tagged

14

Answers SRP - Secure Remote Password - This is based on Diffie-Hellman. The idea is that you can do a mutual password check without actually ever transferring the password or any information that can be used to derive it. Even though it's secure over the wire you should still hash and salt your passwords as your server must never store them in plain text. ...


9

How does file encryption in game assets work, for example the unreal engine has a .assest extension, or I also see a .dta extension in another game, are these zip type packages which have a custom encryption algorithm set by the developer or how does it work? Most of the time, those are not encrypted data files. There's a difference between ...


8

Don't ship sensitive data. There is no way to ship encrypted data so that only the game can access it. You can try really hard but you quickly get into the DRM issues. If you want to keep your game assets away from prying eyes. zip it up xor the file change the extension to something boring (ie not my_level.zip.xor, use my_level.map) . That will stop ...


7

Obviously not a lawyer, so this isn't legal advice, but my personal interpretation is: The code is licensed under Apache License, Version 2.0. If you read the Redistribution section: You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form... So, yes, ...


7

A good strategy is to make your own archive format from scratch, and to make it an indexed one with a table pointing to data chunks instead of storing whole sequential files in your archive, then encrypt your index table and compress every chunk separately using LZMA/Bzip2. Another approach is using bits of procedural data generators here and there (If you ...


6

Mainly compression is used to reduce the size of the distributive and game resource package. You should distinguish compression of the distributive and the resource package of the installed game. The distributive usually is compressed by high compression ratio algorithms, while the package of installed game can be compressed by algorithms with fast ...


6

Yes there are many tools that allow dumping of the full swf, and/or all of the actionscript. http://www.buraks.com/asv/index.html being one of the many out there. No, its not worth the CPU power as it will be easy to crack and design a fake program using your "hidden" key. If someone is going through the trouble of hacking your game, a "hidden" key and data ...


5

I've been researching the same thing and I found this repo to be extremely helpful. The file decrypt.rb decrypts both chunks and keyframes. Edit: check out this reddit thread too.


5

If you're interested in cryptography, run over to Coursera and sign up for Dan Boneh's Cryptography class. It'll teach you all about the fundamentals, how to secure various forms of communication, etc. Key take-away points: do not invent your own algorithms use an existing crypto library use existing crypto techniques


3

A big reason to compress game assets is to decrease loading times. Example scenarios: Read uncompressed asset of 20MB size, or Read compressed asset of 10MB size and decompress. In scenario 2 less data needs to be read from the hard disk which will save some time. If the CPU is faster at decompressing the read 10MB to the original 20MB than the hard ...


3

Mainly compression is in fact used to reduce distribution size. If you think about it with digital music, you could download a CD as .wav and it's 650 MB, or as 256 KBPS AAC files and it's 1/5 the size with the same sound quality*. It just makes sense to compress anything you can. You're taking the compression time on your side once to save time ...


3

My job is in antitamper software. I know somebody who is an old school game cracker. He cracks games like breathing. You can't stop people like him. If your game is popular enough, multiple cracked versions of your game will hit the torrent sites only a few days after release no matter what you do. My advice is to just do the bare minimum to keep out the ...


2

Spending any large amount of time on this is probably foolish. There are tools to grab texture and model data directly from the GPU, and sounds can easily be pointed at a virtual loopback device. Anything that needs to be truly secure needs to live on a server and work only via challenge/response. Doing client data validation is another story, something more ...


2

According to the Google Code page, the license is attribution + share-alike. I quote (emphasis mine): Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. That means "yes."


2

How do you store your data now? Presumably you have a bunch of setting files or even XML. Let's say your data looks like this: <Character name="Jim-Bob the Peasant"> <Item name="Shirt"> <Protection>1</Protection> <Weight>1</Weight> </Item> <Item name="Belt"> ...


2

I think my last comment to Jonathan's otherwise excellent answer is worth expanding into an answer of its own: If you don't have a lot of crypto experience, you shouldn't try to design your own encryption layer if you can avoid it. If you do have a lot of crypto experience, you should know better than to design your own encryption layer if you can avoid ...


2

I'm assuming that the presence of crypto isn't the only thing that's part of your evaluation of game engines. My suggestion would be to start making a list of features you require (including crypto), and start whittling down the list of engines. Additionally, what you want to do with it is a factor as well. If you just want to encrypt a local file, ...


2

Truth to be told, there's no reason to encrypt data in a program that will run client-side (that does include any flash/HTML or unity based games running in the browser). Anyone that's inclined enough can get the data anyway - be it by hijacking internal function calls, the OpenGL/DirectX calls, etc. Once it's on the PC of the user, you must understand that ...


2

I see the following reasons to encrypt data: Protect your users' actual sensitive data by adding to the amount of encrypted traffic. If hackers have to wade through not sensitive game assets, they're much less likely to find a user's actual sensitive data. Protect your servers. Using asymmetric key encryption (like TLS, what people still commonly refer to ...


1

Encrypting the data each player receives makes cheating and ripping of assets a bit harder, but not impossible. The data needs to be decrypted by your game client anyway, so the encryption algorithm and key must exist on the users machine. That means the users have everything they need to decode the network traffic. So you only add a layer of security ...


1

The answer is time Use Compression? if uncompressed (down)load time > compressed (down)load time+decompress time then Win! use compression else Lose! don't bother


1

Always downloaded from the server. If the private key is compromised then you can easily create a new one. If you're worried about load when the game gets popular, you can monetize your website or sell your game to pay for server upgrade/rent.


1

I believe this might help you. In short, there are unlimited number of ways to encrypt your game data. Anything from simply bit swapping to more complicated key based, or even using PGP are all valid ways of storing and encrypting the game data. Compression should happen before encryption as Kornel Kisielewicz has pointed out. You can use whatever ...


1

I think the answer is that 90% or more of the clients would not find a way to use all these exploits but it is enough that one person will and it's on the net and the damage is done. Often times it is sufficient to cheat a small amount of times at certain critical points to gain unfair advantage. You may not be able to detect cheaters if you randomly check ...


1

A better approach than straight up encrypting the data would be to pack the data in a compressed format that still allows efficient loading, and then use a check sum to verify the integrity of the data at load time. Any form of message digest (even rolling your own) should be significant enough. Also, be aware of what encryption seeks to accomplish, and ...


1

You only really have two options when it comes to high performance graphics cards - AMD or NVIDIA. The simplest answer is to get one of each, and profile your algorithm on both to see which is best in your specific case. However, my guess based on having seen a few articles like http://www.theregister.co.uk/2012/12/07/monster_password_cracking_rig/ is that ...


1

Don't make it too easy for hackers by putting each individual image in its own file or whatever, but don't bother with encryption because the determined ones will just break it, and pushing it to slow them down will just slow down your game and its development. Blizzard's MPQ format has encryption, and it has been cracked. The big name games tend to use ...


1

Possible duplicate of this question ? First of all, you may try to serialize your data structure and save it in a binary format, probably also try to obfuscate it with some useless data. Now, the client must try to reverse engineer it. Of course, that is not enough, and now it's time to encrypt this data. I believe that ANY cryptographic library would do, ...


1

The golden rule of security is "always assume that your client is compromised". You're giving the client away, and no matter what you do, someone, somewhere WILL hack it. Unless no-one play your game, of course. So, encrypting protocol with a key "hidden" in the client is about the same as not encrypting at all. If you're worried about cheating, the best ...



Only top voted, non community-wiki answers of a minimum length are eligible