So you want to book a hotel room for $1 and cheat in games? Luckily, if they are implemented in Flash it's really easy. The problem really isn't that Flash can be fully reverse engineered and that when you are deploying a swf, you are actually shipping source code with it. The actual security problem is that you can change the program behavior run-time. And that's bad.
So how do you go about doing it? If you just need to change a few values or jump a few frames inside a Flash app, you can use the Flash ActiveX control's public interface to do that. To do that to a typical Flash game, you just need to check the url where it's loaded from and write your own html page that loads the same Flash movie. Often you also need to pass a few parameters to the Flash movie, so you probably need to trace the http traffic first, which you can easily do for example with this handly little Http Sniffer tool. For more complex cases, such as for replacing methods, you need to build your own Flash movie container first and load the target application inside it. If you are working in Flash 7, remember to lock the _root level of the child application so you don't get any complications. For Flash 6 and older, you can always load the app on some other level than the level 0.
Now there's a couple of things to keep in mind. Flash does have primitive security mechanisms, like the domain sandbox, so movies from different domains are not generally allowed to access the properties of movies from other domains. However, the movies loaded from the localhost are not limited by the security sandbox. So you want to run your own web server or just simply launch the file from your file system. Another thing is that if you want to use Javascript to modify the Flash movie, you need to specify an id for the movie in its OBJECT / EMBED tag. That's it, happy hacking!
I've done this thing, just to test it out of course, a couple of times so I know the approach works. However, I haven't tried booking hotel rooms, as they typically use https to load the Flash movies. The use of https makes it a bit harder, but it shouldn't be impossible at all. Because of this lack of security I wouldn't do any, even remotely security related development work in Flash.
I believe you are misinterpreting how Flash security is supposed to work.
The Flash Player does try to keep content from different domains separate; for example, you can't see the ActionScript variables in a SWF that you loadMovie() from another domain. This guards only against server-based attacks: a movie from domain A can't insert itself into the conversation going on between a user and domain B. This is beneficial both to the user and to innocent domains.
One thing the Flash Player does NOT do is try to prevent client-based attacks. That's because this is impossible to do, and any illusion of such security would be a false promise. If someone knows how to download a SWF and modify it, or run it from their local machine, nothing can stop them. If someone knows how to hack the Flash Player, nothing can stop them. If someone knows how to write a native application that looks marginally like the Flash Player to a server, but really isn't, nothing can stop that either.
This is why all serious Internet security must be enforced on the server. It is always a mistake to trust a client. Anyone can come at your server with any client they wish. If your SWF is checking a password in ActionScript, and then tranmitting a wire transfer order to your bank without the password, and the server is trusting that the SWF has already checked the password, you are making a bad mistake.
Most people who write games aren't very serious about security, so games are often easy to hack. It would be much more surprising and dismaying to find an e-commerce site that doesn't enforce security on the server.
Thank you for your comments Deneb. I believe I'm not misinterpreting how Flash security works, on the contrary I believe I understand it fairly well. You don't need to download the swf, you already have it in your browser cache, and every kid who knows anything about the web knows where the cached files are stored. If you don't, just let the computer find the file from your hard disk. Neither you need to have a hacked version of the Flash player nor have the swf that you are attacking to run on your localhost. It's enough that you run a host swf on localhost that loads the target swf from a valid web server.
I KNOW that the security must be enforced on the server. The question is, does the rest of the world know? My experience is that they don't or they don't care. Would you like me to give some examples of that? The server side security was hardly my point though.
The point and the problem I have with Flash is that you can change the program behavior run-time and that it is extremely simple to do that. While the same would be technically possible if you hacked your Java virtual machine or ran Javascript in your own browser engine, it is just much more difficult. With html pages the idea is to keep the client really dum so you can validate simple value changes on the server. If you need to do complex processing on the client it makes no sense to validate every single value change on the server anymore, so you tend to rely on the built-in security mechanisms of the client engine (OS, VM etc.) being good enough, as is the case with Java as a rich client. Now with Flash you'll get a rich client without any security at all.
Hi there.
Posted by: jon huron at January 1, 2005 04:21 AMYou website is very good!
Posted by: Irina at January 3, 2005 10:45 PM:) Thank you!
Posted by: Alexandra at January 10, 2005 12:12 AMfirst, i want to say" beautiful blog"
second, do you understand the flash security very well?
Posted by: Richard Truman at July 6, 2006 07:51 PM