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

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

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

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

4、分析的時(shí)候了。用 IDA 和 DeDe 同時(shí)分析客戶端程序。為什么還要用DeDe ?因?yàn)镈eDe 在分析Borland c+/Delphi程序時(shí)有比IDA 強(qiáng)的方面，兩個(gè)配合效果很好。同時(shí)啟動(dòng) OllyDBG attach到客戶端程序進(jìn)程上。 btw, 如果你還在用 SoftICE 分析應(yīng)用程序，該考慮換換了。-）在 sendto 上下斷點(diǎn)。很快就會(huì)斷下，因?yàn)榭蛻舳艘煌０l(fā)PING 包，這時(shí)候應(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 報(bào)文的。單步跟蹤這個(gè)函數(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é)清零時(shí)，立刻想不會(huì)是準(zhǔn)備做MD5 吧？IDA 進(jìn)0040E949處的 call 看看，果然是很標(biāo)準(zhǔn)的MD5_Init -> MD5_Update -> MD5_Final結(jié) 構(gòu)， IDA 進(jìn)懷疑是MD5_Init 的函數(shù)看看，赫然看到MD5 的四個(gè)常數(shù)。 Great ! 不用單步跟了，把call MD5 時(shí)的數(shù)據(jù) 16 進(jìn)制 copy/paste 至 U win hex 里，用 win hex 的 HASH 工具計(jì)算數(shù)據(jù)的MD5 ;OllyDBG里直接 F8 跳過這個(gè) call ，和 win hex 里算出的 MD5 值 比較，一樣！省了不少時(shí)間吧？看來胡適倡導(dǎo) “ 大膽地假設(shè)，小心地求證 ”還是很有道理的?，F(xiàn)在很明顯， 40E96B 處的 call 必然是加密報(bào)文的。IDA 跟