004 两种方法找寻路call
文章目录[*]关于寻路call
[*]通过参数找寻路call
[*]CE搜索寻路目的地坐标
[*]通过参数定位寻路call
[*]寻路call参数分析
[*]寻路call代码测试
[*]寻路状态找寻路call
[*]搜索寻路标志位
[*]通过寻路标志位找寻路call
关于寻路call 寻路call在大部分的游戏里都是存在的，游戏的策划为了用户体验，一般都会自带寻路的功能，可以一键自动让人物到目的地。
但是也有一些游戏不包含寻路call，那样的游戏就需要我们去找一些地图数据以及障碍的遍历判断等等，再自己用算法去实现。
这个寻路call不太适合用send断点回溯去找，因为在寻路的过程需要不断的向服务器发送数据包，是一个比较复杂的过程，里面可能有很多循环和逻辑算法。单纯通过一个简单的调用关系不一定能找到这个call。
通过参数找寻路callCE搜索寻路目的地坐标 在找这个call之前我们先来思考一下这个call会有什么样的参数，参数可能会有很多个，但是有一个参数是必然存在的，就是寻路的目的地坐标。
这里有三个坐标分别是XYZ，选择任意一个即可。
先让人物进行寻路，寻路完成之后，当前的人物坐标就是目的地坐标。接着搜索人物当前的坐标。 坐标在内存中的形式都是用的浮点数，浮点数的值是经过四舍五入以后显示到游戏界面的，所以这里要搜索一个区间的值，而不是搜索精确值，区间尽量给大。
接着让人物进行寻路，寻一个远一点的位置，这个时候寻路目的地坐标发生改变，此时在CE里搜索变化的值。
然后在人物寻路的过程中目的地坐标是不变的，我们可以一直扫描未变动的值
等人物到达目的地以后，再用根据当前的人物坐标进行一个范围的浮点数值扫描。
一直重复这个过程筛选掉CE的结果，最后会剩下二十多个，这二十多个值都是一样的，都等于当前人物的坐标。那么说明这些值都是人物的目的地坐标。这种情况只能一个一个去测试。
通过参数定位寻路call 这里有两个基地址，有基地址的情况当然优先考虑选择用基地址。
打开OD，在这两个基地址下四字节的硬件写入断点。然后让人物寻路，此时OD断下
此时是我们的目的地坐标，然后下面这个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 的，各位可以自行尝试，到此分析结束。
相关工具：
https://github.com/TonyChen56/GameReverseNote
太给力了，这么多好东西！
页:
[1]