004 两种方法找寻路call

文章目录

关于寻路call
通过参数找寻路call
- CE搜索寻路目的地坐标
- 通过参数定位寻路call
- 寻路call参数分析
- 寻路call代码测试
寻路状态找寻路call
- 搜索寻路标志位
- 通过寻路标志位找寻路call

关于寻路call

寻路call在大部分的游戏里都是存在的，游戏的策划为了用户体验，一般都会自带寻路的功能，可以一键自动让人物到目的地。

但是也有一些游戏不包含寻路call，那样的游戏就需要我们去找一些地图数据以及障碍的遍历判断等等，再自己用算法去实现。

这个寻路call不太适合用send断点回溯去找，因为在寻路的过程需要不断的向服务器发送数据包，是一个比较复杂的过程，里面可能有很多循环和逻辑算法。单纯通过一个简单的调用关系不一定能找到这个call。

通过参数找寻路call

CE搜索寻路目的地坐标

在找这个call之前我们先来思考一下这个call会有什么样的参数，参数可能会有很多个，但是有一个参数是必然存在的，就是寻路的目的地坐标。

这里有三个坐标分别是XYZ，选择任意一个即可。

先让人物进行寻路，寻路完成之后，当前的人物坐标就是目的地坐标。接着搜索人物当前的坐标。

坐标在内存中的形式都是用的浮点数，浮点数的值是经过四舍五入以后显示到游戏界面的，所以这里要搜索一个区间的值，而不是搜索精确值，区间尽量给大。

接着让人物进行寻路，寻一个远一点的位置，这个时候寻路目的地坐标发生改变，此时在CE里搜索变化的值。

然后在人物寻路的过程中目的地坐标是不变的，我们可以一直扫描未变动的值

等人物到达目的地以后，再用根据当前的人物坐标进行一个范围的浮点数值扫描。

一直重复这个过程筛选掉CE的结果，最后会剩下二十多个，这二十多个值都是一样的，都等于当前人物的坐标。那么说明这些值都是人物的目的地坐标。这种情况只能一个一个去测试。

通过参数定位寻路call

这里有两个基地址，有基地址的情况当然优先考虑选择用基地址。

打开OD，在这两个基地址下四字节的硬件写入断点。然后让人物寻路，此时OD断下

此时[edi+0x2C]是我们的目的地坐标，然后下面这个call将坐标作为参数传入下面的call，那么这个call有可能是寻路call，也有可能是在寻路call的内部对参数进行处理。

删除硬件断点，Ctrl+F9执行到返回，上面的这个call也可能是寻路call。

实际上这两个call都是寻路call，里层的寻路call有点类似于封包，需要对数据进行组包，所有的数据糅合在一起，分析起来不是那么方便。外层的寻路call参数多，比较清晰，分析起来方便。这里我们选择外层的寻路call进行分析。

寻路call参数分析

我们在外层的寻路call下断，让游戏断下。

esi这个地方是一个常量1，多测试几次会发现这个参数的含义是地图ID。

往上翻一下也可以找到这个地图ID的一个基址表达式

edx是一个地址，指向的地址内容是和当前的人物坐标是一致的，那么edx就是出发点的人物坐标，坐标在内存中的存储形式是XZY

D1F930这个地址有点眼熟，回到CE

这个地址正是我们用于找call的切入点，也就是目的地的坐标

最后一个参数ecx是一个当前模块的基址，没有什么特殊含义

寻路call代码测试

接下来用代码注入器测试一下我们找到的这个call是否有效

首先随便找一块地址按照XZY的方式填入出发点的人物坐标

然后在0D1F930填上人物的目的地坐标

在注入器填上相关的汇编代码，注入到游戏进程，效果如图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ek4EuVau-1586586062769)(004 两种方法找寻路call.assets/自动寻路.gif)]

寻路状态找寻路call

搜索寻路标志位

当人物正在寻路的时候是处于跑动的状态，不寻路的时候人物处于站立不动的状态。在寻路call的内部一定会对这个状态进行改写。

利用这个特点我们可以利用状态值作为突破口，来定位到寻路call

首先在人物寻路的过程中搜索1

然后在人物寻路结束的时候搜索0

最后可以筛选出三个地址，我这里正确的地址是第二个，大家需要去挨个测试。

通过寻路标志位找寻路call

打开OD，在寻路标志位下硬件写入断点，等游戏断下

打开调用堆栈，找到最后一个call，显示调用

这个地方，就是我们之前找到的寻路call。

代码之前已经测试过了，这里就不再测试。另外这个call的参数有出发点的人物坐标，也就是说以当前人物坐标为切入点也是可以找到这个call 的，各位可以自行尝试，到此分析结束。