Secure API for awarding points when playing games

[miraclemaker]

Is anyone aware of a third party system that allows you to award points to a player as they player a game?

This points system would be implemented across all games on a site, and the user would then be able to use these points to get other goodies. Similar to how Pogo works if you seen it.

Any advice much appreciated.

Thanks.

[LeechmasterB]

Is anyone aware of a third party system that allows you to award points to a player as they player a game?

This points system would be implemented across all games on a site, and the user would then be able to use these points to get other goodies. Similar to how Pogo works if you seen it.

Any advice much appreciated.

Thanks.

I am doing something similar to this for an assignment, if you want i can show you the stuff once there is a basic framework. Although at the moment i am preparing a game to test it with.

greets

[miraclemaker]

Any info you can give me would be great, but I was hoping this is a subject that's already been tackled and there's something ready-made out that that I can licence.

It's potentially a huge subject, you have to protect against code being decompiled, replay attacks, memory values being altered etc

[SaphuA]

Having most of your stuff done serverside is the most secure. However since you can change variables that Flash sends I wouldn't know how to secure those. You can't use encryption in Flash since you can easily decrypt those vars aswell.

Hope to get some decent replies here so I can learn something =)

[LeechmasterB]

First off, it is really hard to find information on how to protect the game, since most developers are scared of letting out their secrets and thereby may be helping the hackers/cheaters.
Here are some rules of thumb when it comes to cheating, derived from an article by Matt Pritchard (AoE, AoE II).

Rule #1: If you build it, they will come -- to hack and cheat.
Rule #2: hacking attempts increase with the success of your game.
Rule #3: Cheaters actively try to keep developers from learning their cheats.
Rule #4: Your game, along with everything on the cheater's computer, is not secure. The files are not secure. Memory is not secure. Services and drivers are not secure.
Rule #5: Obscurity is not security.
Rule #6: Any communication over an open line is vulnerable to interception, analysis, and modification.
Rule #7: There is no such thing as a harmless cheat or exploit. Cheaters are incredibly inventive at figuring out how to get the most out of any loophole or exploit.
Rule #8: Trust in the server is everything in a client-server game.
Rule #9: Honest players would love for a game to tip them off to possible cheating. Cheaters want the opposite.

Table 1. Cheating classifications:
- Reflex augmentation
- Authoritative clients
- Information exposure
- Compromised servers
- Bugs and design loopholes
- Environmental weaknesses

Now when it comes to flash, it’s a quiet more tricky issue. At least when not dealing with 3rd party tools to enhance security flash is pretty weak when it comes to security as it can easily be decompiled.

Here is a short summary on how to make your game more secure:

- Use a fat/heavy server side architecture.
- Obfuscate and make your game hard to decompile, unfortunately its doubtful that you will manage to prevent decompiling at all. But at least you can make it harder for them.
- Use a secure connection when communicating with the server.
- Encrypt the data you send.
- Limit access to local access (you only want clients to be run on your site)
- Timestamps
- Dynamic command syntax dynamic (random seed)
- Add command verification to the processing steps
- Encrypt important variables when storing them (within the game).
- Dynamically reallocate / change position in ram
- Use 3rd party tools for more security

Hopefully this is already of use to some of you.

[webgeek]

My blog has lots of stuff on various techniques to make hacking Flash a lot harder.

mikegrundvig.blogspot.com

Just look at the security tag.

[LeechmasterB]

My blog has lots of stuff on various techniques to make hacking Flash a lot harder.

mikegrundvig.blogspot.com

Just look at the security tag.

Thats just awesome! Thank you very much for this contribution!!

Basically its got all the necessary stuff as examples which i mentioned in my earlier post. Very neat and a perfect example on how to protect variables in memory and do ssl and validation ect. Once i can start with the implementation it will come in very handy.

greets

[webgeek]

Glad it helped out. Feel free to ask any questions here and I'll see if I can answer them. Thanks!

[miraclemaker]

Guys this is a really great thread we've got going here. Thanks for all the great contribution. I was hoping that there is a 3rd party API to cover this kind of thing but if we end up having to come up with our own solution this information will be extremely useful.

The big problem with tryign to do this kind of stuff with flash is that the games all run client side so the hackers / cheaters etc have complete access to the application, memory space, communication to and from server etc, making our job extremely difficult.

[webgeek]

The big problem with tryign to do this kind of stuff with flash is that the games all run client side so the hackers / cheaters etc have complete access to the application, memory space, communication to and from server etc, making our job extremely difficult.

Communication can be encrypted using various techniques even with the client source code available. You just need to use a key generation technique like the Diffie-Hellman Key Exchange.

Memory space problems can be addressed by encrypting all critical variables in memory. My blog has source code to do this with a random key cipher.

To prevent access to the application itself, you can use the Loader + Socket technique that has been mentioned a bit lately. We are integrating that into the security model of ES4 very soon.

[tidenburg]

can't php just see where the data is coming from? That would be better, adobe and php need to integrate to make a verification to see if the data is sent from flash.
$_FLASH_POST['name'];
that would make this whole thing soo much easier

[Chookmaster]

My blog has lots of stuff on various techniques to make hacking Flash a lot harder.

mikegrundvig.blogspot.com

Just look at the security tag.

Hi,
Just looked at MemoryCrypto - it looks pretty cool.
May I suggest using integers instead of strings for ids?
private static var scoreId:int = 0;
One more level of obfuscation for no costs.
Or perhaps a cryptovar class:
score = new MemCryptoVar();
score.increment(50)

[miraclemaker]

To prevent access to the application itself, you can use the Loader + Socket technique that has been mentioned a bit lately. We are integrating that into the security model of ES4 very soon.

Do you have any more details on this?

[webgeek]

Just looked at MemoryCrypto - it looks pretty cool.
May I suggest using integers instead of strings for ids?
private static var scoreId:int = 0;
One more level of obfuscation for no costs.
Or perhaps a cryptovar class:
score = new MemCryptoVar();
score.increment(50)

All good suggestions. I really like the CryptoVar idea. Feel free to take my code and re-work it into that. You should post it too, that's very useful

Do you have any more details on this?

Basically, we are implementing just what I described. Via our web admin you will be able to upload SWF files and designate them with a name that identifies them. You will also be able to set permissions and such on the file using our built-in security mechanism. Then when a client connects and logs in, they can ask the server for the SWF by name. The server verifies they have access and streams the swf to the client, the client API will return the byte array representing the swf letting the developer use it as they see fit. This functionality isn't limited to swfs either, it can stream anything you want to the client (images, swfs, text files, whatever). Pretty clean and should work great.

[miraclemaker]

Hello again guys.

I've been doing some further research into using sockets to load in a separate SWF at runtime that will contain the functionality for submitting high scores. The socket server will be written in PHP.

This will give us the benefit of encapsulating the scoring API and not having to have any of it contained within the games. HOWEVER, what's to stop a malicious user creating their own fake client SWF that pulls in the API swf and then proceed to call the functions to submit fake scores?

If anyone has any clever ideas to get roudn this that would be great.

Thanks.

[Industrion]

miraclemaker, this is what I was thinking of, also, but I've kind of lost hope in the whole security issues with Flash. I thought about running a Flash app accessible only via socket server (or just a server app itself), which handles this sort of stuff. Anyone else got any thoughts on this? I'd rather be proven wrong on the subject, to be honest, than come across several loopholes after spending hours of thought on it.