0

Example, I have a swf file (original) who it loads on a page: www.mysite.com/blabla.swf

Some people use software like "charles proxy" to load a modified local swf to cheat.

I would like to prevent people from using a modified local swf.

Do you think that this code will solve the problem?

1) create a condition in the htaccess : /blabla.swf shows the content of blabla.php

blabla.php :

header("Cache-Control: no-cache, must-revalidate, no-store\nPragma: no-cache\n");
header("Content-type: application/x-shockwave-flash");
readfile("blabla_secure.swf");
ɢʀᴜɴᴛ
  • 32,025
  • 15
  • 116
  • 110
user2699190
  • 17
  • 1
  • 7

2 Answers2

1

You would still be able to proxy around this just as you could before. Users are likely able to cheat even without modifying the swf by viewing the communication between themselves and server and modifying values as they see fit. Ultimately if you are in a position where you have to trust client input then the client can likely find a way to cheat.

There are some good answers in this thread dealing specifically with flash and highscores, but they are applicable for other use cases too: https://stackoverflow.com/a/74841/3709345

kylethebaker
  • 58
  • 1
  • 4
0

There are two steps you should take with the described setup to ensure the integrity of your client-server architecture.

Step 1: protect the SWF. Use a tool like SecureSWF (http://www.kindi.com/) to make sure they will not be able to decompile and modify it.

Step 2: encrypt/protect the communication protocol. Every client->server message should contain:

  • client id: a random string generated client-side on application start, it should not change since the first message which is handshake
  • session id: browser's ssid, or, better, server should generate one on handshake, should not change after the handshake
  • timestamp or count, you need to have a field increasing every message
  • signature, an MD5 or SHA1 hash of important fields or (better) the whole message

Also, it is a good idea to add a salt (https://en.wikipedia.org/wiki/Salt_(cryptography)) that is not sent with the message and is not stored in a plain form (SecureSWF provides string encryption as well, or alternately you can construct the secret data right at the moment then dispose of it so it is nowhere in the memory to capture it).

Then, the AS3 part, that generates message signature, should be heavily obfuscated with Step 1. The main idea behind these actions is to create a non-reverse-engineer-able signing algorithm to compose the messages the server could trust: correspondent pair client id + session id would let server control the client's flow, correct signature would mean that no fields were corrupted in the message while the message itself was generated by genuine client.

Oh course there's never a 100% guarantee, yet the steps above will increase the difficulty of hacking handredfold, the people who just know how to use Charles and decompilers would never have enough knowledge and skill to hack it. Also, hacking that thing cannot be automated. Also, changing salt/algorithm/obfuscation will cost you mere few minutes, while decryption will require a lot of skill and knowledge, as well as hours or maybe days of time.

Organis
  • 7,243
  • 2
  • 12
  • 14