How we managed to get Alchemy1 working with FlashPlayer 11.2 Incubator and the secrets of SWF Tag 92

NOTE: The technique described in the following text is no longer used in public builds. It was limited to the Incubator release of FlashPlayer 11.2.

A few weeks ago, EPIC published it’s Citadel Demo, driven by Alchemy2 with Stage3D. I assume, if you read this post, you’ll know it wasn’t possible to run Alchemy1 in FP 11.2. There was a lot of discussion about this on the internet and also at Adobe’s prerelease forums. If you wanted to run your Stage3D application along with some Alchemy1 code, e.g. a physics library, the SWF won’t run.
The mysterious thing was that EPIC’s Citadel Demo also uses Stage3D along with Alchemy2. We thought the Player must be told by something inside the SWF that it’s allowed to run Alchemy2 with Stage3D, so we started looking inside the UDKGamePreloader.swf. It’s compiled with SWF Verison 13, while the UDKGame.swf is also compiled with SWF Version 13, but won’t run if started directly.
What is this magic behind the scenes?
Adobe recently announced a nice little tool, called SWFInvestigator. With this tool you can inspect SWF files. We used this on the UDKGamePreloader.swf file and discovered a new unknown SWF Tag 92. I extracted the Tag by opening the file in a Hex Editor and jumping to the beginning of the Tag. SWFInvesitagor is so helpful that it tells you the position of the ‘(invalid)’ Tag:

Name: (invalid)

Type: 92

Position: 8816

Length: 2722

RecordHeader: long

To extract the Tag, jump to this position and copy ‘Length’ Bytes from that position into a new file.
If you look through these Bytes, you’ll discover some human readable Strings like ‘Flash Runtime MOP’ or ‘Adobe Flash Runtime Premium Feature Certificate Authority1′. This might tell you the SWF is signed with some kind of code signing certificate. @ASVGuy found out it’s ASN1 and shared his ASN1 Dump.
I found this nice program to inspect the certificate: ASN.1 Editor that provides a more comfortable viewing of the contents. But there’s another way of inspecting the certificate. Just rename the file with the extracted Tag 92 to the suffix ‘p7b’, so you’ll end up with a file ‘Tag92.p7b’. Double click it and the Windows certmgr will open (I don’t know if there’re similar tools on Mac/Linux). Now you can easily view the contents. Unfortunately I don’t know much about certificates, but I know that for code signing you need a public and a private certificate.
The big question is, how does FlashPlayer certify that the loaded SWF is well signed? Either they do an online-lookup, but Wireshark didn’t capture any connection to be like that. So the private certificate has to be somewhere inside the FlashPlayer Plugin.
Please note that the License Agreement prohibits to reverse engineer, decompile or disassemble the plugin. However, in my interpretation, it does not cover extracting private certificates. You can also get the private certificate with a hex editor by opening the plugin DLL and search for ‘Premium’. I won’t describe it any further and leave this up to you.

Fine. Found out the SWF is signed and if so, changing any Byte will cause the SWF to fail, but that’s not entirely true. You may change the Bytes prior to the FrameRect Tag. But this is not really interesting.
Ok, let’s get to the part how we got Alchemy1 running in FP 11.2.

EPIC’s Loader is really fantastic! They’ve got a background picture as well as a soundloop playing while the SWF loads. We simply tried to load one of our demos by renaming our SWF file to ‘UDKGame.swf’. SUCCESS! It loaded :)
It really was that simple to work around this code sigining thing. With EPIC’s epic preloader SWF, you’ve got the ultimate weapon. A preloader loading the content you want, a background screen, music – anything else you need? ;)
We immediately contacted Adobe to inform them about this major security hole. This might be why they changed how this will work in future. I’m unsure, but I think the details are covered by the prerelease NDA, so I won’t talk about this. What I can say is that Premium Features won’t be signature based. Adobe will use a solution that is as straightforward as possible, so that devs can easily distribute their SWFs without having to resign them constantly.

Some last words on the future of Alchemy and Stage3D.
The following information about Alchemy2 is my very own interpretation.

Alchemy2 is not really a new version of Alchemy, since the produced ByteCode uses the same ‘MOPs’ as Alchemy1, e.g. li16. What’s new about Alchemy2 is that it will be more easy to reuse existing C++ code with less modification. Alchemy2 will for example have it’s own VFS(Virtual File System), it will also wrap a lot of libraries (we found an OpenGL ES2 wrapper in the UDKGame.swf). If you liked Alchemy1, you might want to continue using it. It will continue to work without needing to sign a SWF, buy licenses or anything else.

But if you want to use Stage3D along with Alchemy, you’ll need a license and share revenue with Adobe. You won’t have to share anything unless you made $50K. More details at Adobe.

Quote Tom Nguyen

- Anyone can use Alchemy (domain memory) with any SWF version now, no special signing or cert needed, in the final release of FP11.2 that we just released.

- The approach used in the FP11.2 prereleases was temporary behavior, and is not related to how premium features will be enabled in the future.

Comments (1)

  1. 17:21, 5. April 2012makc  / Reply

    what an EPIC digital signature failure :)

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Pingbacks (1)