2.17z之网游逆向分析之从0开始找明文call的二次在探，纠正思路

墙和鸡蛋

2020年2月17 某网游明文包二次探索


这个是2.14的明文包过程，想弄明白这边文章，发起还是去看下



这是我前天发表的文章，然后昨天夜里想再次看下这个明文包的逆向，发现这个帖子里的方法存在一定的随机性
:funk:eweqw {:1_900:}


也就是我再次用这个方法去找的话，不是每一次都能找到，以是说我找的时候有可能存在偶合的情况下找到了
而且是堆栈窗口找了很多返回地点才发现的，以是我们必须弄明白，到底是怎么回事

然后我再次研究了一下，起首我们来看一下这个游戏的发包流程




我大概理解的这个游戏发包的过程大概就应该是这样
至于收包，我不想研究了{:1_886:}

至于加密完成后写入另外一个地点是一直朝后写
好比说给了以个1000K的空间

然后写完了就从头再来，用类似于一种“标识”来分段数据。

那么我们的突破点就是“加密完成”之后向另外一个地点写入加密数据的时候


下面看正文

起首 bp ws2_32.send




可以看到发包date地点

那么数据窗口跟随这个date地点


观察包发现包在地点+4的位置不停变更但是地点稳定
直接在地点+4的位置下硬件写入断点

来到下面这个图




这点就印证了我第一个流程图的思想，就是数据是从esi写道edx里的，那么这个esi什么套路呢，继续看看数据窗口跟随



这里赤色的字节就是被改变的值，而且每次都是朝下改变，也就是我上面说的给了一个好比1000K的空间写入
然后用“标识”来识别

那么怎么判定写入了多少呢，这里又两个方法
一个随机点，一个可以固定，但是麻烦点
随机的就是，既然我们知道了一直朝下写数据，那么观察两次这个地点，然后相减，我这里得到的是大概0x66字节每次写入
第二个就是好比你发送打坐call，我在第一篇文章写过，就是组成0d个字节的包，然后每3个字节加密成4个字节
就是16个字节，然后加上28是头，29 00是尾，那么就是19个字节，然后在加上系统的固定给的“标识”能算出每次写入的数据大小
我这里就随机点，大差不差


由于这里断线了，以是地点可能不一样了，不管他，上游戏继续，在第一个得到的地点+66写入硬件写入断点，我这里多加了5个字节，由于是大概算的

好的，断在这里了（这里可能是由于刚上游戏的原因，这里朝下继续写都是00 也就代表第一次还没写完系统分配的空间，如果完了一会在回来看，这里就没有00 是重复写入）

那么看右边红框框里的堆栈图
第一个返回到反汇编看，然后在头部下断点，返回发现不对，经验证继续返回是已经实现功能，不是我们要的
那么继续在堆栈第二个地点反汇编的头部下断


到这里了。下一个f2断点
然后出现了一个征象就是会自动断下，而且和心跳包的频率差不多，我们有空间在游戏里面利用
继续打坐断下了


然后返回了大概3次，发现了这儿，是不是很像组包，不用怀疑，就是功能组包地点，也就是我们要找的明文call
其实到了上图的时候，我们就已经可以从寄存器窗口找到刚加完密的临时地点了，而且是稳定的



在这个组包过程下断，可以很直观的看到明文数据了



到此就结束了，经过验证，保证每次都能返回到call 004efeb0这个功能组包call位置，而且都是在堆栈的第二个返回地点
大功告成，收工。



来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！