iNode协议再次分析

iNode协议再次分析

声明：

1)本报告由博客园bitpeach撰写，版权所有，免费转载，请注明出处，并请勿作商业用途。

2)若本文档内有侵权文字或图片等内容，请联系作者bitpeach删除相应部分。若认定侵权，请向本作者提供相关建议和材料，本人在确定公司来源无误下，尽义务地在24小时内删除。如若本人未能及时查收邮件，则可联系博客园站长删除。

3)本文档内容主要涉及iNode客户端逆向研究的主题，但较为简单可以认为是初步入门，贻笑大方请指正。

4)仅仅作为参考用途，抛砖引玉，不作为证据证明用途，请自行取舍，核实引用。最后声明本博文为开源学术研究，见贤思齐，秉承GNU GPL v2许可协议（由于种种因素，为保护隐私对数据包做了部分隐匿处理，这与本文开源宗旨并不相悖。如果部分数据包隐匿处理依然暴露我的信息，请评论提醒我，感谢。我不想被人挖坟）。本文内容不应用于任何商业目的及利益，请勿利用本文作商业利益活动。

iNode出了一些问题

今晚忽然看到iNode上不去了，需要验证某某了。但是一时理不出头绪，所以简要和大神bitdust一块抓了个包，但是大神跑了= =

1.1 2014年11月13日

这个时间节点是我第一次真正关注UDP报某某号的问题。

上图为当时2014年11月13日抓取的包。可以注意到当时这个包还是通过UDP服务报的.

但是今天再抓今天的包时，找不到这个UDP包，说明问题已经产生变化，可能现在不出在UDP问题上，所以我搜索了一下关键词，发现这样一个包，很奇怪。

1.2猜测

未知状态包可能是新增的自定义模式，其采用的格式需要进一步探索。我抓取了多人的数据包，发现某人也是类似问题。总结可能出现的状况如下：

（1）客户端版本没有更新，因为规程主体未变化

（2）某某验证号更新，不会影响网关变化，只是服务器认证。所以不会出现交换机断掉的现象，只是上不了网的现象。

（3）报某某号由UDP更为EAP包，极有可能更新了规程，但值得验证和讨论。不过可能性极大，因为UDP是尽可能交付服务，交付不上也不会产生问题。也就是说如果使用udp报某某号，没有验证也就没有验证了，无妨，不会影响上网。正是由过去的UDP模式改变为EAP，所以影响了上网。这不可能是客户端做到的，只能是服务端做的事情。因为大家的客户端没有变化。

（4）使用bitdust客户端一定程度上可以解决这个，大神提供了虚拟机的思路。至于我本人有两种方式思路可以解决它

我想有两种方式，一是老老实实更新和登记某某号码。二就是，好好研究bitdust你的路由器，为什么你的路由器会没有问题，这说明你的路由器破解了现在的方法！= =大神bitdust你果然很厉害！有先见之明。我想可能是socks你的新插件问题？既然没有封住你的路由器，说明你的路由器是疫苗。研究它就有用。我要紧跟你的步伐却学习协议问题。