Gaming Your Way

May contain nuts.

goAway, Nephew of SiCo

What do the following things have in comon?


test.swf (5,87 KB)

goAway.swf (8,07 KB)



After my funny little episode with the hacked version of Law of the West I started wondering how to prevent that little pricks that can use an URL changer or decompiler to mess around with my stuff. Above you see what might be a solution. It will not stop someone who really, really wants to see your code from seeing it in the end but it will make it reasonably hard.

So how can you prevent that someone just grabs a decompiler, changes things and publish it back?

Maybe if there is no game inside the swf, at least not directly visible.

This is a screenshot of the library of the goAway.swf. Nice, eh?

Right now goAway is a neat little console app (so you can batch it), that takes an swf, optional a textfile full of vars (so you can check them later from the game itself) and spits out a png.

This can be included in another swf (to be released) and is unpacked after loading - and viola you have your swf again, though it'll be like a loaded swf, so you loose your "root".

There is a lot more security related portential behind this:
- load the png from a server instead of including it.
- use a key to decrypt the png
- create the png on the fly on the server each time with a new key
- store multiple swfs/files in a single png to pack a multi file game into a single distributable swf without a lot of trouble
- and and and

The above swf is just a proof of concept and there is still alot to do on the goAway app in oder to make it useable (maybe a frontend, new features (like dynamic png dimensions, splitting into multiple png files for more security, different ways of reading writing the data into the png (byte order)) not to mention an AS3 class to easily handle the goAway png.

After all I'm quite pleased with the idea, as it makes it quite hard for script kids to mess around with a published flash file with the available tools. Making hacking a game just that little bit harder that is needed to seperate the users from the coders.

And of course SiCo will be used to obfuscate the goAway code ...



Comments (5) -

  • Richard Davey

    10/8/2008 1:28:01 PM |

    I played around with this idea too, but never got around the bitmap size limitation inherent in Flash (my data always created bitmaps much bigger than 2880x2800 (or whatever it is)).

    How do you avoid this?

  • nGFX

    10/8/2008 2:36:04 PM |

    the secret is the png. Your image can be "fairly" small, ie you can store up to 15mb in a png of 2000x2000px (a using 32 bit png)

    Quick example:

    swf size: 6009 bytes, * 1.5 that to be on th save side (because of a png feature)

    ~ 9000bytes, divide by 4 and sqrt that
    ~ 47.43... round that up for a good measure ...
    ~ 50px ...

    to check it reverse: 50 * 50 * 4 == 10000

    So a 50x50px png should be able to contain 10000 bytes.
    I used a fixed 100x100px png for the proof, so that's why there is so much white in the png.


  • Jeff Fulton

    10/8/2008 3:39:33 PM |

    Brilliant! Simply one of the best ideas I have seen on this subject in a long time.

  • nGFX

    10/15/2008 7:01:00 AM |

    Not quite.

    Both things do their job. They prevent kids with an url changer to mess around with your stuff.

    And in case of the encoded png you'll have to have at least the knowledge to code something that reorders the bytes and writes it back to disc.

    It's not safe "safe". (But I already wrote that).


Comments are closed