调试案例20170415

前言

一个调试任务悄悄的, 意外的闯进了我的怀里, 我紧紧的将她拥抱. 机会留给有准备的人.
这个软件的源码丢了(公司的代码服务器硬盘坏过,杯具).
以前好使, 现在不好使了. 同事让我弄清软件为啥不好使了, 我只需要定位问题即可.
我从来没接触过这个软件, 但是有懂业务逻辑的同事可以咨询.
将问题解决完, 因为初试牛刀, 所以有点小开心.

记录

软件是用vc写的, 编译的调试版, 连pdb的路径IDA都有提示.
病症: 软件运行后, 直接退出了. 为啥呢? 这是同事想知道的.

目标软件的附加

这软件是以admin身份运行的, 运行在session4, 不是当前桌面.
我得让软件运行后,先停下来再debug她. 得找个容易操作的方法.
开始想手工inlineHook, 在winMain入口后面,没开始干活的时候, 跳到空白区,弹出messageBox. 后来发现, 运行在win2008上时, 映像基地址动态变化(如果要弹框, 且不说我能不能点击MessageBox上的确定按钮, 为了能适应imageBase动态变化, 还要去做地址修正,好繁琐), 那就不是vc6写的程序了. 我也没用DIE查看是啥写的.
最后的方案是:在winMain后面跳到空白区,写个死循环,然后调回去执行正常流程.
等附加上,动态将死循环的代码用NOP填充,就可以debug正常流程了.
这时, 将打过补丁的程序替换同名目标程序.

调试器的选择

目标软件是x86的, 开始用ollydbg1.1试了下. 用管理员身份启动pediy版的ollydbg1.1, 居然附加出错, 杯具…

现在还有2种选择, x64dbg和windbg. 挨个试.

下载了最新版的x64dbg, 用管理员身份启动x64dbg32, 尝试附加, 在列表中有目标软件.附加正常. x64dbg这点好, 只列出自己能附加的软件. x64dbg做的越来越好了, 还开源, 赞一个. x64dbg用qt写的, 等以后也编译源码, 改改代码玩玩.

记录错误流程点

用软件开始, 每经过一个分支, 都记录was jmp或者not jmp, 直到目标程序退出(ExitProcess).
因为软件没有对抗, 结合IDA查看, 发现这些跳转点,有些在系统函数里面, 搞挫了…
因为没有可用的正常场景用于记录正确的流程点, 只能在call一个函数时, 进入看看.
这时结合x64dbg32和IDA, 加函数标号, 防止进系统函数单步.

问题的初步原因

大致跟了一下, 客户端向服务器send包,服务器回包后,客户端判断不成功,走错误流程退出程序. 通讯在反汇编层面看到的都是socket操作, 可以看到connect, send, recv函数的调用.

我将服务器ip和port报给同事. 他对业务熟悉, 让我查下ip和port从哪读来的.
按照流程启动程序, 在connect函数执行前, 可以看到取服务器参数是从配置文件中来的.同事让我将ip换成另外一个, 还是不好使.

问题原因的定位

现在就要看回包判断了.

v12 = fnSocketSend_4098F0(s, a2, a3);            if ( v12 >= a3 )            {              v12 = fnRecvFromRemote_409950(s, a5, 276);              if ( v12 >= 276 )              {                if ( *(_DWORD *)(a5 + 264) )    // 错了                {                  fnCloseSocket_409750(s);                  result = 8;                   // 错误码为8                }

从伪码可以看出, 客户端发送包给服务器, 收包期望276字节.
如果收包不到276字节,就错了.
这个276字节是自定义的协议, 有可能是一个结构体.
如果结构体地址+264的地方不是0(S_OK), 就是服务器不乐意了,客户端也不能走正确流程.

问题的解决

将错误定位的结果报给同事, 他再看服务器工程(就是他实现的java程序), 还有设计文档哦. 对着文档一看, 276个字节的回包果真存在, 回包加264的地方果真是成功或失败的指示DWORD值.

那就没我啥事了:)
过了一会, 同事告诉我, 确实是他的工程出了问题(服务器的java程序维护过), 对客户端发包内容的判断做了更多限制, 导致正确的发包也会判断成不成功.

有点小开心^_^