Course Vector

SWF Trivia

While working on my own SWF decompiler (Flashbug 1.7) I’ve learned a lot of interesting things about SWFs that I wanted to jot down.

1. PNGs can be compressed : When embedding PNG images into a SWF you have the option of compressing them. This actually converts them to a JPEG with an alpha channel. It’s non-standard but definitely a neat trick. This almost negates any reason why you shouldn’t always embed a PNG into your FLA.

2. Text character codes aren’t embedded : When you have any text fields in your SWF, the character codes aren’t embedded into the SWF. Instead it embeds the glyph codes for the specific font used. It then checks the font to match the glyph code to a character code. I suppose this helps ensure your text is displayed correctly.

3. Streamed sounds are combined into one sound : In timeline animation, you may embed 1 or more sounds into the timeline to be streamed. What actually happens is that all the sounds in a given timeline are combined into a single blob of sound data. Then that data is split over each frame, this insures that it’s synced to the frame animation. Which explains why when you decompile a SWF you can’t really extract streamed sounds.

4. SWF Encrypters are pretty useless : I’ve only tested a few, but they really don’t do much. Each SWF is composed of a series of tags. Each tag contains a specific kind of data. So there are for instance shape tags, and image tags, etc. Well there is also an End tag, which means you’ve gotten to the End of the SWF. Well one of the encrypters just puts a fake End tag at the beginning for decompilers to get tripped up on. It’s pretty easy to avoid and most decompilers skip over it. Others try to add custom tags to hide data. But again, most of these work to hide the ActionScript. All of the media is still easily extracted as shown by Flashbug.

Notes: General AS3 Tips

This is the final bit migrated from the Labs Wiki. This is just a short list of quick and easy tips to keep in mind when programming AS3.

• Do not use Objects, if you know which properties will be finally involved. Write a class for it; AS3 seems to register a memory space for them and will have faster access.
• Keep variable names as short as possible. While this doesn’t help a lot, it does help a little.
• Items of 0 alpha are still draw on the stage. Use visible = false to save CPU cycles

› Continue reading

Tags: as3

Notes: Math Optimizations

This is some more stuff migrated from the Labs Wiki. Below is just some aggregated tips and tricks I’ve found on other blogs or websites.

Extract Colors

Not really an optimization per se, but just how to extract color values.

//24bit
var color:uint = 0x336699;
var r:uint = color >> 16;
var g:uint = color >> 8 & 0xFF;
var b:uint = color & 0xFF;

//32bit
var color:uint = 0xff336699;
var a:uint = color >>> 24;
var r:uint = color >>> 16 & 0xFF;
var g:uint = color >>>  8 & 0xFF;
var b:uint = color & 0xFF;

› Continue reading

Notes: Flash 9 Gotchas/Bugs

This is also migrated over from labs. This was a list of bugs and gotchas I’ve run into over during my time as a Flash developer. I’m sure the best play to look would be Adobe’s Bug tracker but it doesn’t hurt to have a concise list of things to watch out for.

Bugs/ Gotches

• Bug

  wmode="opaque" or "transparent" disables KeyDown actions (not true in 9,0,60,0 beta) and disables MouseWheel actions

› Continue reading

Notes: Cross-Domain Policy

Below is the structure of the cross-domain policy and all the allowed values. The majority of the content was aggregated from Adobe’s page on cross-domain policies.

A cross-domain policy file is an XML document that allows a web client to handle data across multiple domains. You will usually need one if the SWF is playing on Domain A and the files are located on Domain B. Policy files grant read access to data as well as permit a client to include custom headers in cross-domain requests. A policy file is also used when using Sockets during socket-based connections.

The most common location for a policy file on a server is in the root directory of a domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml)—the default location that clients check when a policy file is required. Policy files saved this way are known as master policy files. The following is an example of a typical, permissive URL (i.e. non-socket) master policy file:

Example

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>
	<site-control permitted-cross-domain-policies="master-only"/>
	<allow-access-from domain="*"/>
	<allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

› Continue reading