Re: Securing Flash Games.

[Michael Tartre <mtartre () gmx com>]

I hate to bring up kind of a dead thread, but I think I have a nice  
approach for this:

Because the calculations are happening on the client side,  
theoretically you cannot prevent a user from faking a "perfect score"  
between reports to the server.  But you can address the specific  
concern of uneducated memory editing.

The cheat program referenced assumes the data is in integer format.   
Flash is very flexible with memory types, so you could do:
 obfuscatedVar = new String();
 varInput = 10; // or any int
 obfuscatedVar = Math.round(Math.rand()*1000)+";"+varInput;

To obfuscate the variable, then:
varInput = (obfuscatedVar.split(";"))[1]; //should auto-typecast back  
to int

To recover before using the variable.  "Secure" the variable back into  
obfuscation whenever it's changed client side, then bring it back into  
your variable name before use.  (To make it a little uglier on  
decompilers and a bit more modular, you could package a set of this  
calls into a "obfu" and a "deObfu" function and call and put the  
functions in weird movie clips and call them from there.)

While obfuscation is not security, here's what this will do:
 - for that memory cheat system that you specifically brought up, it  
will find "varInput", and user might try to change the value, but that  
value gets reset to the obfuscated value.  Ultimately, without knowing  
your data structure, it will be impossible to access or cheat.
 - let's say they disassemble your Flash code.  Flash code is very  
ugly when disassembled, at least using the freeware disassemblers  
(hey, I'm a student; I'm cheap).  Now, even though they know your  
datatype, they still can't search for something exactly in memory  
because of the randomness in the salt string.

So I'd say this level of obfuscation is pretty good; without a  
disassembler, someone at a cheat engine could spent hours editing a  
useless value and get nowhere.  This is much more scalable than using  
server-databases for constant updating, and not much less secure  
(since, as said above, they could just mimick your protocol).  Again,  
this is just obfuscation and not real security, but the client  
technically has full permissions to the data you want to protect so  
you can't really hope for security (barring placing all the  
calculations server-side).  So for most applications, this should be  
more cost-beneficial.

I am kind of curious what flash game requires a high level of  
security...

Good luck and happy coding,

Michael


On Dec 11, 2008, at 3:23 PM, Murda Mcloud wrote:
> This has me wondering whether it is 'illegal' or 'unethical' to hack  
> these
> kind of games(non money/fun type) when they are running client-side.  
> I mean,
> I don't know whether many of the ones I have played have any kind of  
> EULA
> which says you can't do this kind of re-engineering. The bigger  
> games may
> well have but not the smaller games that you see at miniclips and  
> the like.
> (Not that I remember at least)
>
> When it comes to gambling games then the money incentive will make  
> sites a
> bigger target I'd guess-as Dan points out-but the illegality of that  
> seems
> so much more obvious.
>
> > > -----Original Message-----
> > > From: listbounce () securityfocus com [mailto:listbounce () securityfocus com 
> > > ]
> > > On Behalf Of Dan Crowley
> > > Sent: Thursday, December 11, 2008 7:45 AM
> > > To: security-basics () securityfocus com
> > > Subject: Re: Securing Flash Games.
> > >
> > > Flash, being a technology that runs on the client side, will  
> > > always be
> > > subject to modification. Consider all data coming from the  
> > > application
> > > to be tainted.
> > >
> > > Furthermore, any sort of encryption that you use will be difficult  
> > > (if
> > > not impossible) to enforce. Any algorithm or key used will still be
> > > stored in the flash file, and all it takes is some reversing to pull
> > > it out. All of a sudden, users can send messages as if they were the
> > > flash game, using your encryption key and algorithm.
> > >
> > > Even worse, there are more considerations than the strength of the
> > > encryption scheme. Let's say, for example, that you have a flash  
> > > poker
> > > game. For the sake of argument, you find some way to make the
> > > encryption scheme impossible for the user to break. Then, a  
> > > malicious
> > > user (Let's call him Mallet) decides to run a packet sniffer on his
> > > machine. Mallet picks up the packets his computer sends to the game
> > > server. He's down $300, and finally manages to win a piddly $5 back.
> > > Mallet then isolates the packet sent after winning those $5 and  
> > > sends
> > > it again. And again. And again, ad nauseum, until he's doing very  
> > > well
> > > indeed at poker. There are ways to prevent this, but still...
> > >
> > > Put as much of the process on the server as possible. As long as the
> > > logic is on the client side, it will never be secure.
> > >
> > > --
> > > Dan Crowley
> > > "One machine can do the work of one hundred ordinary men. No machine
> > > can do the work of an extraordinary man."