How can secureSWF break decompilers without affecting the Flash player?
Decompilers and the Flash player differ in one very important area. The Flash player executes code – if the code says “GOTO”, the Flash player does. Reverse-engineering tools attempt to view sections of code at once and identify those pieces of code as for-loops or if-blocks or whatever structures were present in the source code. The Flash player does not particularly care and certainly does not need those structures. Loops and if-statements are simply a commonly followed GOTO. secureSWF’s code transforms destroys the common perception of a compiled control structures. The Flash player doesn’t care if one set of GOTOs has been replaced by another. But decompilers are left with spaghetti code. Since ActionScript has no actual GOTO command (compiled byte code does) this often poses a significant reverse-engineering problem.