More questions/topics for experienced devs/publishers

Solar2D General Questions/Discussion
#1

A big “thank you” to all who participated in my last question, it’s been very helpful.

A little background before today’s questions: We’ve had a mobile game pretty much completed (plays well, testers love it, etc.) for several months, and are now deep in the process of - for lack of a better word - packaging it for release. By packaging I mean doing things like setting up servers for the back-end, trying to figure out fraud and cheat prevention, figuring out how to validate server-side that the game was actually purchased, etc.

It should be made clear that this discussion is not necessarily about programming, but rather about the business and logistical end of publishing a game.

So if you followed my last question/discussion, you’ll know that I have moved much of the sensitive processing and storage to server-side, to prevent simple cheats, etc. So far it’s been working great in our testing.

My new model for the game is (was?) going to be that anybody could play for free and they would see ads. If they decided that they wanted to participate in leaderboards and multi-player matches, they would have to register a free account (through the game, stored on the back-end servers). They would still be seeing ads until they purchase the paid version of the app, but they could enjoy the multi-player, etc. The servers would do things like track sessions, log prior sessions out automatically if a new session started for that login to prevent account sharing, etc.) So that’s all working well now.  

Here is the meat of today’s discussion/question:  By adopting this new approach it solves several potential issues (see prior conversation). But overnight a terrifying thought struck me… it is fairly trivial to analyze the network traffic and see how our servers operate. If someone wanted to clone (or even just imitate) our game but didn’t want to set up their own servers (or didn’t know how) and simply kept sending info to OUR servers, there’s no real way to be sure that the traffic is coming from OUR app. Which means not only would we be assisting the cloner with their copy of the game, but would also be incurring expenses for bandwidth, etc. and losing profit.

So far, I can’t think of any way to ensure that the traffic coming in to the server is from a legit copy of our app UNLESS we change our strategy and allow participation in leaderboards and multi-player ONLY to people who have purchased the paid version of the app, and then as part of each login we’d re-do the receipt check with Apple or Google to confirm. This is not my preference because I’d like to allow people to play the multi-player game without purchasing in exchange for seeing ads, but now it looks like it may not work based on this reasoning about the servers.

Does anybody have any ideas on how to restrict/validate traffic to servers without doing what I described above?

On a side note, does anyone know of any books or websites that help new publishers navigate these type of non-programming game app decisions?

#2

I can’t see this being something that anyone would actually try, but can’t you send an encrypted string with each request that only your app and the server has the key to? 

#3

Certainly, but the ol’ catch-22 rears its head here… decompiling (technically it’s more of a decoding) a Lua app is trivial, so there’s no real way to hide the encryption key (or your source code) from someone who downloads your app. 

Unless you know a way to keep a text string hidden? (If you do, I think many people here - including me - would be very happy to hear about it).

#4

To be fair if someone’s going to go to that much trouble to code a clone, figure out how your API and encryption works, while all the time hoping you don’t change the API and completely break their app then good luck to them.

#5

I guess the problem is that if they simply decompile and clone the app, they don’t have to figure out ANY of the server API or encryption, since they’d be looking at the source and could easily see how it’s done. Or they could just use the code as is, replace all of the art, and throw it up into app stores without any other mods.

But I get your point, and it’s definitely valid.

This may be a problem without a real solution, in which case I think my only option is to force people to actually purchase the app and do the receipt validation, but it sure would be nice to let them play instead with ads and know that we’re not getting scrogged.

#6

My opinion on this never changes and I am not the only one that follows this train of thought (so I am not a radical). The time spent worrying about people stealing your game/app before it is even economical viable is better spent making the game the best game you can possible make or spending that time and effort in marketing. If it is successful people will find ways to clone it either by reverse engineering it or by decompiling and making their own. If it isn’t successful then it doesn’t matter who clones it. And sometimes cloning is good for the original maker. (Ketchap clone of 1024 was also great for the original 1024).

But alas if you do want to go down this route, I would create a hash of some of the lua files (important files) and something returned from the server. Anything that you might think would be required a  change for them to make a profit on your behalf. I would also have as many of the lua files on the server using something like patcher (in the marketplace) and every day I would modify those files on the server so that the base for the hash would change.

  1. App starts.

  2. Server puts a timestamp on the file. Sends it to client on loading.

  3. Hash of file + timestamp of server = matches hash on server.

  4. Good app.

  5. Doesn’t match show some sort of message.

If they decompile your app some key files will be missing or if you are using patcher they will be stubs. 

A clever hacker will be able to pull those files from memory while the app is running. Figure out your scheme for the hash and then do it every morning to update the hash so he can play.

#7

Thanks, Agramonte. I agree with what you are saying, as well.

However, if someone clones an app and starts to sell it, that (theoretically) erodes the audience for our game… that constitutes lost potential sales. But it’s actual, real-life cash out of pocket if someone is abusing my servers and bandwidth and I have no way to tell if the traffic is legit.  :slight_smile:

I was not aware of the patcher plugin, that could definitely help! I am not sure how app store rules might apply to an app that self-patches. so will have to research a bit. But THANKS for your input! 

#8

I harrassed xedur a bit after the last big thread and he had a cool idea that the best security systems are the ones you dont know you tripped. Like if you have a game that checks for cd and refuses to play if the cd is bad, then people people know they got caught and they can just crack that. but if the game sees that the cd is bad and doesnt crash there, but just disables something with a delay then the hacker wont realize he got caught. This forum needs ping feature to call people to answer here. He had some ideas about this stuff that were great

#9

Agreed. Other systems I’ve created give the appearance that all is well but it essentially cuts the user out of things (like letting them see comments they’ve posted but not showing them to anyone else).

These are all good discussion points and I am enjoying this conversation, thanks again to everyone.

My main concern in this particular thread is not so much about the app itself, but rather about protecting the back end server by validating that the app contacting it is ours.  :slight_smile:

#10

@agramonte - I like your patcher idea!  I bought everything @RG put on the marketplace but I actually never implemented patcher - I’ll have to give that a shot.

This is great discussion by the way so thanks to @coronasdk66 as well!

#11

As @pixec said, we discussed several means of protecting one’s app, but as people have already pointed out again, as soon as the user has physical access to your app, then all measures ultimately fall short. It’s really about how much time and money you want to invest in protecting your assets and whether or not it’s all even worth it.

The very best techniques rely on not being noticed, at least not immediately. If you slam the door on their face instantly, they’ll see where the issue is and they can get around it easily if they have the knowledge and the know-how, but if they can’t be absolutely certain as to what caused the service to fail or whether it failed at all? Now that’s better.

One famous example is Game Dev Tycoon. Its developers released a version of their game on torrent sites where, as the game progresses, more and more consumers begin to pirate the player’s fictional game up to a point where they will inevitably lose due to piracy. Now, people didn’t realise that they had run into DRM and that they were the butt of the joke and that is why it was so effective. It also doubled as marketing, which is rare for any DRM.

If you want to protect your APIs from misuse, then you need to assign each user their own ID and/or key so that if you detect that someone is not a legitimate user, then you can ban them from your service either instantly, or with a delay, or you can mess around with them. Again, the more elaborate, the more expensive it is to setup and maintain.

Now, if you’ve read up to this point and you are waiting for the answer, then I’ve got some bad news for you. If your server works in a way that it will give access to anyone with the right key and if the cloned app has access to your keys, then that’s it for the security I’m afraid. You can send files and hashes, but if the app has everything it needs to work with them, then even the most brilliant idea becomes a moot point.

One simple thing that you could do is to always send your app’s version to the server, i.e. system.getInfo( “appVersionString” ), and verify that this in fact matches with version numbers that you’ve used for your app. If you receive a connection where the app version doesn’t match with any version that you’ve used, you immediately know that it is not one of yours. Then again, if you receive connections from outdated apps, you’ll prompt them to update their app, i.e. the cloned app has to keep up with updates. However, you can make it so that the server doesn’t block the user with an outdated version, but your app just opens some popup that a legitimate user can’t close. A cloned app could edit the code slightly to disable the popup, so it’ll play, and then you’ll know that if an outdated app got past the initial verification process that it’s not one of yours, etc.

Really, there’s no silver bullet with app security. Version checking is simple and cheap to do, and requires at least some extra effort from whoever is copying your app, if someone is copying your app.

#12

Another good answer, thanks.

I do believe that there IS one solution, and I outlined it in my initial post… that is to modify the game such that all of the juicy features are available ONLY if the server confirms the app store receipt whenever the user logs in. 

So the choice is whether to allow non-purchasing players access to ‘advanced’ features like multi-player matches and leaderboards (which in turn opens the potential scenario I described above)  or to only allow those features to people who have legit purchased.

I hate to take the multi-player /leaderboard experience away from the casual player, especially if I am generating at least some revenue from ads… so I guess the path I will take is to allow non-purchased players to freely enjoy the experience of multi-player. I’ll incorporate some of the suggestions from this thread just to make it more of a hassle for those who would attempt to steal server bandwidth/CPU/storage, along with some other things I have not divulged here. I will also then create some stats/reporting to monitor specific data points to get a rough feel for whether hanky-panky is occurring.

As always, thanks for the discussion. As a (mostly) solo dev, it’s great to have a community to discuss these topics.   :slight_smile:

#13

As a general rule, in F2P, everyone should have access to everything but if they pay they should get a better experience.  Things like no wait times, increased coins, etc.