Randomization in SWFz

First of all, SWFz is a static security testing tool (not released, sorry) that is, as the name implies, aware of the Flash file format. Originally, it has been developed to generate test samples for Adobe Flash Player but surely the samples generated by this tool can be used to test any application that parses Flash file.

There are numerous methods embedded in the application to create fuzzed samples. The main reason for this is the demand for different fuzzing opportunities. Additionally, I added methods when parsing of some structures hadn't been completed yet but some ones had. These methods weren't planned but I thought to be a good idea to add them until I finish the relevant code, after all it still provides some creativity in the test cases.

So there are methods being primitive by ignoring some structures and there are methods being much structure aware for targeted testing. Then there are the between methods.

There is one important thing that's same among the methods: the fact of randomization.

As you envisage, SWFz has been evolutionary evolving. Initially, a simple method had been implemented that is dumb fuzzing; I call it fuzzing of linear blocks. The program divides the file into linear blocks, and can overwrite the byte at random position by a random value in each block. That time, I wanted to start with a simple feature and I did it by this. The position of each block and the byte value for altering the original one were chosen by random.

One of the next evolution stage was that the tool is able to locate the position and the size of the methods storing the actionscript bytecodes. Clearly, with this it's possible to launch more targeted fuzzing. The program can overwrite the bytecode at random position by a random value in each method. The position of each method and the byte value for altering the bytecode were chosen by random.

One of the next evolution stage was that the tool is able to locate the position and the size of the methods storing the actionscript bytecodes, moreover it is able to locate the position of each bytecode. The program can overwrite the opcode part of the bytecode at random position by a random opcode defined in a set. Practically, it means the program is able to replace the instruction with an other instruction that has the same size and properties.

I could have used the computer clock to generate the random numbers, that might work, I however have chosen a predictable random generator method called Mersenne twister. Using this, I can safely reproduce the test cases at any time, and the testing of the fuzzer can be done in more straightforward way.