Right, so I'll start off with an application that seems to use SWF Encrypt or a similar technology (Link to download provided at the end). I've confirmed this by decompiling using popular software such as Eltima's flash decompiler as well as flare. Both programs come up with the tell tale signs of useless decompilation i.e. random eval() and addition, etc.
So, the first thing that I have to do is set up a simple environment for getting rid of any foreign bytecode inserted by SWF Encrypt. For this, I'll be using Java. The basic idea is to have a library that makes it simple to edit an swf on the bytecode level (similar to Java's Bytecode Engineering Library, ObjectWeb ASM, etc.) This isn't meant to be pretty or anything right now, so I'll just make it a hack.
Code:
import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.DataInputStream;
import java.io.IOException;
public class SWFel {
public static void main(String[] args) {
try {
DataInputStream stream = new DataInputStream(
new BufferedInputStream(
new FileInputStream("jetman_base.swf")));
int compression = stream.readUnsignedByte();
int signature1 = stream.readUnsignedByte();
int signature2 = stream.readUnsignedByte();
stream.close();
System.out.println(Integer.toHexString(compression) + " ");
System.out.print(Integer.toHexString(signature1) + " ");
System.out.println(Integer.toHexString(signature2));
} catch(IOException e) {
e.printStackTrace();
}
}
}
I read some of the swf file format specifications, and it states that the first 3 unsigned 8 bit bytes are signature bytes. The first determines whether the file is compressed or uncompressed. The second is a "W", and the third is an "S" presumably to determine whether the file is corrupted or not. Following this paradigm, I should be able to manipulate a SWF file soon enough by creating methods to insert, edit, and delete individual bytecodes.
Now that I have my basic environment set up for manipulating various bytecodes within the SWF, I now need to review what it is I could possibly be needing to change. So far, my knowledge of what they could do to confuse decompilers is limited to what I read in http://www.gotoandplay.it/_articles/2004/04/swfProtection.php, and information I've gleaned from the 2 threads dealing with this subject on this forum. I'm disregarding the articles I've read on identifier scrambling, keeping things on the serverside, etc because they basically have no association with this type of security, and are fairly intuitive to begin with.
The SWF seems to be incorporating the non-displayable characters technique, and I'm also assuming it performs the jumping sentence technique, but I don't know of any other techniques aside from that.
SWF I'm using to practice on:
http://rapidshare.com/files/112575482/jetman_base.swf.html
. I never really released it, but I'm attaching its current source here for your convenience. The obfuscation tricks it reverses (which are surprisingly lame) are outlined in the comments.