发布建设网站百度竞价开户

案例：

某游戏出现调用寻路函数失败异常崩溃。

基本情况分析：

在刚登陆游戏的时候直接调用寻路函数崩溃。

手动寻路以后再调用寻路不崩溃。(排除了函数编写错误的可能)

猜测可能检测方法：

有某一个标志位(全局类型)在游戏刚登陆的时候没有被赋值。

如果手动寻路以后，该标志位被赋值，再调用该函数可以正常使用。

如果未手动寻路过，该标志位未被赋值，直接调用该函数，产生逻辑错误，产生崩溃。

也就是说我们调用的函数处于标志位被赋值的内层，跳过这个赋值过程，而在更内层函数又对该标志位进行了访问验证。
解决方法：

1.通过来回返回到选角色界面 和进入游戏界面

搜索这个标志位。

返回角色界面会初始化搜索变动的数值，进入游戏以后不会被赋值，再手动寻路以后再搜索变动的数值，来回多次筛选。

最终失败，那失败的原因是什么呢？其实很简单，如果他是一个全局变量，那么他一定是可以扫描到的，但是如果他是一个指针地址，那么我们初始化以后他就变化了，这种方法就不行了，最开始我们猜测他是一个全局类型的标志位，但是目前确定并非全局变量。

2.暴力修改寄存器的方法

在CALL上的寄存器 即使无用，也是会有这些标志位线索的

而不是像书本上说的 只有ECX EBX可能传递参数

我们可以每个寄存器清零 当然不能修改ESP，看哪个寄存器可能和标志位有关系


最后在修改到ESI的时候崩溃了

然后我们追ESI来源，发现ESI是小地图控件对象，而在这控件对象下面有一个标志位，如果打开地图寻路，那么这个标志位为1，否则是0，我们没有手动寻路过的话，就是这个标志位的问题导致崩溃，逻辑很简单，你没打开地图是怎么寻路的呢？

3.返回最外层调用分析全部参数和属性

可以最全面的分析每一个值，而不遗漏

为什么不在最内层调用？因为寻路是多次频繁发包，不像其他函数1-2次发包即可，一段寻路可能上百次发包，那样我们需要自己写寻路算法，发送走路封包了，工作量一下扩大很多，当然如果以上两种办法解决不掉的情况，自己用A*写寻路，貌似也成为了一种方法。

联想：

如果某些游戏存在这样的检测点，而不产生异常，选择让外挂用户悄然不知的措施，再其使用该功能以后的一段随机时间里进行封号处理，是不是对外挂检测和防御起到更大作用。

甚至说让反检测方很难发觉呢？

否则直接崩溃，让人直接抓到突破口，视乎失去了意义。

当然，也许设计者并不是为了 检测考虑，只是单纯的逻辑冲突导致崩溃。

但是这是值得我们借鉴的好方法。