這是別人給我發的，讓我分析一下，看能否寫出exp。只怪自己水平不夠，最後沒能寫出exp，以下為自己的分析思路

　　環境為win10 pro x64 英文版（10.0.16299） 預設安全配置

一、漏洞分析

　　此漏洞是由於LeviStudioU在處理.G_Picture.xml檔案的szFilename時沒有對其長度進行檢查，導致呼叫後續的函式MSVCR90!wcscpy時發生緩衝區溢位，從而引發SEH異常。

　　首先開啟LeviStudioU，附加windbg，到達漏洞現場

　　此時引用了無效指標，再次執行到達可控位置

　　通過KB回溯堆疊呼叫，從0x0019d3a8位置的ntdll!KiUserExceptionDispatcher+0x26可判斷呼叫了SEH程式

　　通過分析0x0019d860位置的Hmi_BmpLib_Dll!GetXmlBmpInfoByPos+0x24c，可判斷上層函式為Hmi_BmpLib_Dll!GetXmlBmpInfoByPos；重新啟動程式，用windbg中斷Hmi_BmpLib_Dll!GetXmlBmpInfoByPos位置

　　單步執行到0x03042258位置，出現G_Picture.xml的檔案路徑。

　　其中eax為漏洞檔案G_Picture.xml的路徑。

　　一直單步執行，直到0x0304239e位置，此時程式準備清空緩衝區。

　　執行完0x30423ac後，此時會呼叫memset函式將緩衝區置為0，緩衝區的首地址為ecx=0x0019d426，空間大小為0x206h，儲存內容為0。

　　繼續執行到0x030423b4處，可以看到szFilename變數。

　　從0x030423b4至0x030423de處，這個過程會從G_Picture.xml檔案中取得szFilename的值，並且值轉換為unicode字元，即\x61\x61\x61………變為\x0061\x0061\x0061………。

　　接下來會呼叫MSVCR90!wcscpy函式。進入此函式，檢視esp的值，其中0x19d424為目的地址，0x058fb988為源地址。

　　此時重點關注緩衝區地址處0x0019d426的內容值為0

　　繼續執行到0x683b7130處，如下圖所示會將源引數src的第一個值\x0061拷貝到緩衝區0x0019d426處。

　　檢視緩衝區位置0x0019d426的值開始變為\0x00000061

　　以此類推，會將源地址內容逐個拷貝到緩衝區0x0019d426處

　　執行到漏洞觸發位置，因為是seh異常，用!exchain檢視異常，可知next SEH的地址為0x0019d854，seh的位置為0x0019d858。

　　此時改變szFilename的值，將得出：

　　SEH在第539位元組後被覆蓋，

　　Next SHE在537個位元組後被覆蓋（因為字元要被轉換為unicode格式）

二、漏洞利用

　　根據以上漏洞分析可大致畫出如下的棧分佈圖

　　思路1：將seh覆蓋為pop pop ret（而且要找到類似0x00nn00mm的地址），然後將next seh改為jmp xx，最後在seh後新增shellcode，但最後因沒有發現/safeseh OFF的模組而放棄。

　　思路2：利用載入模組之外的地址，找到pop pop ret、call/jmp dword ptr[ebp + xx]或call/jmp dword ptr[esp + xx]的地址，而且格式要為0x00nn00mm,經過查詢，未發現符合0x00nn00mm的地址。