Gareth Jones

Due to the unsecure nature of Flash, I’ve always been wary of having my work decompiled and its code re-used without my knowledge or consent. By default Flash offers very poor protection against this. While it’s undoubtedly impossible to prevent this from happening completely (despite various security software vendors’ claims), you can make the process so difficult that most people will give up trying.

Of course, not all Flash work will be a target to such piracy but games and elearning products can be targets because the cost and time of developing these resources legitimately can be quite high.

An easy way to protect your work against decompiling is to run your work through an obfuscator. I use Amayeta’s SWF Encrypt, and while a file that has been obfuscated in this way is larger in terms of file-size, the protection that this process offers your code is well worth it. Obfuscating your file like this makes the code almost impossible for a human reader to know what’s going on inside it, much less be able to steal it or change it for their own needs. In a decompiler the code will appear to be nothing more than a load of gibberish, and in fact some decompilers will be tripped up by the obfuscated file and won’t even open it at all.

Cyclomatic complexity is a software metric used to measure the complexity of code. Specifically, it directly measures the number of linearly independent paths through a method. Although not a rule, generally speaking the quality of the code can be inversely proportional to the cyclomatic complexity value, so the lower the score, the higher quality the code.

One of the best programs that I’ve found for measuring the cyclomatic complexity of Flash Actionscript is SourceMonitor. This handy little freeware tool will give you the cyclomatic complexity values of your classes and of the individual methods within those classes so you can see exactly what requires attention in the event of a high score. It also gives other feedback too, such as number of lines of code and the number of methods per class among others.

If you fire up SourceMonitor with the intention of using it for Flash, you’ll notice that there is no preset for *.as files among the half-dozen or so presets available. That’s fine. Select the C++ profile and change the file extensions to *.as, then proceed. You’ll also have to make sure that your class files are saved with ANSI encoding and not UTF-8, though most decent text/code editors will take care of this for you. The latest version of SourceMonitor also parses UTF-8 files, so there’s no need to save with ANSI encoding any more.

Why should you care what cyclomatic complexity value your code gets? Well, apart from the warm glow you get inside from knowing that your code is well-written and elegant, there is a practical reason for it as well and that is the reduction of potential bugs. The more complex the code, the more difficult it is to keep track of what’s going on and the higher the risk of bugs creeping into your classes.

The accepted values for cyclomatic complexity are as follows:

• 1 – 10: a simple program with a very low risk of bugs
• 11 – 20: a more complex program with a moderate risk of bugs
• 21-50: a very complex program with a high risk of bugs
• > 50: untestable and obviously a number you want to stay well away from.

The highest value I’ve personally seen on an Actionscript class is 74, but you didn’t need to know that value to see that the classes were badly written. The classes contained switches that executed exactly the same code on ten different cases and there were duplicated methods in most of the classes. The code was written by a contractor, and as far as I know that was the first and last job that he was given. The name of the product that features this code is something that I’ll have to keep to myself though!

This morning I was looking forward to making some progress on a Specsavers application that I’m working on. I had been thinking about some of the finer details of how it was going to work last night and was ready to blast through the code and have a good portion of it written by the end of the day.

It was not to be.

I had an application class, and this application class would instantiate different child classes that were responsible for different “screens” depending on which “screen” the user had selected. This is an approach that I have used a thousand times before, so it really didn’t take much time to have all the code in place. However, when I published the application I found that it didn’t work. The first screen would load fine, but when trying to load the second screen I found that the application would just remain blank. What was going on? The file was compiling without any errors and all I was doing was instantiating different classes depending on a string ID. For all intents and purposes, the class that was failing to work was identical to the one that was working.

This was weird!

As I was using a method that I had used countless times before, I thought that perhaps the third-party wrapper that I was using was interfering with it so I stripped out its code. Nope, still didn’t work. I stripped out my recently-edited button manager class… nope, still didn’t work.

After stripping out everything apart from the absolute bare essentials and STILL ending up with only the first screen, I made a simple test file from scratch using different smiley faces as screens. Again, an application class called two other classes depending on which button I pressed, and each of these classes attached a different movie clip to the stage. It worked fine, as it had done so many times in the past.

So, what the hell was different between that and my non-functioning Specsavers app?!

I traced out the object variable that was being linked to the different screen classes and for the first screen it came back as [object object] as expected, but for the second screen it was coming back as undefined. I put a “wtf?” trace above and below the line that instantiated the second screen’s class and yep, they popped out in my trace so the line WAS being executed – it just wasn’t doing anything.

I went about transplanting the smiley faces code into my Specsavers app line by line and when finished, it worked. I then tried it again with the original class and once again I was met with a blank screen as once again it failed to work for me.

What the HELL was going on here?! My time was being consumed by a problem with attaching a movie clip to the stage! Was I missing something? Had I accidentally smoked a vast amount of weed before starting work that day?

In the end I had two classes – my original Specsavers class and my smiley face class – identical apart from one small detail. The Specsavers class was located within a subdirectory and was being imported at the top of the application class. The smiley face one was located within the same directory as my SWF and so did not need to be specifically imported at the top of the application class. The smiley face one worked while the Specsavers one did not.

I put the smiley face one inside the sub-directory and imported it – right there, it stopped working. I took the Specsavers one out of the sub-directory and put it into the same directory as the SWF and deleted the import line and yeah, it worked.

There was nothing special about the name of the sub-directory. It’s not a system name or a reserved name or anything like that.

So, to summarise, there is some kind of weird quirk that – for some reason – means that Flash treats classes that are imported slightly differently to those that aren’t. I’ve never come across this before and I have no idea if I’ll come across it again, but while searching for potential reasons for my non-functioning class on Google today only to find absolutely no clues at all, I hope this post might prove useful to someone else.