Cheat Prevention - Secret Key Concept

Post here your questions about the Flash / Flex / Air API for SFS2X

Moderators: Lapo, Bax

User avatar
jpardoe
Posts: 132
Joined: 31 Aug 2009, 20:54

Cheat Prevention - Secret Key Concept

Postby jpardoe » 23 Feb 2011, 14:01

I have been thinking about cheat prevention in multiplayer flash games.

To my knowledge there are two problems.

    Memory hacking - Players can alter the value of gold, for example.
    Swf decompilation - Allows hackers to edit your game code.


To solve the first problem, most of the game logic will be controlled by the server. Therefore, if someone gains 25 gold, the server already knows about it. They won't be able to say "I just got 9999 gold" because the server doesn't care. It handles how much gold you get without being told.

To solve the second problem, there are code obfuscaters, but they aren't a 100% guarantee.

So I have a different concept that I'd like to suggest:

What if you use PHP to generate a secret key based on a password and the current time? This secret key is passed to the SFS server AND the client (as a param). It is uniquely created every time the game page is loaded.

When the user logs in, the secret key from the client is sent to the SFS server, and compared with the server's own secret keys. If there is a match, we know that the client was loaded from the original server, and therefore it should be the original client.

If a player were to tamper with the client, they would be hosting it from their own server, and therefore wouldn't receive a legitimate key from MY server. So when it comes time to log in, the secret key cannot be sent, and would of course prevent the player from logging in.

Can anyone poke holes in this theory?
dingo
Posts: 98
Joined: 27 Jan 2009, 21:34

Postby dingo » 24 Feb 2011, 14:33

So the actual security the hacker has to overcome is how to load the swf on another domain than yours.

If he can load the swf on localhost and fool the key generation script into thinking he's loading from your domain (by spoofing the referrer), the hacker wins.

If he can fool the browser into loading the modified swf from the browser cache, the hacker wins.

So basically it's checking the http referrer. You could probably achieve the same result by getting the entered URL in flash via:

Code: Select all

var url:String = ExternalInterface.call("window.location.search.toString");

and just sending it to SFS2X on login.

I would guess the only true protection is be to let the server handle everything. Poker Sites work this way of course. Any other protection, i would guess, can be hacked. Otherwise we wouldn't have hackers in Modern Warfare 2 ;-)

Btw i checked out some obfuscators, i will be using:
http://www.ambiera.com/irrfuscator/index.html

And about php, unless you already have a php environment, you could also use a simple jython script with the SFS2X embedded webserver.[/code]
User avatar
jpardoe
Posts: 132
Joined: 31 Aug 2009, 20:54

Postby jpardoe » 24 Feb 2011, 14:39

Hi Dingo,

When I refer to the secret key, it will be generated on the server side. In my example, I suggested using PHP although I'm not sure how that would communicate with the server.

Anyway, the basic principle is that the key is generated by the server, and handed to the swf client. The same key is then passed back to the server upon login, and verified.

If the client is hosted on localhost or a remote host, the underlying key generation will be missing, and therefore login will not work.

The only way it could be spoofed is if they figure out how the key is generated, and imitate it.

I've just thought of another way - they could log in on the original site, retrieve the genuine key, and then input that into their hacked client to be sent at login.

Damn...Back to square one!
Rotty956
Posts: 74
Joined: 02 Jan 2011, 15:58

Postby Rotty956 » 15 Mar 2011, 22:07

Couldn't you use the crossdomain to prevent the user from communicating from their local? Or is it possible to spoof the domain by using your host file?
Sparticus
Posts: 227
Joined: 27 Feb 2006, 17:44
Location: Canada
Contact:

Postby Sparticus » 05 Apr 2011, 22:27

Even if they use your file from your server, they can easily edit the memory adresses of the variables in your swf, or even better, they can just substitute the swf in memory with a new hacked swf.

You can never trust anything from the client. No secret key will fix that. Server side checks is the best you'll get
Bathory
Posts: 54
Joined: 17 Sep 2011, 21:47

Re: Cheat Prevention - Secret Key Concept

Postby Bathory » 05 May 2013, 04:50

This is an old topic but I would like to validate a basic idea.

What if the main swf file contains a line that make sure the game is run from http://www.mysite.com. Third grade hacker sees that and removes the line.

But, somewhere in the swf an obfuscated function will produce a checksum based on the actual content of the swf, not the filesize. Maybe MD5 could do that, I'm not familiar with it. While doing a common action in the game, the client send this checksum value over to the server for verification. If there is a mismatch, the servers stops sending crucial updates to the client.

The hacker could still circumvent it by keeping the original swf apart from his modified version only for checksum purposes. Maybe then something else can be done.

Or you would just have to keep updating an unused string in your swf or change the checksum recipe to force him to keep up.
User avatar
Lapo
Site Admin
Posts: 23009
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Cheat Prevention - Secret Key Concept

Postby Lapo » 05 May 2013, 09:38

Yes, this an additional layer of security that could be applied.
At the end of the day the idea here is to employ as many security tools as possible to keep most hacking attempts at bay. There is no silver bullet, but all solutions will improve your overall solidity against cheating.

Recently I wrote a white paper on this subject that digs into the various levels of hacking and how to counteract them.
Take a look in this section of the SFS2X documentation:
http://docs2x.smartfoxserver.com/Overview/white-papers
(see last w.p.)
Lapo
--
gotoAndPlay()
...addicted to flash games
Bathory
Posts: 54
Joined: 17 Sep 2011, 21:47

Re: Cheat Prevention - Secret Key Concept

Postby Bathory » 05 May 2013, 18:08

Lapo, your document is really complete and useful. In the last section you suggest:

Server-side signature: similar to the “token technique” the server could sign each client binary with a special, time-limited signature that will expire within minutes. This
way modified clients will fail to access the server because unable to provide a valid signature.

If you ever have any pointers, link or other document that can explain how the server can sign each client I'd be very interested.

Thank you
User avatar
Lapo
Site Admin
Posts: 23009
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Cheat Prevention - Secret Key Concept

Postby Lapo » 05 May 2013, 20:38

I don't know of any specific tutorials but the idea is relatively simple, you compile the client SWF with one or more temporary values, suppose a String with default value = "1234567890".

When the client gets to your website and requests the SWF file the server will dynamically create a random String token, substitute it to the default value and serve the file. So what's happening is that each client will get it's uniquely signed file.

The random token is added to a database and when the client will connect and login in SmartFox you will be able to check if the client token matches what you have in the database. You can also make sure that the token expires after, say, 5 minutes so that it can be used within a reasonable amount of time since the SWF was downloaded.

This is a simplistic version of the implementation: if you want you can also make it more complex by setting several variables, using different data types and using custom formulas to resend the data back to the server at login time.

The main technical difficulty is to be able to manipulate the SWF from server code. You may use open source libraries for SWF manipulation (I don't have direct experience with them), or create a simple SWF parser that just does the simple bytecode manipulation you need.

cheers
Lapo

--

gotoAndPlay()

...addicted to flash games
Bathory
Posts: 54
Joined: 17 Sep 2011, 21:47

Re: Cheat Prevention - Secret Key Concept

Postby Bathory » 10 May 2013, 17:47

Thanks. So basically I have to find a way for the http server to sign each client before it is distributed and while doing so, store the specific client's key in a database for later verification.

To my understanding it may be difficult to intercept the request and modify the swf before it is served. It must be done outside of the java extension run by SFS, right? Also since simultaneous connections are plausible, the swf should be modified only in memory before it is sent to avoid collisions.

Before I can accomplish something like that, I was thinking about using an open source library (ex: [url]http://www.flagstonesoftware.com/transform/[/url)] with which, from the game controller thread I could modify an element of the swf every 10 minutes. Like the content of a hidden input field that the client will have to send back upon connection. So at worst, a user who downloaded a swf that was about to expire will get a "please hit refresh" message when he tries to connect, he'll have to type in his login info again within the updated swf.
User avatar
Lapo
Site Admin
Posts: 23009
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Cheat Prevention - Secret Key Concept

Postby Lapo » 11 May 2013, 07:26

To my understanding it may be difficult to intercept the request and modify the swf before it is served. It must be done outside of the java extension run by SFS, right?

It's not particularly difficult, but yes it must be done via a servlet in the embedded HTTP server (Jetty) or, if you use another http server, in whatever language it uses on the server side (php, python, c#...)

Also since simultaneous connections are plausible, the swf should be modified only in memory before it is sent to avoid collisions.

Yes the byte data of the SWF file can be cached in memory, yes.

Before I can accomplish something like that, I was thinking about using an open source library (ex: [url]http://www.flagstonesoftware.com/transform/[/url)] with which, from the game controller thread I could modify an element of the swf every 10 minutes. Like the content of a hidden input field that the client will have to send back upon connection. So at worst, a user who downloaded a swf that was about to expire will get a "please hit refresh" message when he tries to connect, he'll have to type in his login info again within the updated swf.

Interesting library! Yes you can use this one to sign your SWF as well.
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X ActionScript 3 API”

Who is online

Users browsing this forum: No registered users and 22 guests