Question

i’m using AMFPHP to stream content from my server to my Flex application, since Flash is a clientside technology i would like to make it harder for people to grab protected files, so i created a system that streams swf file to another flash player, i’ve done all the testing on URL stream, now i want to pass the swf file to the player as bytearray .. since i think it’s safer and harder to break and in the future i even might do some encryption of my own if i became more familiar with bytes and bits .. anyways is my method the best one? (SWF to ByteArray?) or is there a better one? if the bytearray method is the best, i am facing a problem in outputing the swf file in the right format, i’m using a very primitive method ..

        $file = file_get_contents($file); 
        $byteArr = str_split($file); 
        $byteArr = array_map('ord', $byteArr);
        $return['fileBin']->data = $byteArr;

and i return the $return variable …

your help is highly respected and appreciated.

Rami

Answer 1

Hm…

I use something very similar currently (I’m developing an MMORPG…) – I decided I needed the content of the game preloaded so the player doesn’t have to wait so much. Unfortunately – These files would be easy to just browse and even decompile.

Because of that I made a custom compression+encryption combo that needs a password. This password is sent by the server when needed.

However, in your case this is not the best thing to do. ByteArray is not anything hard to break – essentially it will send raw byte data. Unless of course you encrypt it (+1).

Another good thing to do would be to tokenize the requests (+1). I.e. in PHP you generate a “token” and write it to a token-list file. The token would be something like 32 alpha-numerals. This token would also be passed to the SWF object / page requested, which would immediately use it in request. The request works ONLY with a valid token, that is, one that was recorded in the token-list. When it is used, it is removed instantly. Also, there could be a time limit on each token. Like 15 or 20 seconds. If it is not used by then, remove it. User-side (if loading too long) would need to be reloaded (although not manually – can be some script, or iFrame to reload just the SWF) if time limit was exceeded.

EDIT : the author of the question asked differently – his aim is apparently to make the SWF file requested reachable / loadable ONLY by the loader application. Nothing else. So:

I’m afraid this is a hard thing but… It’s not really possible to make something impossible to crack / hack into. Fortunately it is easier to do in networks (although they are attacked more often) or internet. You CAN’T make something that can be loaded only by your application. If you think about it – it is impossible even logically – in both cases (user-requested AND application-requested), the user computer requests one file, and it is easy to track that request and replicate it or to simply intercept it. Decompilation of SWFs would be used if any of the former two doesn’t work. A little bit about countering all possibilities:

A) track and replicate

This is easily doable with such tools as Firebug on FF, or equally good (really) Inspector on Safari. With these, it is easy to see what was requested, the headers and response (luckily it is not possible to download the file requested – it is not recorded as long as it is not html or plain text MIME), also the response headers.

There is no use in obfuscating the request URL in code, if it will ultimately be shown as requested in the console of one of these tools. Solutions would be:

1. make the request one-time only (shown above – tokenization)
2. use a special header for the request, such as “Connection: keep-alive” – this makes it quite harder for normal attackers, because they will often just copy the URL and request it in browser – but the connection there will be automatically “Connection: close”, check for that in server-side code and accept only the keep-alive (or your “special”) requests
3. use a protocol different from HTTP – unfortunately this involves server-side socket functions for communicating on different ports than HTTP’s 80… most server providers don’t let users do this, but if you can – and want security – do it – don’t use any known protocol, but rather something that suits just your need – after all, you control both server-side and client-side, so the communication can be done anyhow

B) interception

It is a little bit higher-level attack – but if the attacker is skilled and has SOME resources, not so hard to do. Essentially this comes to having a proxy of kind (hence the resources – need for a server with sockets enabled, which I myself have :D), that he will use to connect through with his browser. The proxy will, however not only forward content, but at the same time record it. Countering:

1. use different protocol
2. encryption of that protocol – because even if the data is recorded, it doesn’t matter – it is no longer just HTTP headers followed by raw file data (the headers are easily removed and “violá”) – only the client-side application knows how to use this data

C) decompilation

This isn’t even so hard to do – SWF decompilers are not anything new now, and any code from your application is freely available to the attacker. Even if you use different protocol, the attacker can, with less or more effort, break into it. Solutions:

NONE – you can just make it harder for the attacker – obfuscate your code, have a lot of it (if you really WANT the security… chaos might just be your friend), use cross-client cross-server requests for the actual code – dynamically loaded secondary SWFs that load the code…