Simple attempt to exploit a stack of buffer overflow vulnerability in Wecon Levistudiou

This is someone sent to me, let me analyze, see if I can write exp. Only blame oneself level is not enough, finally failed to write exp, the following for own analysis idea

Environment for WIN10 Pro x64 English (10.0.16299) default security Configuration

First, the vulnerability analysis

The vulnerability is due to a buffer overflow that occurs when a subsequent function msvcr90!wcscpy is called, resulting in an SEH exception, because Levistudiou does not check the length of the. g_picture.xml file while it is processing the szfilename.

First open Levistudiou, attach WinDbg, reach the vulnerability scene

An invalid pointer is referenced at this time, and execution reaches the controllable position again

Back stack call through KB, ntdll! from 0x0019d3a8 location Kiuserexceptiondispatcher+0x26 can be judged by calling the SEH program

By analyzing the hmi_bmplib_dll!getxmlbmpinfobypos+0x24c of the 0x0019d860 position, the upper function can be judged as Hmi_bmplib_dll!getxmlbmpinfobypos; restart the program, Break Hmi_bmplib_dll!getxmlbmpinfobypos position with WinDbg

　　

Single-Step to 0x03042258 location, g_picture.xml file path appears.

　　

where EAX is the path to the vulnerability file g_picture.xml.

　　

The program is ready to empty the buffer until the 0x0304239e position has been run one step at a time.

　　

When the 0X30423AC is executed, the Memset function is called to set the buffer to 0, the first address of the buffer is ecx=0x0019d426, the space is 0x206h, and the storage content is 0.

Continue to 0X030423B4 where you can see the szFileName variable.

　　

From 0x030423b4 to 0x030423de, this process takes the szFileName value from the G_picture.xml file, and the value is converted to Unicode characters, \x61\x61\x61 ... Become \x0061\x0061\x0061 .....

　　

Next, the msvcr90!wcscpy function is called. Enter this function to view the value of ESP, where 0x19d424 is the destination address and 0x058fb988 is the source address.

　　

　　

Focus on the content value of 0x0019d426 at the buffer address at this point is 0

　　

　　

Proceed to 0x683b7130 where the first value of the source parameter src \x0061 copied to the buffer 0x0019d426, as shown.

　　

View buffer position 0x0019d426 The value begins to change to \0x00000061

And so on, the source address content is copied one by one to the buffer 0x0019d426

　　

Execution to the vulnerability trigger location, because it is SEH exception, with!exchain to see the exception, the address of next Seh 0x0019d854,seh is the location of 0x0019d858.

Changing the value of szFileName at this time will result in:

SEH after the No. 539 byte is overwritten,

Next SHE overwritten after 537 bytes (because characters are to be converted to Unicode format)

Ii. exploitation of exploits

According to the above analysis of the vulnerability can be roughly drawn the following stack map

Idea 1: To overwrite Seh as pop pop ret (and to find an address similar to 0x00nn00mm), then change next seh to JMP XX, and finally add shellcode after Seh, but finally abandoned because no module/safeseh off was found.

Idea 2: Use the address outside the load module to find the address of pop pop ret, call/jmp DWORD Ptr[ebp + XX] or call/jmp DWORD Ptr[esp + XX], and format for 0x00nn00mm, after searching, No addresses are found that meet 0x00nn00mm.

Simple attempt to exploit a stack of buffer overflow vulnerability in Wecon Levistudiou