The term Flash can include any of the other terms defined below, and I find that saying "Flash" without specifying exactly what you mean can be confusing and misleading. Case in point: I'm not sure what you specifically mean when you say "Flash" in your question. Is it Flash Player? The authoring tool? Or the whole collection of technologies that fall under what Adobe calls the "Flash Platform"? To help clear all this up, let me define the technologies involved in creating Flash and Flex content so that we're all using the same terminology here:
Flash Player is a runtime for rich media content in the browser. There is also Flash Lite to run Flash content on older or low-end mobile devices, and Adobe AIR extends Flash Player to allow content authors to publish native desktop and mobile applications that can integrate with things like the file system, windowing systems, and device sensors like the accelerometer and camera. Collectively, Adobe refers to these as the Flash runtimes.
Flash Professional (often called the Flash authoring tool or the Flash IDE) has traditionally been the primary application used to create content that runs on Flash Player. It is very designer oriented with timelines, layers, and visual drawing tools. Software developers may find this application disorienting and limited compared to other development tools that focus more on code, like Flash Builder (see below). When someone says, "I built something with Flash", they often mean the Flash authoring tool, but that's not always the case. For that reason, it's good to always clarify to avoid any confusion.
ActionScript is the primary programming language supported by Adobe to target Flash runtimes. The current version is ActionScript 3 (abbreviated as AS3), which has been supported since Flash Player 9. Content created with older versions of ActionScript can still be run in the latest versions Flash Player, but new features are only supported when using ActionScript 3 to create new content.
Flex is a collection of technologies designed to create rich applications that target the Adobe's Flash runtimes. Though saying "Flex" previously had the same ambiguity as "Flash", the Flex brand name is becoming more and more focused on the Flex framework and SDK, described below.
The Flex SDK consists of compilers, a command-line debugger, and the Flex framework. The included compilers are:
1. MXMLC, an ActionScript and MXML compiler to output the final SWF file for deployment to Flash Player.
2. COMPC, a static library compiler for ActionScript that outputs SWC files.
3. ASDOC, a documentation generator built on the compiler technology.
The Flex framework is a collection of ActionScript classes designed to build Rich Internet Applications. It includes things like user interface controls, web services and other connectivity classes, formatters and validators, drag and drop, modal windowing, and component states. These classes are in the mx.* package. Generally, when developers say "Flex" without any clarifying information, they mean the Flex framework and not the product formerly known as Flex Builder.
In 2011, Adobe donated the Flex SDK to the Apache Software Foundation. It is now called Apache Flex and it is fully managed by the community rather than Adobe. However, Adobe employees continue to contribute to the project, and Flash Builder (see below) continues to support new SDKs released by the Apache Flex project.
MXML is an XML-based markup language used by the Flex compilers to make layout and placing components into containers easier. The tree-like structure of XML make the containment hierarchy easier to visualize. MXML is actually converted to ActionScript during the compilation process.
Flash Builder (formerly known as Flex Builder) is a development environment that allows developers to build different project types to create SWF files that are deployed to Flash runtimes. It is built on the Eclipse platform and is more familiar to software engineers. Flash Builder supports projects built with Flex or pure ActionScript. Flex projects include the Flex framework. ActionScript projects are the most basic you can work with, starting with a single class and an empty canvas, and the Flex framework is not included.
Flash Builder does not replace Flash Professional. Some people who have traditionally used Flash Professional may now choose to use Flash Builder instead. Often, these are software engineers who appreciate or require the advanced development tools offered by Flash Builder or don't work heavily with assets designed in a visual tool. Some developers may write their code in Flash Builder, while choosing to compile their projects in the Flash authoring tool. Often, these developers are also designers, or they are working with other people who are designers. In this situation, there may be many graphical assets created in the Flash authoring tool, and it could be difficult or simply inappropriate to bring them into another environment.
The Flex framework is specifically designed to build applications. It includes many traditional form controls (buttons, lists, datagrids, etc) and much of the code runs on an advanced component framework written in ActionScript. Not everyone is building the sort of content that Flex is designed to create, and Flex does not replace traditional Flash development practices for everyone. It is a better approach for some developers, but may not be right for others. More design-heavy websites, such as those created for movies, music, energy drinks, advertising campaigns, and things like that probably shouldn't use the Flex framework. These types of content might be better suited to Flash Professional or a pure ActionScript project in Flash Builder. Similarly, little widgets you put into the sidebar of your website or on your profile in a social networking website may need to be built with pure ActionScript (without the Flex framework) because they require a smaller file size and they probably don't need a big complex component architecture designed for larger applications. When targeting Flash runtimes, your development environment, frameworks, and workflow should be chosen based on your project's requirements and goals.
This is a classic problem with Internet games and contests. Your Flash code works with users to decide a score for a game. But users aren't trusted, and the Flash code runs on the user's computer. You're SOL. There is nothing you can do to prevent an attacker from forging high scores:
Flash is even easier to reverse engineer than you might think it is, since the bytecodes are well documented and describe a high-level language (Actionscript) --- when you publish a Flash game, you're publishing your source code, whether you know it or not.
Attackers control the runtime memory of the Flash interpreter, so that anyone who knows how to use a programmable debugger can alter any variable (including the current score) at any time, or alter the program itself.
The simplest possible attack against your system is to run the HTTP traffic for the game through a proxy, catch the high-score save, and replay it with a higher score.
You can try to block this attack by binding each high score save to a single instance of the game, for instance by sending an encrypted token to the client at game startup, which might look like:
hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))
(You could also use a session cookie to the same effect).
The game code echoes this token back to the server with the high-score save. But an attacker can still just launch the game again, get a token, and then immediately paste that token into a replayed high-score save.
So next you feed not only a token or session cookie, but also a high-score-encrypting session key. This will be a 128 bit AES key, itself encrypted with a key hardcoded into the Flash game:
hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))
Now before the game posts the high score, it decrypts the high-score-encrypting-session key, which it can do because you hardcoded the high-score-encrypting-session-key-decrypting-key into the Flash binary. You encrypt the high score with this decrypted key, along with the SHA1 hash of the high score:
hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))
The PHP code on the server checks the token to make sure the request came from a valid game instance, then decrypts the encrypted high score, checking to make sure the high-score matches the SHA1 of the high-score (if you skip this step, decryption will simply produce random, likely very high, high scores).
So now the attacker decompiles your Flash code and quickly finds the AES code, which sticks out like a sore thumb, although even if it didn't it'd be tracked down in 15 minutes with a memory search and a tracer ("I know my score for this game is 666, so let's find 666 in memory, then catch any operation that touches that value --- oh look, the high score encryption code!"). With the session key, the attacker doesn't even have to run the Flash code; she grabs a game launch token and a session key and can send back an arbitrary high score.
You're now at the point where most developers just give up --- give or take a couple months of messing with attackers by:
Scrambling the AES keys with XOR operations
Replacing key byte arrays with functions that calculate the key
Scattering fake key encryptions and high score postings throughout the binary.
This is all mostly a waste of time. It goes without saying, SSL isn't going to help you either; SSL can't protect you when one of the two SSL endpoints is evil.
Here are some things that can actually reduce high score fraud:
Require a login to play the game, have the login produce a session cookie, and don't allow multiple outstanding game launches on the same session, or multiple concurrent sessions for the same user.
Reject high scores from game sessions that last less than the shortest real games ever played (for a more sophisticated approach, try "quarantining" high scores for game sessions that last less than 2 standard deviations below the mean game duration). Make sure you're tracking game durations serverside.
Reject or quarantine high scores from logins that have only played the game once or twice, so that attackers have to produce a "paper trail" of reasonable looking game play for each login they create.
"Heartbeat" scores during game play, so that your server sees the score growth over the lifetime of one game play. Reject high scores that don't follow reasonable score curves (for instance, jumping from 0 to 999999).
"Snapshot" game state during game play (for instance, amount of ammunition, position in the level, etc), which you can later reconcile against recorded interim scores. You don't even have to have a way to detect anomalies in this data to start with; you just have to collect it, and then you can go back and analyze it if things look fishy.
Disable the account of any user who fails one of your security checks (for instance, by ever submitting an encrypted high score that fails validation).
Remember though that you're only deterring high score fraud here. There's nothing you can do to prevent if. If there's money on the line in your game, someone is going to defeat any system you come up with. The objective isn't to stop this attack; it's to make the attack more expensive than just getting really good at the game and beating it.
Best Answer
I've only found one solution, and that's using the NetStream object in combination with a video control.
The video control must be manually added to an
Finally, the event status is returned in nsListenHandler:
Only this code wont do is tell you if a stream is already successfully being published to.