原创

协议解析Bug分析

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://elastic.blog.csdn.net/article/details/40480235

协议解析Bug分析

 

       源自邮件协议RPC(远程过程调用)处理的Request请求数据包的bug

       一、Bug描述

       腾讯收购的Foxmail客户端可以作为outlook客户端的替代品与Exchange服务端进行交互完成邮件收发。而我们所要做的就是让邮件经过我们代理的优化处理。

       这时候问题来了,Outlook客户端经由我们代理没有任何问题;但是换成Foxmail就会有错误弹窗,错误号:0x000006BE。但是如果不经过代理,Foxmail收发邮件一切正常。

       很明显,是代理出了问题。

       二、不知道如何排查?

       又是面对不熟悉的6万行以上的代码,又是不熟悉的框架,又是文档混杂,又是项目进度非常赶……

       还好是必现的环境,还好还有日志、还有wireshark的分析。

       初始的时候由于不知道虚拟机开启了混杂模式,导致wireshark抓的数据包有大量的Retransmit数据包以及很多out of order(失序)数据包。所以抓住的点是某个包被重传了两次,然后找日志哪个包重传了两次?

        由于日志里确实没有找到重传数据包,再来怀疑之前的分析?这才找到了混杂模式导致了误分析。特将混杂模式和普通模式定义列举如下:

        混杂模式就是接收所有经过网卡的数据包,包括不是发给本机的包,即不验证MAC地址。普通模式下网卡只接收发给本机的包(包括广播包)传递给上层程序,其它的包一律丢弃。一般来说,混杂模式不会影响网卡的正常工作,多在网络监听工具上使用。

        三、根本原因

        最后思路还是结合日志分析抓包,看到对于RPC的请求数据包(request)的加密数据长度和日志打印不一致,顺着代码去读,发现是Foxmailoutlook多了一个比特标记位置为1(此为根本原因),导致多出了表示回话UUID16个字节的数据。在数据处理中取长度和取数据段结构体赋值的时候导致偏移出错。

       四、阶段小结

       虽然找到偏移出错的根本原因,但是要彻底解决bug还有很长的路要走。代理中有几十处能搜到的和偏移有关的数据项,有些变量不能见名识意,还需要跟读代码逻辑。

       深刻体会到协议解析常犯的两个错误

        1)对于协议的解析,马虎不得,偏移一个比特可能剩余的解析会全部出错;

        2)协议解析有些字段或者标记位是可选项,比如大多是情况用户不去选择则该字段就没有意义。但是作为程序员的我们要考虑到一旦用户选择的情况,做好分支判定处理。

协议解析必须严格参考协议文档,考虑相当全面,马虎不得。

 

        2014-10-26 pm8:39思于家中床前

 

作者:铭毅天下

转载请标明出处,原文地址:http://blog.csdn.net/laoyang360/article/details/40480235

如果感觉本文对您有帮助,请点击支持一下,您的支持是我坚持写作最大的动力,谢谢!

文章最后发布于: 2014-10-26 20:42:57
展开阅读全文
0 个人打赏
私信求帮助

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503

分享到微信朋友圈

×

扫一扫,手机浏览