記錄金盾加密視訊提取工具被逆向分析過程一
上篇講替換機器碼工具的分析,本次繼續分析同一個包裡帶的視訊提取工具。
看圖:
工具使用過程:
這裡的WIN7.DLL是主要檔案,我們結合前面分析的,替換機器碼後,在把該DLL注入到播放器內,輸入密碼後,視訊就開始播放了,並在D盤根目錄下生成了一個AVI的視訊檔案,調整播放速度可以加快提取。提取後的AVI不能播放,需要使用它裡面帶的修復工具修復後就能播放了。
因能力有限,花費了很長時間來分析。win7.dll注入後做了3個動作:
1.HOOK播放器,把解密後的記憶體資料儲存到磁盤裡。
2.儲存後的檔案,在HOOK播放器的三方庫(FFMpeg)中的一個功能,並把儲存的資料再讀取進行解密。
3.在HOOK播放器調整播放速度的位置,把速度調整為20倍,達到快速播放寫出資料。
本篇我們分析它提取資料的過程。
該DLL被加了SE強殼,需要一個能過SE的OD(
那麼如何支找到提取的關鍵地方?我這是想到2個思路:
1、既然要把檔案寫出來,肯定要使用檔案操作的API,如CreateFile之類的函式。對其下斷回朔。
2、使用記憶體監視工具對注入的DLL看它都修改了些什麼,找到地址下斷。
本次我使用第二種方法,監視該DLL對記憶體修改的哪些地址進行下斷。
圖上可以看到,這裡直接JMP到DLL內了。在JMP上一句下斷,新增視訊後,輸入密碼進行播放,開始斷在了此處,我們F7跟進DLL內
0C0A12B0 60 pushad 0C0A12B1 36:8B4424 20 mov eax,dword ptr ss:[esp+0x20] 0C0A12B6 A3 BCAE0A0C mov dword ptr ds:[0xC0AAEBC],eax 0C0A12BB 36:8B4424 24 mov eax,dword ptr ss:[esp+0x24] 0C0A12C0 A3 B8AE0A0C mov dword ptr ds:[0xC0AAEB8],eax 0C0A12C5 36:8B4424 28 mov eax,dword ptr ss:[esp+0x28] 0C0A12CA A3 B0AE0A0C mov dword ptr ds:[0xC0AAEB0],eax 0C0A12CF 36:8B4424 2C mov eax,dword ptr ss:[esp+0x2C] 0C0A12D4 A3 ACAE0A0C mov dword ptr ds:[0xC0AAEAC],eax 0C0A12D9 A1 B0AE0A0C mov eax,dword ptr ds:[0xC0AAEB0] 0C0A12DE 8B0D C0AE0A0C mov ecx,dword ptr ds:[0xC0AAEC0] 0C0A12E4 6A 00 push 0x0 0C0A12E6 68 ACAE0A0C push win7.0C0AAEAC 0C0A12EB 50 push eax 0C0A12EC 51 push ecx 0C0A12ED E8 E4120C00 call win7.0C1625D6 0C0A12F2 ^ 75 8B jnz Xwin7.0C0A127F 0C0A12F4 15 B8AE0A0C adc eax,win7.0C0AAEB8 0C0A12F9 A1 BCAE0A0C mov eax,dword ptr ds:[0xC0AAEBC] 0C0A12FE 8B0D C0AE0A0C mov ecx,dword ptr ds:[0xC0AAEC0] 0C0A1304 6A 00 push 0x0 0C0A1306 68 A8AE0A0C push win7.0C0AAEA8 0C0A130B 52 push edx 0C0A130C 50 push eax 0C0A130D 51 push ecx 0C0A130E E8 27170C00 call win7.0C162A3A 0C0A1313 A5 movs dword ptr es:[edi],dword ptr ds:[es> 0C0A1314 61 popad 0C0A1315 8BC7 mov eax,edi 0C0A1317 99 cdq 0C0A1318 36:034424 08 add eax,dword ptr ss:[esp+0x8] 0C0A131D 68 C51B8B00 push 0x8B1BC5 0C0A1322 C3 retn
從彙編程式碼來看,是獲取堆疊內值,並把獲取的內容儲存在常量裡
0BFE12ED E8 E4120C00 call win7.0C0A25D6
這個CALL裡沒看出什麼,因為它做了VM,能力有限。但從上面的傳參來看,它會不會是設定偏移?
DWORD SetFilePointer( HANDLE hFile, // 檔案控制代碼 LONG lDistanceToMove, // 偏移量(低位) PLONG lpDistanceToMoveHigh, // 偏移量(高位) DWORD dwMoveMethod // 基準位置FILE_BEGIN:檔案開始位置 FILE_CURRENT:檔案當前位置 FILE_END:檔案結束位置 說明:移動一個開啟檔案的指標
下面這行程式碼該控制代碼是獲取一個檔案的控制代碼,正是前面生成的AVI檔案控制代碼
0BFE12DE 8B0D C0AEFE0B mov ecx,dword ptr ds:[0xBFEAEC0]
先猜測它就是一個呼叫SetFilePointer的過程,直接在
0BFE12F9 A1 BCAEFE0B mov eax,dword ptr ds:[0xBFEAEBC]
下斷,F9執行。CALL裡被VM反正也看不懂,繼續往下走。斷下後,把常量的內容給了EAX,儲存控制代碼的常量給了ECX。
0BFE1304 6A 00 push 0x0 0BFE1306 68 A8AEFE0B push win7.0BFEAEA8 0BFE130B 52 push edx 0BFE130C 50 push eax 0BFE130D 51 push ecx 0BFE130E E8 27170C00 call win7.0C0A2A3A
又是一個被V的CALL,看的我頭暈、噁心。從上面的傳參來看,前面做了偏移,這裡會不會就是寫資料了?
BOOL WriteFile( HANDLE hFile,//檔案控制代碼 LPCVOID lpBuffer,//資料快取區指標 DWORD nNumberOfBytesToWrite,//你要寫的位元組數 LPDWORD lpNumberOfBytesWritten,//用於儲存實際寫入位元組數的儲存區域的指標 LPOVERLAPPED lpOverlapped//OVERLAPPED結構體指標 );
結全API來看,在從堆疊中看到內容,傳入了控制代碼,解密的資料內容,大小,0,0正符合WriteFile這函式的引數啊。
執行完該CALL後,就返回到了播放器的程式碼中繼續執行。當在執行到HOOK位置後,又開始把資料寫出。
(為了驗證是不是正確的,我們複製偏移量,還有儲存些要寫出的記憶體資料,在寫入檔案後,開啟生成的檔案用WINHEX定位去看下是不是把記憶體裡的資料寫出去了。實際說明它確實把記憶體裡的資料寫到檔案裡了。)
總結:
1、DLL注入後,會先HOOK SetFilePointer。隨後當播放器呼叫該函式時,會有個判斷是讀取加密視訊時就執行HOOK程式碼:
008B1BBE - E9 EDF6720B jmp win7.0BFE12B0
同時獲取加密檔案的大小,建立一個同大小的空資料檔案。
2、視訊播放時,播放器執行到HOOK位置進入到DLL後,把解密的資料及大小寫出到磁盤裡。
3、迴圈執行2,直到視訊播放完。提取也就完工。
4、該DLL內很多東西被V掉了,需要自己結合實際情況去猜。
5、還有些細節的東西,根據這思路大家可以去細跟下。
6、以上分析的程式碼,如果要寫程式可以直接摳彙編稍改下就能做成工具使用了。
生成的視訊檔案,並不能看,前面說過還有第二次解密。下篇我們在分析第二次解密的功能!
PS:生成的是AVI檔案,使用WINHEX看資料它實際是一個MKV的格式視訊。
記錄金盾加密視訊提取工具被逆向分析過程一
http://www.it0365.com/thread-26-1-1.html
(出處: IT資源社群)