The eternal question about how to protect an online SWF file


seen here

How can i protect my swf from decompilers?

Simple answer would be:
you can try but it will probably fail, so don’t.

A more elaborated answer would be:
you can try but it is unlikely to cover 100% of the cases and it will take a lot of efforts.
It’s not impossible but it will really take a lot of hard work and unlikely to block 100% of all the “vilains”.

Simply put, it’s a whack-a-mole game and there is no silver bullet or other “magic solution” at the click of a button.

Still, you can make it really really hard for someone to decompile your SWF,
but don’t fool yourself there is a cost: the time and involvement it takes.

What do you try to protect and why ?

If it’s about the source code itself, is it about running the code or reading the code ?

Is it about you users security ? server security ? both ?

Is it about some secret algorithm or very unique way of doing things you think you have ?

Do you try to prevent a copy and paste clone of you game on some shady server ?

There are many things you can try to protect, some are easy some much harder.

So before going into a long development process to do this or that, first define what you try to protect.

For example:

I published a game on and I don’t want some 3rd party to easily copy the game.swf on their own other

Another example:

I published a game.swf and I don’t want users to submit a hacked score


Basic Principles

  • as soon as you publish something online
    it is publicly accessible by anyone
  • either by a path on your server
    for ex: GET
  • either in the browser cache
    there are plenty of tools and browser add ons to extract SWF from the cache
  • either from memory
    even if the SWF was not cached you can
    retrieve it from memory
  • a SWF file is structured in such a way
    that you can easily reverse it (from binary)
    to source code (or pseudo code)

Technically, with just that you can imagine it not gonna be easy to protect a SWF from decompilation.

The case of obfuscation

Obfuscating is the principle of changing/renaming variables name and other definitions before (or after) compiling the source code.

The logic is: even if the code is decompiled it will then be really hard to read.

Some obfuscates claim they can obfuscate in such a way that the source can not be decompiled with some tricks, it can happen but see that as a temporary solution, again this is not 100% safe.

First, an obfuscator does not prevent the code to be decompiled it just make it less readable,
so as long as you can actually see the code logic, even if it’s very hard to read it, it is not impossible
to retrieve the code.

Second, an obfuscator modify either your source code or the SWF binary and so could inject
any code it wants, and that could be much much worst than having your code decompiled.
Especially with an obfuscator that is closed source, you have no way to know what’s going on,
what is modified or how, and so it could be used to inject malware in your SWF or advertising links,
and other tracking and nasty stuff.

Third, because the obfuscation modify the original code it can introduce instability.
For example, the normal SWF would work fine but the obfuscated SWF would crash and other niceties like that.

My advice: stay away from obfuscator unless they are from a high professional quality (which I had never seen in the Flash world, maybe with .NET and Java but not AS3).

So What do we do then?

Learn how the browser cache is working.

The very way to make a SWF not decompilable is to not give access to the SWF file in the first place.

The basic way to do that is

  • use HTTP 1.1
  • prevent HTTP caching
  • use HTTPS
  • load a shim.swf that load an encrypted child.swf
  • the shim.swf decrypt the child.swf based on a “key”

We want to ban HTTP 1.0 as it allows to work around some caching and non-caching mechanism.

Also, we want to sniff the user-agent to block by default some old browser like IE6;
and yeah user-agent can be spoofed, but in our case it will work e.g…

  • we do not want IE6 to cache the page
  • so we block user-agent that identify as IE6
  • IE6 has no way to fake its user-agent
  • so we will effectively block IE6

But in fact there is an even better way: use HTTPS
depending on the cypher suite you use server-side some old browser
will be excluded and among them IE6
(someone can hack the registry, spoof the user-agent all they want)

see TLS/SSL support history of web browsers.

By enforcing the use of HTTP 1.1, HTTPS and a somewhat recent browser version
we can then control how the browser caching works.


In short you want the following HTTP headers

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

But wait… that’s only the beginning: HTTP/1.1, HTTPS with a modern cypher suite that enforce modern browsers.

The thing is you have also something else than browsers than can access a web page: robots, crawlers, spiders etc.

So before even the caching, you should prevent the downloading part.

If a user can simply do a
$ curl -X GET
it is basically game over.

But cURL has a little weakness, it does not interpret JavaScript in the HTML page,
so we gonna use JS to filter out any cURL, wget and other robots crawler.

And at the same time, we gonna enforce the HTTP referrer, to be sure another site can not embed our HTML page with an iframe, and other little tricks like that.


Here how it works:

  • the server deliver an HTML page that is almost empty
  • but at the same time the server created a user session
    which create user cookie with a unique value (HTTPS only)
  • in this web page you use the “double submission of cookies” technique
    to validate the referrer but also to send an HXR request to fetch
    a shim.swf
  • from that the shim.swf load an encrypted child.swf
    encrypted with a private key associated with the user session
  • also you make it in such a way that if the user refresh the page
    the unique session id change and so the private key have to change too
  • that way the child.swf is always encrypted with a different private key
  • now the tricky part is to compile the shim.swf “on the fly” with that key
    to load an external binary on the stage
    • use Loader.load() to load the encrypted SWF
    • then use the key to decrypt the SWF
    • finally use Loader.loadBytes() to load the ByteArray in memory

Wait, we are not done yet, all the above could maybe block 99% of “vilains”
but even if there is no cache or file around an attacker can still scan and inspect the memory
to find out the unencrypted SWF data and dump it to a clean SWF file.

Well … not yet :wink:.

Now, we gonna move some components of our client-side SWF to the server-side,
and keep some key logic purely server-side, the client will get the output it needs
but the code will stay resident on the server-side, and that is bullet proof.

So, yeah it’s hard to implement, but it is also remotely impossible to crack,
here what we got for us so far

  • the data stream goes trough HTTPS
    so any client-request can not be spoofed
  • but also we have a special unique id combined with a private token
    all that in our user session
  • that means we can sent request we from the client
    that we can validate from the server-side
  • whether you use a REST API, AMF, etc.
    the request can be validated
    simply take all your parameters and create a checksum
    with you private key (a bit like OAuth validation)

Now, is the hard part: choosing the “logic” you want to delegate to the server,
is it a game ? is it an app ? etc., it will be a different choice for what actually happen in SWF.

Remember what I said at the beginning

What do you try to protect and why ?

If it was super easy to just protect a SWF everyone would just check the option “protect” for anything and everything.

But it is quite hard, take lot of resources (that could be used to actually program the app or game) and finally is it worth it ?

So, I’ll take a recent personal app as an example: a client-server chat app.

Here what I need to protect

  • the user data
    for that I use HTTPS and Secure Socket
    so the text one user send to another user can not be intercepted
  • the user login/password
    again HTTPS and Secure Socket
    and depending where the app is running a save in Encrypted Local Storage
    if the user does not want to re-enter his/her credential all the time
  • protecting the SWF file ?
    I could not care less
    go ahead take it decompile it, have fun

Why ?

  • you will not be able to inject admin commands
    because those are validated and verified server-side
    you can try to spoof them but it will fail “by default”
  • you can not impersonate another user
    again validated and verified server-side
  • you can not spy on other users private conversations
    again the server decide to which user the messages are dispatched
    you would have to impersonate another user to receive his/her message
    and you can’t do that
  • oh you want to cheat at this little multi-player game?
    sorry you can’t, the server keep in-memory the game session
    and validate the score every step of the way and so will know
    if you try to submit a score that is way too high

I don’t need to protect the SWF because the whole logic is already server-side,
the chat client is just that a client, there are some logic like building/interpreting commands
but those are harmless as the real data is stored server-side, for example:
to get the user list in a room, you send a command getUserList()
not only the command can be locked to only “admin” role but also
can be allowed to only those who are actually in the room and that only the server knows,
and tons of things like that.

OK that example is a very specific one but again ask yourself why you want to protect a SWF,
in most case is the basic “reflex” “oh I want to keep my stuff private I’m so afraid they gonna steal my code from me” when in most case nobody cares.

And yeah there are other specific cases like games, if you have experienced your game being cloned and republished some other place, yeah I can understand you really don’t want that to happen.

The thing is there are no easy way to protect a SWF, yeah I show a little above how it is possible, but even then it is not 100% sure nobody will ever be able to crack it, maybe 99% but certainly not 100%.

So think of it like that: what is harder and take more resources ?

  • build a special limited SWF for online promo
    that does not contain all the codes, assets, levels of the full game
  • spend hours if not weeks in building online SWF protection
    for the full game published online

I would say “the special limited SWF” is the way to go.

Now, you may be in a case where you really have to publish the full game as an online SWF
and still with that you have numerous choices you can make

  • force a user registration to access the full game
  • sequence the assets and game logic in such a way
    that you have to actually beat the game to get all the assets of all the levels
    (just that can be more effective that protecting the SWF, because it takes time)
  • only allow a limited demo online
    registered users can download the full game to play on the desktop
    eg. you can automate the build of the desktop app with a fingerprint related to the user
    and if the game is leaked you will know which user did it
  • etc.

All those things, even if they look complicated, are less complicated than protecting the online SWF.


Hi, I really liked this reply of yours to the swf security issue. However there is a lot of complexity to it that you have clearly mentioned and so most people like me, novices, would just let it go at that. But It would be a great help if you could convert this into a tutorial showing the exact implementation of this then I am sure it would be of great benefit to the AS2 / AS3 community. I for one, would surely try it out then.

Thank you.


It is very funny you ask a tutorial when the article above is just that with explaining and references and everything

The only thing this article is missing is a demo source code that you could copy/paste without bothering reading the article.


Hi zwetan, Thanks for that quick reply. I have read the article and in fact I am reading it a second time now. I will read it yet again maybe as I try and implement some of what you suggested.

I must say that this is probably the only recent article on the subject while most of the others are at least 4 to 5 years old. Besides it’s more detailed than any other article that I have come across.

However I do feel that while normally a flash developer does not have much experience in server setting and stuff like that mentioned in your articles, I was hoping for more detailed instructions. I was also hoping you would recommend some obfuscators and file encrypting tools of your choice, possibly with some links to them.

In any case I’ll try and see how far I can go and will revert back to in case i get stuck somewhere. A wonderful and complete article.

Thank you.


Hi zwetan !!,

I have been reading and following your article along. However I wish you could elaborate a bit, and yes with some sample code if possible just to send me in the right direction, on the following :

But cURL has a little weakness, it does not interpret JavaScript in the HTML page,
so we gonna use JS to filter out any cURL, wget and other robots crawler

How can Javascript be used to filter out cURL? Or are you suggesting that the website be constructed using JS entirely ? Or maybe some portion of it ? Exactly how?

Thanks loads.


because curl does not interpret JS

here a basic example

AddType application/x-httpd-php .jpg

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^*$ [NC]
RewriteRule \.(gif|jpg)$ [R,L]


$je = $_GET["je"];
$http_referrer = getenv( "HTTP_REFERER" );

$good = "img/too_many_secrets.jpg";
$bad  = "img/setec_astronomy.jpg";

function serve_img( $name )
    header("Content-type: image/jpeg");
    $data = file_get_contents( $name );

    if( $data !== false )
        echo $data;

if( ($je == 1) && (!empty($http_referrer)) )
    serve_img( $good );    
    serve_img( $bad );


$je = $_GET["je"];
$http_referrer = getenv( "HTTP_REFERER" );

$img_tag = "";

if( $je == 1 )
    $img_tag = "?je=1";

$html = <<< HTML
function getParameterByName(name, url) {
    if (!url) url = window.location.href;
    name = name.replace(/[\[\]]/g, "\\$&");
    var regex = new RegExp("[?&]" + name + "(=([^&#]*)|&|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));

var je = getParameterByName('je');

if( (je === null) || (je === "") )
    window.location.href = window.location.pathname + "?je=1";
referrer: ${http_referrer}
<img src="image.jpg${img_tag}">

echo $html;

when you go to
the JS automatically redirect it to
and the HTTP_REFERER is set
also the img src change to image.jpg?je=1

it display the “good” image

if you do a
$ wget
$ curl

the JS does not execute and the HTTP_REFERER is empty

also try to access directly in your browser

it display the “bad” image

the param **je** for "javascript enabled" could be anything else

like the hash of a passphrase

like a random number

the important thing is that the server-side (in this case PHP)
can share this param (or key or anything really) with the JS client-side

the HTTP_REFERER is the basic trick to avoid hotlinking
but don’t rely on it as it can be spoofed
and when you move to HTTPS you do not have referers

see Detect Javascript on the server side
for another way to do it (eg. without a redirect)
even if curl can handle cookies, if the cookie is set by JS then curl can not deal with it

In other ways to block curl you can also do the obvious
like test the user-agent (but again that can be easily spoofed)

and/or do more advanced thing
see Detecting the use of “curl | bash” server side

That only is not enough to block the download of a binary like a SWF or an image
it is the succession of all the things put together

what described above can be swiftly defeated with
$ wget --header="Referer:"
$ curl --referer "" -O


Hi Zwetan,

Thank you for the reply and the detailed response. I will take some time to read and digest & understand all of it. Will revert later.

Thanks again.


Hi zwetan !

This really is goes on spiraling ! :disappointed_relieved:

OK here are a few more contradictions. :thinking: :thinking:

  • So if a website is using HTTPS and cannot use referers, is the above pointless ( only the referer bit ofcourse)?
    -I have also read though that HTTPS has a new referer policy. So then can this be used or not ?
    If not then in the string of things up to this point in your article above, we just leave out the referer header thing and continue or is there something else that may be used instead when the website is using HTTPS.

Thanks !


You want to use HTTPS because only the combination of HTTPS + cache-control headers
prevent to keep the SWF file into the browser cache

now for the referer, you don’t care, it was just for the example
you never want to trust it as it can be spoofed

now the HTTP RFC specify that when HTTPS is in use the referer is not being sent


15.1.3 Encoding Sensitive Information in URI’s

Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure

see Where did all the HTTP referrers go?

but again, do not use the referer to validate a request

in the example above I was just using it with another param
to have 2 variables instead of just 1, for the example sake

the important part being use JS to defeat direct download of resources from either curl or wget

so there are no contradictions, again “it is the succession of all the things put together”

when I said it could be anything else

like the hash of a passphrase

I meant it

if you hit a PHP page that each time generate a different key
then you can use this key in JS and pass it through to the shim.swf
that will then load an encrypted SWF


  1. PHP page hit
    • encrypt SWF with key=12345678
    • add the key in the page itself
  2. when the page load on the client side
    • JS can access the key
    • pass it as a FlashVars to the shim.swf
    • the shim.swf load an external SWF file based on the key
      eg. Loader.load( "protected.swf?key=12345678" )
    • decrypt the SWF file in-memory based on the key

so key here is highly simplified but that’s the general idea

at worst someone inspecting the page could use curl/wget to download the shim.swf
but we don’t really care as this one has no contents

the file protected.swf is in fact a PHP page that go fetch the correct encrypted SWF
based on the key parameter, you could add timeout and many other parameters
for ex: when you register the key you add a timestamp and the key is only valid for 10 secondes
if someone try to access the full URL with protected.swf?key=12345678 it just return a default SWF (not the real content)

You do want to read

for even greater details read

in short, instead of using the referer to validate the page you use the XSRF-TOKEN to validate each requests (see the detailed examples in “AngularJS security series part 1: Angular $http service”).

At the time the server generate the key

  • you can associate it to an IP address
  • you can also associate a timestamp
  • and a XSRF-TOKEN

when a GET request hit the server to get the file protected.swf
you can validate the request with the IP, the timestamp, the XSRF-TOKEN

if only those validate, then you serve the binary of an encrypted SWF using key=12345678

and note that this is still hackable, even if no SWF is in the browser cache, the SWF will be in-memory and so can be extracted from memory, not super easy but feasible.


Hi Zwetan !!

Wow !! thanks a lot for the reply. The referer really was confusing me quite q bit because while It seemed it was not needed in this scenario ( HTTPS), your reply hinted otherwise. In any case it was a good exercise and i learnt some about headers in detail.

OK so I am headed to flash and swf. And yet another query.

This suggests that the swf is on the server and that it is encrypted every time the page is requested. This implies that the swf is to be encrypted using php. How is that possible especially since the decryption takes place in native flash when shim.swf decrypts the protected.swf using the secret key ?
Which encrytion and decryption utility runs in php and flash? Or am i again making a mistake in understanding this?



ok … so here we’re talking about symmetric encryption, see Symmetric-key algorithm

it could be any algorithm, at the bottom in the list of “Block ciphers” in “Other algorithms”
you could see one named XXTEA

and on Github you can find the implementation of this algorithm
in many languages:

for PHP
for AS3

while some implementations could cause problems in some specific case
see this article XTEA Encryption Interoperability

in general, if you use the same algorithm, you don’t care of the language where it runs

here PHP will do the encryption with a key
and AS3 will do the decryption with the same key

with an algorithm like XXTEA it should be fast enough to do it “on the fly”

many, I took XXTEA as an example but you could use anything else like AES, Triple-DES, etc.

see As3Crypto - ActionScript 3 Cryptography Library for example
and find the equivalent algorithm implementation in PHP

you might need to experiment a bit to have both AS3 and PHP to interoperate correctly
eg. if algo XYZ use key ABC then it generate the SAME encrypted stuff


Hi Zwetan,

Thanks for the reply. I have checked out the encryption routines for php and actionscript. However, what are my options if I am using AS2 and not AS3 ?? Can I use the shim.swf to load bytecodes using AS2 ?

While trying to construct the shim.swf I realized that most of this involves AS3 routines. I was hoping to load the AS2 swf using a AS3 file. But I can’t seem to find a way around it.

Thanks !


Hi Zwetan, Please ignore my last post.

So I managed the movie loading as well as passing variables via flash loading. etc in AS2.

However I do have another question and that is passing the decrypt key via Flashvars seems to be a very weak link since the key is directly visible in the variable that holds it.

Another question I have is that it seems to me that there is no concrete way to ensure that the shim.swf that we are passing / receiving the data to is the actual, authentic swf and not a spoofed one. For comparison, a form holds a anti csrf token and we can be pretty sure by comparing it’s value to the one saved on the server that the data is coming from our form. Checking the domain of the webpage holding the movie is also not a secure method and can be spoofed.

Are my fears correct or unfounded ? If yes, then can something be done about it.

Thank you.


an AS3 SWF can load an AS2 SWF, no problem

the key need to be unique and random and is valid only for a 1 GET request
which can be enforced with a timeout value server-side

you don’t care if the key is visible to all, the same as you don’t care if the shim.swf
encryption/decryption algorithm is available in the clear

because nothing is kept in the browser cache, it is all in-memory
the only way to make use of this key is to have access to the SWF binary

the shim.swf is served from your own server
as indicated in Website controls (policy files)

Policy files affect access to a number of assets, including the following:

  • Data in bitmaps, sounds, and videos
  • Loading XML and text files
  • Importing SWF files from other security domains into the security domain of the loading SWF file
  • Access to socket and XML socket connections

so by default using HTTPS your shim.swf will only be allowed to load another SWF from the very same domain

also review Creating more secure SWF web applications
to not do “stupid things”

as long as you don’t have a security policy of

<?xml version="1.0"?> 
<!-- --> 
<allow-access-from domain="*" /> 

that allows then any other domain to load your shim.swf, then you’re good


<param name="allowScriptAccess" value="sameDomain" />

The default setting for allowScriptAccess is “sameDomain” which means that if the SWF and the surrounding HTML were both served from the same fully qualified domain name, then the SWF can communicate with the HTML’s DOM and access data such as cookies or form data. If the HTML and SWF are served from different domains, then the SWF cannot access the surrounding HTML.

see Loader class

Loader security
When you use the Loader class, consider the Flash Player and Adobe AIR security model:

  • You can load content from any accessible source.
  • Loading is not allowed if the calling SWF file is in a network sandbox and the file to be loaded is local.
  • If the loaded content is a SWF file written with ActionScript 3.0, it cannot be cross-scripted by a SWF file in another security sandbox unless that cross-scripting arrangement was approved through a call to the System.allowDomain() or the System.allowInsecureDomain() method in the loaded content file.
  • If the loaded content is an AVM1 SWF file (written using ActionScript 1.0 or 2.0), it cannot be cross-scripted by an AVM2 SWF file (written using ActionScript 3.0). However, you can communicate between the two SWF files by using the LocalConnection class.
  • If the loaded content is an image, its data cannot be accessed by a SWF file outside of the security sandbox, unless the domain of that SWF file was included in a URL policy file at the origin domain of the image.
    Movie clips in the local-with-file-system sandbox cannot script movie clips in the local-with-networking sandbox, and the reverse is also prevented.
  • You cannot connect to commonly reserved ports. For a complete list of blocked ports, see “Restricting Networking APIs” in the ActionScript 3.0 Developer’s Guide.

However, in AIR, content in the application security sandbox (content installed with the AIR application) are not restricted by these security limitations.

You will also need to add codes in the loaded SWF
to do some basic checks see Protecting a swf

So, to spoof that shim.swf there are many methods, like loading the SWF from a local page, using the debug player, using the mm.cfg etc.

see AS3 hidden treasure in the mm.cfg file. Revealing and documenting many Flash secrets!


This is mainly used by the FlashBuilder Profiler. When you launch a SWF profiling, FlashBuilder add this line to mm.cfg to make it run another SWF before the one you profile.

The default file is:

C:/Documents and Settings/{USER}/My Documents/Flex Builder 3/.metadata/.plugins/com.adobe.flash.profiler/ProfilerAgent.swf?host=localhost&port=9999

The profiler agent is a SWF that use the as3 sampling classes to collect information and send them all over a socket connection to FlashBuilder.

FlashBuilder is only interpreting that data received from the SWF
By changing localhost by any other machine name you can connect to a remote FlashBuilder Profiler. On the Remote profiler you need to check the “wait for application” box and then start the local SWF on the other machine.

to prevent that just use a gatekeeper.swf

eg. shim.swf --> gatekeeper.swf --> 123456789.swf

in that gatekeeper you can verify

again you HAVE TO use HTTPS

whatever domain you use eg. can easily be spoofed with HTTP
not with HTTPS


Hi Zwetan,

Thanks a lot for the reply !! That’s a lot of information to assimilate and work on. I have read all and understood some.

I have never heard previously of the gatekeeper.swf concept. What I can make out from the diagram - and i may be completely wrong - is that shim.swf is supposed to load gatekeeper.swf which is then going to conduct the tests on domain and ip and confirm that it is indeed the correct domain. If so, it will then go ahead and load 123456789.swf which is the actual swf that we are trying to protect.

Kindly clarify.

Further, I have been trying to use the following bit of code to create my AS3 shim.swf ( since you mentioned I can use an AS3 moviw to load an AS2 movie) .

    import flash.display.Loader;
    import flash.display.Sprite;
    import flash.system.ApplicationDomain;
    import flash.system.LoaderContext;
    [SWF (width = 640, height = 423)] //the dimensions should be same as the loaded swf's
    public class Main extends Sprite
        [Embed (source = "VerletCloth.swf", mimeType = "application/octet-stream")]
        // source = path to the swf you want to protect
        private var content:Class;
        public function Main():void
            var loader:Loader = new Loader();
            loader.loadBytes(new content(), new LoaderContext(false, new ApplicationDomain()));

However it simply gives the following error which I am unable to resolve.

TypeError: Error #1007: Instantiation attempted on a non-constructor.
at Main$iinit()

Please help me out with this.
Thanks loads.


I did warn


yes, it is complex and it will take a lot of time to have a complete solution

If I wanted to provide a complete solution with all sources
I would have done that long ago but imho it’s not worth the time

so Ajay, with all due respect, I feel like you’re asking questions in order to make me do your “homework”
I do think I have commented enough and give enough pointers to cover all the “corner cases”

after, it is a developer problem, either you can implement it or not following the guidelines
but I’m certainly not gonna do it or debug it for you for free


Hi Zwetan,

Yes sure and I am not complaining at all !! In fact I have been at it with your help. I don;t mind reading and trying things out.

The code, I have been trying various implements and only when I could not surmount the error did I post it here for your help.

I feel like you’re asking questions in order to make me do your “homework”

It’s not like that, I read and proceed to a point where either I do not understand something ( and I do a lot of research on google) or I am stuck at the code, like I was now since yesterday, that I turn back to you for help.

Definitely I have got a lot of it ( help) and I am grateful.
Thanks again !


I could narrow down the error to the fact that

private var content:Class;

remains uninitialized. All examples of code that I have encountered have used the Class variable like that. Some of them choose it to use a const instead of a var. I don’t think that matters. What matters is that it probably has a null value.

Maybe just a pointer now in the right direction would be a great help.

P.S. I am using Flash CS3 for coding and testing.
P.S. Maybe its a FLASH CS3 issue and I need to compile this using Flex.

Thanks tons !