Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


How to verify Mobile Game Client session with JSON?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 shakerx   Members   -  Reputation: 107

Like
0Likes
Like

Posted 07 July 2014 - 02:43 PM

We are creating a turn based multiplayer game in Unity where client data is sent to the server (SSL encrypted) using JSON to update player currency, gear, etc.  We have hit a road block with client verification.  We need to be able to verify the Client application is indeed the Client.

 

For example - to update player gold to 100, the client would send the following URL Request:

example.com/update.php?player_id=1&gold=100&session_id=1234asdf

 

What is to keep someone from calling that exact same address in a browser and changing 100 gold to 10000000?

 

Option 1:

Create session_id based on algorythm stored in client code to verify?

FAIL

When creating a mobile game in Unity for Android, users can easily download the APK and view the source and see the algorythm.

 

Option 2:

Create session_id on server and send to client for later use?

FAIL

A network packet sniffer can intercept session_id being sent back down to the client.

 

In both cases, the above URL can be modified with a spoofed session_id and player gold set to 10000000 instead of 100.

 

Are we stuck with TCP ports for all client / server communication or can we still use JSON? If so, how can we use it securely?

 

Thank you!!!

 



Sponsor:

#2 Nikopol_AU   Members   -  Reputation: 455

Like
1Likes
Like

Posted 07 July 2014 - 05:56 PM


What is to keep someone from calling that exact same address in a browser and changing 100 gold to 10000000?

 


 

What is to keep someone from calling that exact same address in a browser and changing 100 gold to 10000000?

 

What is to keep someone from disassembling your client and sending the same 1mil gold request from Client itself?

 

Number One Rule:

never trust a client

 

The solution to your problem is to change protocol from:

 

Client: "I opened this chest and now I have 100 more gold"

Server: "Ok"

 

to something like:

 

Client: "I want to open this chest".

Server: "You succeeded. This chest contained a treasure. You now have 100 more gold".

Client: "Ok"


Edited by Nikopol_AU, 07 July 2014 - 05:57 PM.


#3 shakerx   Members   -  Reputation: 107

Like
0Likes
Like

Posted 08 July 2014 - 10:16 AM

Thanks for your reponse!  It is very helpufl.

 

To follow up, how do we trust the client when it asks to open the chest?

 

For example, in our game there are battles where the player battles the computer and then reports to the server success or failure.  We can modify the reward logic (as you suggested) to all be server side; however, we still have to 'trust' the client's battle success or failure response.  Any ideas?

 

Thanks again!



#4 hplus0603   Moderators   -  Reputation: 5519

Like
3Likes
Like

Posted 10 July 2014 - 10:25 AM

We need to be able to verify the Client application is indeed the Client.


You cannot. The game world is littered with corpses of games that thought you could do that. This forum is littered with threads from otherwise smart engineers who thought they could do that.

how do we trust the client when it asks to open the chest?


You either run a simulation on the server side, that makes it possible to verify that the player is, in fact, close to the chest, OR you design the game play such that it doesn't really matter whether the player is close to the chest or not -- perhaps chests are only generated once the player completes some other checkpoint, and you assume that it's supposed to be openable after that.

the player battles the computer and then reports to the server success or failure


If you want this to be cheat proof, then you need to run a simulation on the server that verifies that the player did in fact get the result.

The other alternative is to focus more on the game being fun, and don't worry about the cheaters. This works for single-player experiences; not so much for multiplayer.
enum Bool { True, False, FileNotFound };

#5 fastcall22   Crossbones+   -  Reputation: 4376

Like
0Likes
Like

Posted 10 July 2014 - 12:19 PM

example.com/update.php?player_id=1&gold=100&session_id=1234asdf


If, and only if, the URL is generated by the server and then sent to the client, then you could use a hash to confirm that the URL hasn't been tampered with:

$url = 'http://example.com/update.php?player_id=1&gold=100&session_id=1234asdf';
$url .= '&hash='.secret_hash($url);
print $url;
http://example.com/update.php?player_id=1&gold=100&session_id=1234asdf&hash=0123456789ABCDEF

If a malicious player were to change the gold, then the hash wouldn't match on the server and the request would be denied.
Again, as hplus has suggested, it would be better if the URL described an action a player is doing, rather than "raw game code".

Edited by fastcall22, 10 July 2014 - 12:20 PM.

c3RhdGljIGNoYXIgeW91cl9tb21bMVVMTCA8PCA2NF07CnNwcmludGYoeW91cl9tb20sICJpcyBmYXQiKTs=




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS