Subscription based standalone game build without using a storefront

Hello there,

Let me try to explain what my company is looking to do. We are building educational games for companies who work in third world countries to stay safe. The way our contracts work is that a company will purchase a standalone game for a set period of time, usually 1-3 years. Once that time period is up, they can either purchase an extension for their subscription, otherwise, they can't have access to the game. We are trying to produce these games without any need for an app store or client-based system like Steam etc.

What we are currently looking at is having the game itself have a start screen where it will check the current date on the computer against a specified end date variable for when the client's contract ends. Our sample for this is below.

https://answers.unity.com/questions/1250833/how-to-check-the-date.html

If the current date is before the end date, it will display how many days in their subscription they have left. If it is past the end date it will display a screen saying that their subscription has run out and that they need to contact our company to extend it. This screen would display our contact information but have no more functionality so they can't continue playing the game.

The issues I'm having with this system are a few:

1- We would have to issue separate builds for each and every client with code that would have their specific end date hard-coded into the variable to check against, which means we can never sell any off the shelf courses, they'd all have to be custom built. (I suppose it's possible for "off the shelf" courses to simply have a date timer that collects the date the game is first started against a date 365 days after that first start date.)

2- Using this method, when a client purchases an extended subscription, we'd have to send them a new build with a new date coded in and hope that all of the people in their company using the game, redownload the new version of the game and stop trying to use the old one.

3- I'm assuming that since Unity is checking a system date against a variable date if the user changes the date on their computer, they'll be able to get around our date checking software.

Are there any more elegant methods you all can think of to achieve the same or a similar goal but without some of the issues? We were thinking of having extension keys where we build in a handful of codes they can enter one time only and if the customer purchases an extended subscription, we send them the next activation code and they can get past that blocker screen for another year etc.

Thanks in advanced for your help!

 

I'm not sure the subscription base would be the best solution in this case.

Unfortunately there isn't any offline 100% safe method for periodical key validation check. Consider if it is offline, it can always be changed. You can have a look at some out of the box solution like cryptolens, but still would not be 100% safe.
Having a set of keys will not make any difference if it is offline, you might as well have only one key, as they cannot be compared to each other against a database of keys being used.
Also, instead of making a new build for each instance, you can simply make a new encrypted file with the info that you can read from. It will have a very similar effect than a new hardcoded build but without having to rebuild it, odds are nobody will put the effort to decrypt it, as there are easier ways to bypass the game if it is offline.

Regarding the date method, you don't necessarily need to use that as a reference to how much time has passed, as it is by far the easiest way to cheat. One alternative would be to create files which track time and are not bound by system datetime, those can be deleted but are harder than changing time.

If you really want to validate properly you have to do it outside the app, so online. I'm sure that's an option, even in third world countries.

 

I mostly agree with FarnandoHC. For any sort of offline validation, you are dependent on data provided to you by the customer's computer. Since it's their computer, they can change pretty much anything on it to lie to your program, if they are sufficiently determined. The best you can hope for is to make cheating a little less convenient by using more complicated checks.

Additionally, a common problem with securing software is the issue of "class breaks", where breaking one copy allows someone to break all copies. If you are manufacturing physical locks, and one person figures out how to pick your locks, then that one person can get past your locks, but your locks will still stop other people. But in the world of software, if one person figure out how to break your security, they can write a program to do it automatically and distribute it on the Internet, and suddenly everyone can get past your locks. So even if you have really good security, all it takes is one evil genius somewhere in the world who can figure out how to break it, and suddenly breaking it becomes easy for everyone else.

It's also worth asking yourself whether you are even focused on the right problem. You're worried about someone buying your software and then continuing to use it after their license expires. Have you considered that someone might buy your software and share it with 5000 friends, who can then use it without needing to buy it at all? That seems like a much more serious concern.

That's basically the issue that "DRM" software tries to solve. People have been working on that problem for a long time, with extremely limited success. There are companies that just make DRM solutions and sell them to major video games to try to stop people from copying the video games and playing them for free, and they basically don't work--for popular games, I hear that the security usually holds up for somewhere between weeks and hours before someone posts a break.

The bottom line is, restricting what your software does when it's running on hardware that someone else controls is very hard. It's like the difference between making a safe that will protect your valuables in your own home, and making a safe that will protect your valuables even when the safe is located in a criminal's home, where they have unlimited time and access to try to break it.

However, I think I can help with this specific bit:

This specific problem can be solved with a challenge-response protocol. The installed copy of your software generates a random code, the challenge, and the user has to call you up and tell you that code when they want to renew. You enter that code into your system and it generates a new code based on the challenge--the response--and the customer has to enter that second code into their computer. Your software verifies that the response is correct for that challenge (so the correct response to a different challenge won't work). This way, everyone who wants to renew needs a different code; giving your code to someone else won't work.

Of course, this doesn't solve the problem that someone might edit files on their computer to make your software think that it generated the same challenge as their friend's computer. For that matter, it doesn't stop them from editing files on their computer to make your software think they've already renewed successfully when they actually haven't. But it does stop the specific problem of customers sharing renewal codes with each other.

 

Thank you both for responding, this has been very helpful. It seems like my fears were on track and that my responses have a few directions to go, but being able to relay this information to my manager is quite helpful in realizing that any solution we propose for this will have some inherent (and very common) problems.

Thanks again for your help!

 

I'd just like to point out that if you make your software a hassle for legitimate users, they will look for alternatives without that hassle rather than wanting to extend their contract. Installing new builds or changing licensing files will require a tech person if having to be done manually, instead of through a system like Steam. If your customers aren't expected to have reliable internet, what are the chances they maintain staff members with even basic technical knowledge?

Also a challenge response system over the phone can be expensive in some countries, especially countries with limited internet access.

Be careful in your quest to stop unauthorized use of your software than you don't run off your legitimate customers.