You can generate a SHA256 hash.
I can also generate md5, sha1... my own hash algorithm. But the question is: what or who will verify the hash when my swf file will be compromised ? User ? Flashplayer ? Browser ? Another swf file (can be compromised too) ?
I don’t think there is a perfect solution. You can only make it more difficult to get hacked.
Usually, folks implement security by making sure they don’t serve data to swfs not served from their domain. Then it doesn’t matter if you are running a hacked swf.
I can't agree that hacked swf is not problem. The problem may be, if attacker add logger into swf which store users activity to other server. It can wait and log users credentials or modify users inputs, it can also be a proxy - I can imagine many scenerios. When you're talking about games, banners... ofcourse, it doesn't matter. But on banking or goverment field this could be a big problem.
OK, so options are:
1) Belive in https/ssl
2) Obfuscate swf the code to prevent decompilling
3) Create a heavy obfuscated loader, which will load other modules and verify its hashes
5) maybe something like 3) or 4) exists, so usage of proprietary solution
Any others ?
The classic simple configuration works as follows and assumes the goal of the SWF is to display and possibly edit important information on a server.
1. Server at www.mycompany.com
2. SWF at www.mycompany.com/myapp/myswf.swf
3. Wrapper html at www.mycompany.com/myapp/myswf.html
The idea is that your users should be using myswf.html to load myswf.swf and call the server at www.mycompany.com. Unless you have a breach in your server security, anybody who copies your swf and hacks it would theoretically need to host that swf on a different server, such as www.evil.com. There is hopefully no way for the evil person to install the evil swf on your server. Therefore, the best the evil person can do is send a potential victim a link that may read as www.mycompany.com/myapp/myswf.html but actually links to the swf at www.evil.com. IOW, they’d embed a link like this:
This would in turn load the hacked swf at www.evil.com/myapp/myhackedswf.swf. The way Flash Player Security works, when the hacked swf tries to access the server at www.mycompany.com, the player will first check for a crossdomain.xml somewhere on www.mycompany.com. If that crossdomain.xml file does not permit access from www.evil.com, the request for data is denied, effectively neutering the hacked swf.
This scenario seems to be secure enough for banks, governments and large institutions, otherwise, Flash Player would not be used for any serious web applications.
No matter what you do to the SWF itself, or the wrapper that loads it, if someone fools the user to logging in to a completely different server/swf pair, they can certainly steal credentials.