[casual_games] Platform for multi-player Flash games

[Morbus Iff]

> About security - I'm guessing you're asking about if we wrap your SWF
> somehow to protect it from decompilation? The answer to right now is
> No, we don't touch your swf, so it's the developer's responsibility to
> obfuscate or otherwise protect their code. This is primarily because
> we haven't found a good, automated way to do this - if anyone has any
> pointers to possible solutions, they would be much appreciated.

I've been fighting this in my own designs, which:

  * all non-writable gameplay data comes from a remote database.
  * user statistics, writable, are sent from client to database.

Just like high scores, only more so (in my case, I'd be sending back 
logfiles too, which would help me with debugging, rooting out powerful 
objects, and cheating - two players would send back the same logfile, and 
if they didn't match, we can't trust one of those clients/users).

Ultimately, I've yet to devise a super spiffy way - some folks have 
suggested a PGP like key system, but I don't think I want to go that 
crazy. Some things I've thought about:

  * Client is hardcoded with URL and password. Decompilable.

  * Client is hardcoded with URL, and asks server for a key. Client
    then sends key to server for any writable updates. The app would
    still be decompilable, however, so that someone could still find
    the URL, issue their own key request, then data insertion.

  * Key/password is sent along with a normal data client data request
    - there's no separate request or special URL. Ultimately, this
    becomes security by obfuscation, and was abandoned solely on
    that principle.

At this point, the thing I finally settled on was that there's no way 
around the reverse engineering issue, thus, simply and obviously, rely on 
  stronger and automated server checking: compare multiple player logfiles 
(as above - two players play against each other, both clients keep 
accounting logs, and if the logs are different, one client has done 
something naughty) and, should something look suspicious, immediately flag 
both accounts as suspended until an admin can look at it. And the basics: 
any write requests from the client would use both the user's own game name 
and password (as opposed to a fake-able generated key or password), anal 
data checks (this number may never be about 5, no player can ever win 
within 5 turns, no play counts can ever exceed game turn count, only one 
player can win, etc.). I've yet to devise a bunch of checks for two 
players working in tandem (faking BOTH logfiles) but, for this particular 
game, I'm not entirely sure if that would create an exploitable hole.

-- 
Morbus Iff ( you are nothing without your robot car, NOTHING! )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus