The AVM2 specification – along with the SWF File Format Specification appears at first glance to thoroughly detail the inner workings of the Flash VM and how the bytecode that it uses is stored in the SWF file. However, a more detailed analysis reveals problems. The AVM2 specification was published in May 2007. Since then, we have had v10+ of the Flash Player released, with new features such as the generic Vector class. Adobe had to add new opcodes and data encodings to AVM2 to achieve this. The C to Flash Player project, Alchemy, added a whole range of new opcodes. None of these additions has ever been publicised by Adobe though. An updated version of the AVM2 specification has never been published. Folk have had reverse engineer the latest versions of the SWF file to try and work out the changes to the VM.
Adobe like to claim they have opened up the Flash VM by publishing these specifications. The fact that no update has been published in four years calls that claim into question though. I don’t know why it hasn’t been updated. Not keeping it up to date gives Adobe a commercial advantage (is it wise for a commercial company to use tools that rely on the questionable legality of reverse engineering efforts?), so perhaps that is why. Maybe it is internal politics in Adobe resulting in some manager banning the publication of updates? Maybe it is sheer laziness?
Whatever the reason, I wish Adobe would make up its collective mind. Either the AVM2 is open, in which case, they should get on publish an up to date specification; or it isn’t open. So which is it Adobe?
It turns out that the specification is more up to date than the date on the PDF version suggests. Patrick Le Clec’h and Zwetan Kjukov both pointed out that the Alchemy opcodes are in fact documented in the wiki-based version of the specification.
The man from Adobe: he says “yes”. Thibault Imbert agrees that it needs fixing: