逆向工程和協(xié)議分析練習(xí)

1、逆向工程和協(xié)議分析練習(xí)igx2006-04-11簡介最近小區(qū)寬帶改造，要求裝一個他們的客戶端，并且一直跑著這個客戶端才能上網(wǎng)，非常不爽。同時鑒于將近兩年沒做逆向分析了，正考慮找東西練練手，正好這個東西送上門來，估計不難，就它啦！:)先明確一下目標(biāo)：分析出這個客戶端是如何工作的。自己寫一個客戶端代替它，最好能做成Win dows 服務(wù)方便使用。最后研究有沒有遠程溢出可利用。ok, 目標(biāo)明確后可以開始了！信息收集一開始就直奔目標(biāo)并不好。收集信息一方面可以慢慢進入工作狀態(tài)，另一方面也能啟迪分析思路。所以不要在這階段省時間。先看看這個客戶端都裝了什么文件，寫了什么注冊表項。到安裝目錄下，發(fā)現(xiàn)一個uni

2、nstall.log ，安裝記錄都在里面了。除了一個分析的客戶端exe 程序為，其它只有一個文件名為 profile 的比較可疑。猜測是一些配置信息，用win hex 打開，居然是二進制，看不到有意義的信息。作罷。再用 stud_pe 檢查客戶端程序：沒殼；Borland C+編譯。 Great ! 應(yīng)該可以直接拿IDA和 DeDe 分析。啟動 Ethereal 抓包。啟動客戶端程序登錄到小區(qū)寬帶網(wǎng)。發(fā)現(xiàn)登錄成功后ethereal 只抓到兩個UDP 報文。果然夠簡單！從Ethereal 解碼看，客戶端從3849/udp 向服務(wù)端3848/udp 發(fā)送 login 報文，服務(wù)端回應(yīng)一個UDP 報

3、文。報文里看不到有意義信息，估計是加密了?，F(xiàn)在，這個login 過程是一個關(guān)鍵分析點。繼續(xù)抓一段時間包。發(fā)現(xiàn)客戶端大約每30 秒向服務(wù)端發(fā)送一個固定的UDP 報文（源和目的端口也分別是3849 和 3848 ），服務(wù)端則返回兩個固定的報文。聯(lián)想到IRC 協(xié)議 里的 PING PONG 報文，懷疑這也是一種PING PONG 協(xié)議。這也是一個分析點。繼續(xù)抓包，沒看到其它報文。估計在正常情況下login 成功后只要保持不停PING PONG 就行了。逆向分析現(xiàn)在，我們有四個報文：login_request禾口 login_response;ping 禾口 pong 。但是無法看出報文意義。該是逆向

4、分析的時候了。用 IDA 和 DeDe 同時分析客戶端程序。為什么還要用DeDe ?因為DeDe 在分析Borland c+/Delphi程序時有比IDA 強的方面，兩個配合效果很好。同時啟動 OllyDBG attach到客戶端程序進程上。 btw, 如果你還在用 SoftICE 分析應(yīng)用程序，該考慮換換了。-）在 sendto 上下斷點。很快就會斷下，因為客戶端要不停發(fā)PING 包，這時候應(yīng)該是斷在發(fā)PING 包的 sendto 上:text:0040D8C0push ebp+fromle n ; tolen.text:0040D8C3leaeax, ebp+to.text:0040D8C

5、9pusheax;to.text:0040D8CApush0;flags.text:0040D8CCpushebp+le n;len.text:0040D8CFleaedx, ebp+buf.text:0040D8D5push edx; buf.text:0040D8D6mov ecx, ebp+var_68text:0040D8D9push dword ptr ecx+8Ch ; s.text:0040D8DFcall sendto;這里發(fā)送keep alive 包往上面回溯，很容易發(fā)現(xiàn).text:0040D847 call build_keep_alive_pkt這里是構(gòu)造sendto 出

6、去的 PING 報文的。單步跟蹤這個函數(shù)調(diào)用 ,前面的包構(gòu)造都很容易理解。最后 :?text:0040E924push10h；n?text:0040E926push0；c?text:0040E928leaeax, ebp+s?text:0040E92Bpusheax；s?text:0040E92Ccall_memset?text:0040E931addesp, 0Ch?text:0040E934movdl, byte ptr ebp+var_14?text:0040E937movecx, ebp+var_10?text:0040E93Amovecx, dl?text:0040E93Cinceb

7、p+var_10?text:0040E93Fpushebp+var_14?text:0040E942pushebp+var_8?text:0040E945leaeax, ebp+s?text:0040E948pusheax?text:0040E949callMD5?text:0040E94Eaddesp, 0Ch?text:0040E951push10h；n?text:0040E953leaedx, ebp+s?text:0040E956pushedx;src?text:0040E957pushebp+var_10;dest?text:0040E95Acall_memcpy?text:0040

8、E95Faddesp, OCh?text:0040E962movecx, ebp+var_14?text:0040E965movedx, ebp+var_8?text:0040E968moveax, ebp+var_4.text:0040E96Bcallen crypt?text:0040E970moveax, ebp+var_14?text:0040E973movesp,ebp?text:0040E975popebp?text:0040E976retn跟到memset 把包里保留的16 字節(jié)清零時，立刻想不會是準(zhǔn)備做MD5 吧？IDA 進0040E949處的 call 看看，果然是很標(biāo)準(zhǔn)的MD5_Init -> MD5_Update -> MD5_Final結(jié) 構(gòu)， IDA 進懷疑是MD5_Init 的函數(shù)看看，赫然看到MD5 的四個常數(shù)。 Great ! 不用單步跟了，把call MD5 時的數(shù)據(jù) 16 進制 copy/paste 至 U win hex 里，用 win hex 的 HASH 工具計算數(shù)據(jù)的MD5 ;OllyDBG里直接 F8 跳過這個 call ，和 win hex 里算出的 MD5 值 比較，一樣！省了不少時間吧？看來胡適倡導(dǎo) “ 大膽地假設(shè)，小心地求證 ”還是很有道理的?，F(xiàn)在很明顯， 40E96B 處的 call 必然是加密報文的。IDA 跟