hi,I am working on a "massive single player online game", whatever that means :). This will actually be a card game with 3d animations that you will play by yourself. The game will require an internet connection to play, as it will have a tightly integrated social system to drive engagement. 

I'd also like to have the server be authoritative for some basic stuff - since it's a single player game, I can't really be authoritative for much, since the game has no verifiable rules - the game allows players to just play cards and watch the animations with some local interactions/random effects. But at least I can do some basic sanity checks, such as "does this user have this card, and did they actually pay for it", "have they played this card already in this game", "have they played a card within the right time limit, as in has it been at least X seconds", etc...

Just to clarify - the game doesn't actually have server-verifiable "rules" per se, it's not like Solitaire where I could simulate the game being played on the backend. The game just allows players to play cards and watch the animations on the screen.  The "rules" are arbitrary and defined by the person playing the game, so there's nothing to verify in that regard. 

Since the game is single player and there are no server verifiable rules in the game I know that this will be easy to hack since a malicious and smart player could eventually build a proxy to respond to the calls on behalf of my game server and allow players to download pirated versions of the app in an app store with all of the IAP assets already in the build. 

I have an idea that I wanted to run past you guys about adding an additional layer on top of the basic sanity checks to protect the assets from being pirated. Basically - the game client will come bare bones and you won't be given any cards up front except for the "gifts" you receive as a new player. This means the graphics & animations won't be on the device until the moment you open that card in a pack you purchased. The server keeps track of what cards the player opened in the packs.

Here's the trick now: the animation files themselves will be encrypted and the client won't be given the key. Then, when the game client goes to "play mode", he calls out to the server and says "I'm about to play a game using these 10 cards" - the server verifies he purchased those cards and then sends him the 10 seperate keys for those animation files. The game client would load the animations from disk, decrypt the files, and then throw away the key and never persist the decrypted animation files.

In essense, the only way a malicious person could now obtain assets they don't own is some person would have to first attach a debugger to a mobile game client, find the keys in memory in the exact moment it's sent from the server, and then build a server proxy which would respond with those keys to anyone who downloads the pirated game. OR, they'd have to dump the decrypted animation files to disk - and then make the game logic jump over the decryption sequence (I'm not sure how hard that is to do).

This feels sufficient enough for me that it would be a big enough barrier to prevent hacking at least to some reasonable extent. In addition, I could cycle the animation files + keys on a monthly basis if I really wanted to.

Any thoughts on this? Is this just absolutely insane? Is there a better way? Is this just a waste of my time and I'm missing something obvious? I know that credit card processing companies have used similar methods (perhaps outdated) to store credit card numbers.

I''ll still need to prove the concept by making sure this isn't too memory /CPU intensive on a mobile device (e.g. iPhone + Android).

Thanks for any feedback!

Why do you think those are the things that need protecting? The art and animation assets themselves are usually among the least protected because there is no significant benefit.

Your encryption rules don't really help much.  Encryption is like an armored car service, it protects stuff during transit but does nothing to protect against those on either end.  

By virtue of the way services work the other end is always untrustworthy. I guess the analogue would be for a bank to trust any transaction a customer sends because the transmission is encrypted. It doesn't matter if they're transferring a million dollars into their account from a null account, the transaction is encrypted so all is well. Never trust anything coming from the client. Ever.  All values must be validated before being used.

It seems your concern is to protect the moves people make and the rules of the game. in that case you can make the client into a dumb terminal and only state where the cards are displayed, receiving the clicks they make, and doing all the processing on your side. No need to protect any animations, it is the processing that gets protected by never exposing it to the client.

What is the attack you actually want to protect against?

For example, you could pre install all cards, but make the client "dumb" and just send selections to the server, and then only show/animate based on instructions from the server. This would prevent against players "seeing the wrong thing" until players figure out how to write a fake server.

Regarding encrypting the assets against "ripping," know that tools exist to slurp textures and vertices out of the graphics card. Because the card needs to render to screen, that data need to ultimately be in decrypted form.

Pays can also use screen video recorders to record the animations and enjoy them whenever they want.

If you want to encrypt files on disk, there is nothing bad about that per session, but it won't stop a determined attacker. That being said, your actual problem will be getting people to find out about your game, and then care about your game, and then care enough to give you money. Asset ripping seems like a first world problem by comparison -- almost like free advertising...

Anyway, define the attack you want to defend against, define the capabilities of the attacker, and may be able to come up with a solution, but the attack "sufficiently motivated users can copy your art when they see it on the screen" is not something you can realistically defend against without hosting your have only in carefully controlled secure facilities.

On 8/3/2017 at 4:18 PM, frob said:

Why do you think those are the things that need protecting? The art and animation assets themselves are usually among the least protected because there is no significant benefit.

Your encryption rules don't really help much.  Encryption is like an armored car service, it protects stuff during transit but does nothing to protect against those on either end.  

 

By virtue of the way services work the other end is always untrustworthy. I guess the analogue would be for a bank to trust any transaction a customer sends because the transmission is encrypted. It doesn't matter if they're transferring a million dollars into their account from a null account, the transaction is encrypted so all is well. Never trust anything coming from the client. Ever.  All values must be validated before being used.

It seems your concern is to protect the moves people make and the rules of the game. in that case you can make the client into a dumb terminal and only state where the cards are displayed, receiving the clicks they make, and doing all the processing on your side. No need to protect any animations, it is the processing that gets protected by never exposing it to the client.

3

My concern is that since this is a mobile game available on IOS and Android, people will be able to make modifications to the binary and inject code which would allow them to bypass the IAP functionality, therefore gaining full access to the game without paying for anything.

Of course, once they do this, they will put the modified app in the 3rd party pirated/app stores and make it free to download for anyone who wants it.

My goal is to protect the IP and monetization of the game by only allowing users who actually paid to make use of the game in the way they are allowed. If the animation files are encrypted on disk, they won't be able to do anything with the game without connecting to the server and receiving the key. If the key is always sent Just In Time, the animation files will never be decrypted on disk. Through this, only users who paid will be able to use the game for the portion they paid for - until someone is smart enough to read the keys in memory or flush the decrypted animation files to disk.

I appreciate your feedback a lot! I have thought the same thing about making the client a 'dumb terminal' and having the server run the actual game logic. I think that might be the solution, but I still think adding encryption and only allowing the assets to be downloaded after they pay may add an extra layer of protection without too great of a a cost. The reason being is because even if the client is dumb, I think the server logic isn't anything crazy hard to replicate due to the nature of the game. It's not very interactive. Imagine a card game you would play just to watch the visual effects of using the card, like for children to watch cool animations once they play the card. Since there's no actual interaction with the server, creating a server may not be that difficult for someone to do...

On 8/3/2017 at 9:35 PM, hplus0603 said:

What is the attack you actually want to protect against?

 

 

Someone being able to play the game without paying for the IAP assets

"For example, you could pre install all cards, but make the client "dumb" and just send selections to the server, and then only show/animate based on instructions from the server. This would prevent against players "seeing the wrong thing" until players figure out how to write a fake server."

This is a great idea and one that I have also thought of. The problem comes with how simple the 'game logic' is. It's basically just an animation player. Imagine a childrens card game where you could collect cards and then when you played them, a cool animation played. There's no interaction with game logic outside of maybe recording points and such for playing the card, there's no interaction with another player. The premise of the game is to come up with really cool 'decks' which have unique combinations of these animations and then share them with other people.

"Regarding encrypting the assets against "ripping," know that tools exist to slurp textures and vertices out of the graphics card. Because the card needs to render to screen, that data need to ultimately be in decrypted form."

Textures and models - OK. But what about animation files? I haven't read enough yet about tools which allow rips, I'm curious if they have the same thing for an FBX file thats sitting in memory.

"Pays can also use screen video recorders to record the animations and enjoy them whenever they want."

That's OK - as long as they paid for the one they want. The true engagement of the game comes from the social interaction with other players showing each other their pretty/fun 'decks'.

"If you want to encrypt files on disk, there is nothing bad about that per session, but it won't stop a determined attacker. That being said, your actual problem will be getting people to find out about your game, and then care about your game, and then care enough to give you money. Asset ripping seems like a first world problem by comparison -- almost like free advertising..."

    True.. But I have heard horror stories about games having 3x as many downloads for the pirated version in the 3rd party app stores vs the actual paid versions...

Keeping your iOS application un-cracked is really Apple's problem, not yours. Keeping users from rooting their devices is Apple's problem, not yours.

The question is: If you could somehow make the game not work when on the pirate app stores, do you think people would instead pay for your game in the iTunes store, or would they just play another game on the pirate store instead? Similarly, if they REALLY want to play your game, is the price in the app store really going to be a problem for them?

I think you're trying to "solve" something which isn't actually a problem for your profitability or marketing. And if that "solution" means that regular, paying players get worse service (say, the app doesn't work when they're not connected to mobile data/WiFi) then you're actually hurting your own chances.

Note that users capturing the screen will be able to share the screen caps quite easily, so it's not just "users who paid for the card" that see it; it's the entire internet. A much more useful strategy than locking things down, would be to put the name of your game in the lower-left corner of all screens, in an unobtrusive way, so that anyone who sees a shared screen, can see the name of your game.

If it were me, I would spend approximately zero time on solving the rooting/cheating problem, and spending all of my time on making sure the game is worth paying for, and then spending time on figuring out how to tell the world that the game exists and is worth paying for. It will likely have a much higher return on time invested than anti-hacking mechanisms.

damn. Well said. Will think about this and process it some more. I have heard horror stories about apps being pirated but maybe I'm thinking about this completely wrong.

Thanks a million to you guys for your help!

Drew

Yes, games get pirated! And to some extent, this is not great. And if you can lock down your app, there is some gain to be had there, assuming that your game is well known enough that it will have lots of players, and important enough that the players who crack software will actually bother with it.

Another option is to use the piracy as a marketing mechanism. If you update the app every month, with new encryption keys and new content not available in the previous month, then you can use the pirate copies as marketing. When your server tells the app is 3 months old or older, pop up a dialog saying "get the latest version from iTunes to unlock new cool content!" Hackers that hack the app might not find this dialog, and because the time isn't yet that old, the app won't show it until it's spread already.

Will server-side keys plus encrypted files stop a casual hacker? Yes, likely. Will your game be annoying to players if it has no way of being played when in the basement or traveling between coverage areas? Absolutely! Which of these is the bigger problem? Only you can decide for sure.

Mostly, though, piracy hurts small game makers, not because the small games are pirated, but because the big games are pirated. If a game playing pirate can play the big games for free, or play the small games for free, they'll more likely play the big games. If the option is playing the big game for free, or paying a small price for the small game, then the small game can't compete. For users who don't pirate, the equation is instead "play big game for lots of money, or play small game for little money," at which point the equation starts working for the small game developer.

Finally, I will leave you with what I think is the best story about piracy management, out of the release of Game Dev Tycoon.