Nonetheless, the hard part was to find a decompiler that could convert the SWF file that gets loaded in Internet Explorer back into bytecode. I tried to use flasm but this file was encoded using Adobe Flex 4, which was released around March 2010 so the open source tools are a bit scant. I ended up using an unregistered version of Sothink's SWFDecompiler, which wants $70.00 for a license. An older 6.0 version seems to have some quirky bugs where it actually lets you export the ActionScript files back to the original format. Regardless, the program preserved all the original variable names, so you can pretty much have the original format, and I found a way to post the decompiled files in their entirety here:
The way in which Facebook has implemented cross-domain message passing in Internet Explorer mimics the use of the HTML5 postMessage. Instead of creating an event sender/listener for messages from a different window to pass, Facebook relies on SWF objects to talk with other in Internet Explorer. In Flash, there is the concept of LocalConnection objects, where SWF objects can talk with other even when they are on different domains. It injects this SWF file into both your site as well as after you login through the window popup (facebook.com).
When you do an FB.init() on your localhost, it instantiates FB.XD._openerOrigin (i.e. http://dev.myhost.com/ + 16-character random string), which is used to define the connection name that SWF objects will be use to communicate. The FB.XD_openerOrign was the key to the problems this past week -- Facebook was messing around with stuff for IE8, and broke the connection name that the SWF objects would agree on listening. They later fixed it based on the reviews of the diff I examined. When you type your login and password, the URL that is used when you submit goes to http://static.ak.fbcdn.net/
In addition to setting up the origin= query parameter, the FB.init() functions also sets up 3 separate callback functions: ok_session, cancel_session, and no_user, which are instantiated into a callback dictionary each accessible by a random 16-character signature. So if you've ever wondered why the query string on the Facebook login is so long, it's partially because of all the info they encode to handle the results of different authentications. Regardless, the message that gets passed includes a bunch of different URL-encoded string, but one of them is a cb= parameter, which specifies which callback function to run.