TIGSource Forums

[...]being redistributed or used after a certain date, no matter how inconvenient it is to the user? Note that this is purely theoretical.
Basically, this would be used for a highly closed beta test or such, with the idea that it's simply impossible to use it after x/x/xxxx at xx:xx, NO MATTER HOW RIDICULOUSLY INCONVENIENT IT IS. So it's fine if it needs an internet connection, anything.
An obvious solution would be to download a file from a web server and if it doesn't have specific content, don't run. Thing is, a user could set up a local web server, set their HOSTS file to redirect my.domain.com to 127.0.0.1, and put that file on their server. It's clear that hex/assembly hacking would probably work eventually, but short of that, is there a way to lock it down NO MATTER THE INCONVENIENCE. (I don't think I'd ever be obnoxious/untrusting enough to actually do this, but you never know and I think it'll be interesting to discuss.)

You're on the right lines with hitting a webserver, that's what the majority of the most annoying anti-piracy patches do atm. You need something on the webserver that is hard to fake. You could simply shove all of the content there. But if you assume no exe tampering, then having the server decrypt something encrypted with asymetric encryption is even more effective (digital signing (http://en.wikipedia.org/wiki/Digital_signing)). This cannot be faked locally, as they won't have your private key.

I thought of using asymmetric encryption, but what is this 'something' that would be sent?

I remember reading in a discussion people suggesting to have vital processing occurring in an external, controled server. They suggested AI. It would require expensive infrastructure though.

I don't really like discussing about this. Even if nobody here uses it, somebody might stumble on it and have ideas.

Pick a largish random number. Send it to the server. Have the server sign your random number with a private key and send back the signed version. The client has the corresponding public key and can verify the server in fact signed it. Assuming the user can't somehow manipulate what random number you generate this is pretty unbreakable (though you're still wide open to them hacking the program's machine code).

Thing is, the bit in parenthesis there is actually a pretty big deal.

With security issues, the starting point shouldn't be what measures are available so much as what the bad guys are most likely to attack. With a game, you get two kinds of behaviour you mainly want to prevent:

1) People who would quite like to play after the deadline and/or enable their friends to do so and will therefore spend ten minutes trying to defeat the security.

2) People who, on principle, want to hack your game as soon as they discover there is security and will then distribute the hacked version.

Players in group 1 are no kind of threat at all. Most things will stop them, including pretty much anything that uses a server.

Players in group 2, however, will have no trouble at all with the system being proposed.

If you want something a little tougher, download some game-critical data from the server (encrypted). That way if the hacker just strips out the entire code section they'll be left with a game that doesn't run (or degrades to a demo).

Still perfectly possible for the bad dudes to get round this, of course, but if you're lucky you'll reach a level of protection where they can't be bothered.

Assuming you're talking about a Windows system... Something to do with web installations, registry entries, and system restore dates comes to mind.

The bottom line is, though, no. Anything date based can be defeated with just setting back the machine date and keeping it disconnected. However, you could make that arduous enough that it's unrealistic - such as, after the target date the game can only be installed on a disconnected, back-dated, fresh-installed/system-restored machine, with a snoop of the transfer of the web install spoofed to the local machine. Could also toss a watchdog something into the prefetch directory or services list to blow away or break the program if the date ever changes ahead of the target date, and then remove the watchdog program. For best results, keep the release window short so that you can security check the system date against the last-modified date on the installer file.

Though I'm not sure Vista wouldn't pitch a tantrum about letting an installer access such protected areas of the system.

/ I'll stop thinking up evilness and making edits, promise

Honestly, there isn't.

The more difficult the DRM-software (yes, this is a form of DRM) you have on an application is to crack, the more crackers will swarm to try to crack it.

Have the client only draw graphics, do all processing on the server. This has the added advantage of not needing to update clients on small bugfixes and being able to collect user statistics (since you're running the actual app on the server). This is basically how MMOs work. Not really, but simplified.

If you just wanted to prevent redistribution of a closed beta, an alternative idea would be individually watermarking each copy, so if it does leak at least you know who did it -- and, if you tell players their copies are watermarked, and perhaps also put their name/info on the copy in an obvious way, you have an implied social (and perhaps legal) threat against redistribution.

Of course, they could try removing their name and all the other watermarks; it seems hard for them to know if they've succeeded though.  Especially if they don't have anyone else's beta copy to diff against.

...cleeeeeever!

Here is what I would do, you must do ALL these steps:

-everybody who downloads file must give valid name and address, these data should be hardcoded in the software and displayed somewhere in the first menu
-put another secret watermark into each file to know whose version was spread
-prevent game from installing after a given date
-during installation make the software record the location of the setup file somwhere in an ini file
-check windows date and make the deactivate the software after date.
-make the software connect periodically to a server to check date on the server, if connection is impossible let the software run, but stop the software after 5 unsuccesful attempts of connection
-put an internal timer in the software, record how much time has passed every time the software is being run, when the theorical date is passed (for example if the software has been run ocntinuously for one month) deactivate the software
-when deactivating the software you must delete or at least corrupt files in the software directory
-when deactivating try to locate the setup file at the perviously recorded location and delete it.
-have beta testers sign an NDA
-wait until beta tester goes out of house and pretend you reandomly bump into him in the street, find excuse to be invited into beta tester's house. Once inside, improvise.

The thing I like about this plan is that it's still susceptible to binary hacking, but ONLY if the hacker thinks to start working before you shut the server down.

But yeah watermarking if it's actually feasible is probably a more practical solution. It depends on exactly what it is you're trying to do.

The idea of watermarking is predicated on being able to catch the offenders.

Hello,

There's a whole software category of solutions that provide time-limited versions of your software.

Search for something like "software protection licensing time limit" in google and I'm sure you will find a solution that meets your needs.

Hope this helps

Execryptor provides time limit functionality as well as key generation, when I asked 6 months ago to someone experienced in the reverse engineering community about which packers were the least trivial to defeat this was one of them.

http://www.strongbit.com/execryptor.asp

It's basically a wrapper over your main executable, doesn't install any other software on the users system.  It's also affordable price wise.

But if they do, it's trivial. Just diff the two copies and put garbage in the differing parts. You'd need to do some checksum thingy to prevent that. Now, it already requires actual cracking to bypass the checksum mechanism. Then again, that's still fairly trivial too... Even I've managed to hex-edit programs to e.g. jump unconditionally where normally they'd make a decision.

Invite all users to your home and make them play though dumb terminals. Make sure they are all naked before they enter the room of testing.

Anything you give to the players can and will be hacked in any way. If you make a hugely complex isAllowedToRun() method, it takes minutes to make it always return true. You can duplicate this method all over the place in different shapes, but the fact is that anything you put in there can always be hacked, and there's nothing you can do about it ever.

So the only solution is to NOT give them the game, for example by doing this:

This is mostly theoretical, though.. In practice there are some fairly successful hard to crack DRM schemes out there that haven't been cracked yet.

Care to elaborate? I don't believe there are any uncracked DRM. Well, some games haven't been cracked, but this is mostly a case of obscurity, not security. Case in point: Solium Infernum. But all big publisher titles have been cracked as far as I know.

Sure ... another option is to consider all possible pairs of beta testers, and add a watermark that each pair shares.  (And possibly also consider groups of 3, 4, etc)
Then if they just nuke what's different, the watermarks that remain identify the exact group.  You would need O(n^2) watermarks just to account for pairs, though.  (And when you need that many watermarks, it's perhaps more easy to damage watermarks you haven't even found just by writing where they might be stored ...)

If the game is high-profile enough for some sort of large-scale collaboration, another possible problem-scenario is if someone breaks into a beta tester's computer and gets their copy that way; then sharing it with watermarks intact would just point to someone who did nothing wrong except maybe bad security.  (And of course, there is the related issue that someone could leak the beta and then claim it was stolen to avoid blame...)

Do what OnLive does. Have the players play the game on your machine through a web interface.

And just to be sure, murder them before they leave.  >:D

Ah, sorry, I didn't mean there was uncrackable DRM.
I meant basically exactly what you said in the second sentence there. Some things haven't been cracked yet, so it CAN slow down some people (especially if you're not huge), but there's no way to make it truly secure.

Never give it out to anyone!

Fine, not that funny. ::)

The easiest way I can think of is to move essential game components onto a server.