By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Katilian said:

Wouldn't slow them down in the slightest. The client has access to the data both before it is encrypted, and after it is decrypted, meaning so does anyone with a decent debugger. There is no actual need to break the encryption! All I need to do is piece together how the unencrypted sent save maps to the unencrypted return save. Then all I do is strip out the encryption/decryption funcationallity in the client and get it to handle the unencrypted data directly, as does my spoofed server. Or I could just complete overridely the save/load function entirely and get them to use the exact same data anyway...

This is the fundanmental flaw with DRM. (Taking the old encryption metaphor) Alice wants to send a message to Bob without Cylde being able to read it. Trouble is with DRM, Bob and Cydle are the same person.

Edit: Just focusing on your last paragraph. They only generally get a one shot at delayed piracy. Unless they come up with a new scheme for every release (expensive and time consuming, unlikely to get the money back in sales), they might slow down the crackers for the first release that uses it, but once the inner workings are known, repeating the procedure is simple.

This also assumes the crackers don't get a copy before release (usually they do) and aren't working on cracking it before it comes out. Given how many games have pirated versions before or on the release date (hint: most of them), you really need to be on the ball to get that window of opportunity.

Also, the crackers do usually generate methods that can be tailored to future releases using the same copy protection (many copy protections also share similar traits, so even if they are different, figuring them out is a fairly generic process). This is why pirated releases appear so quickly. You're also forgetting that there is "glory" in the Scene for defeating copy protections and being the first to release the pirated game. Crackers also do this for the fun and challenge, so the "effort" required for smaller releases isn't an issue.

Forcing someone to connect to the server means that functions which are required for the game to work could also execute on the server as well. Its difficult to reverse engineer an executable file without the source code available. It probably goes beyond saved games as I have recently read further on the topic. It seems to imply that part of the game itself will execute on the server. So its only an easy trip for them going forward if:

A) An unprotected version of the code is leaked ahead of time.
B) Someone gets a hold of the server executables.
C) They don't use unique keys and someone builds a keygen.

If they took part of the display driver hookup out of the local code and stored it on a server, even if they did manage to reverse engineer it it may only work on say the DX11 path for Nvidia cards in the current generation.