逆向工程和协议分析练习

1、逆向工程和协议分析练习igx2006-04-11简介最近小区宽带改造，要求装一个他们的客户端，并且一直跑着这个客户端才能上网，非常不爽。同时鉴于将近两年没做逆向分析了，正考虑找东西练练手，正好这个东西送上门来，估计不难，就它啦！:)先明确一下目标：分析出这个客户端是如何工作的。自己写一个客户端代替它，最好能做成Win dows 服务方便使用。最后研究有没有远程溢出可利用。ok, 目标明确后可以开始了！信息收集一开始就直奔目标并不好。收集信息一方面可以慢慢进入工作状态，另一方面也能启迪分析思路。所以不要在这阶段省时间。先看看这个客户端都装了什么文件，写了什么注册表项。到安装目录下，发现一个uni

2、nstall.log ，安装记录都在里面了。除了一个分析的客户端exe 程序为，其它只有一个文件名为 profile 的比较可疑。猜测是一些配置信息，用win hex 打开，居然是二进制，看不到有意义的信息。作罢。再用 stud_pe 检查客户端程序：没壳；Borland C+编译。 Great ! 应该可以直接拿IDA和 DeDe 分析。启动 Ethereal 抓包。启动客户端程序登录到小区宽带网。发现登录成功后ethereal 只抓到两个UDP 报文。果然够简单！从Ethereal 解码看，客户端从3849/udp 向服务端3848/udp 发送 login 报文，服务端回应一个UDP 报

3、文。报文里看不到有意义信息，估计是加密了。现在，这个login 过程是一个关键分析点。继续抓一段时间包。发现客户端大约每30 秒向服务端发送一个固定的UDP 报文（源和目的端口也分别是3849 和 3848 ），服务端则返回两个固定的报文。联想到IRC 协议 里的 PING PONG 报文，怀疑这也是一种PING PONG 协议。这也是一个分析点。继续抓包，没看到其它报文。估计在正常情况下login 成功后只要保持不停PING PONG 就行了。逆向分析现在，我们有四个报文：login_request禾口 login_response;ping 禾口 pong 。但是无法看出报文意义。该是逆向

4、分析的时候了。用 IDA 和 DeDe 同时分析客户端程序。为什么还要用DeDe ?因为DeDe 在分析Borland c+/Delphi程序时有比IDA 强的方面，两个配合效果很好。同时启动 OllyDBG attach到客户端程序进程上。 btw, 如果你还在用 SoftICE 分析应用程序，该考虑换换了。-）在 sendto 上下断点。很快就会断下，因为客户端要不停发PING 包，这时候应该是断在发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;这里发送keep alive 包往上面回溯，很容易发现.text:0040D847 call build_keep_alive_pkt这里是构造sendto 出

6、去的 PING 报文的。单步跟踪这个函数调用 ,前面的包构造都很容易理解。最后 :?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 字节清零时，立刻想不会是准备做MD5 吧？IDA 进0040E949处的 call 看看，果然是很标准的MD5_Init -> MD5_Update -> MD5_Final结 构， IDA 进怀疑是MD5_Init 的函数看看，赫然看到MD5 的四个常数。 Great ! 不用单步跟了，把call MD5 时的数据 16 进制 copy/paste 至 U win hex 里，用 win hex 的 HASH 工具计算数据的MD5 ;OllyDBG里直接 F8 跳过这个 call ，和 win hex 里算出的 MD5 值 比较，一样！省了不少时间吧？看来胡适倡导 “ 大胆地假设，小心地求证 ”还是很有道理的。现在很明显， 40E96B 处的 call 必然是加密报文的。IDA 跟