bp send 的腐朽和神奇_写给新人 UP

Summer.殇

bp send 的腐朽和神奇_写给新人 UP

每每在其他技术论坛一提到 海大家就会取笑我：“ 海呀，就是那些只会BP SEND 和CTRL+F9 的那些人啊”，听到这样的嘲笑起初自己也十分瞧不起BP SEND有段时间甚至刻意避免使用这个断点。其实不是人家的错，是我们自己将BP SEND这把利器用死了，学东西把东西学死了是非常大的悲哀，我们要用聪明智慧来展示出自己的实力，实力可以攻破任何谣言。

诚然BP SEND在网游发展的初期是一把无往而不利的万能断点，因为客户端总要跟服务器通讯，所以一有动作就会断下来。而现今网游开发人员都有防范 的意识和手段，在他们的作品中自然对于大家手中的这个BP SEND会使出各种手段加以遏制。

举个简单的例子，星尘传说 这是我第一个研究的游戏 他就专门针对BP SEND做了很好的处理，专门做了一个负责发包的模块，通过消息和事件跟主体程序进行通讯，我们的单步跟踪自然无法跟随消息追随到功能CALL，无数次的CTRL+F9都只能深陷在一个无尽的消息等待循环中。还有些强力的游戏制作者，自己编写WS2_32.DLL，用于网络通信，我们还傻乎乎的去截取系统API自然是一无所获。还有些开发商会HOOK  WS2_32.DLL，监测用户的动作，触发了它的规则轻则掉线，重则封号。

游戏在进步，而我们只知道 BP SEND + CTRL+F9 可想而知，太公钓鱼。

我们先讲如何穿透消息封锁的BP SEND
原理：虽然消息和事件可以阻挡我们对代码的回溯跟踪，但是作为程序运行的忠实记录者 “堆栈”却将程序运行的关键步骤都记录下来了。然而，堆栈中并不会记录所有的CALL调用。示意图：

模块1： 游戏主体进程
  ↓
模块2： CALL1(获取技能ID)→CALL2(获取角色ID)→CALL3(获取目标ID)→CALL4(错误检查)→压入技能ID参数 压入角色ID参数 压入目标ID参数→技能CALL5(id1,id2,id3)→CALL6(发送消息给发包等待模块)


模块3：CALL7(消息等待模块)
                ↓↑
send( );

这就是一个使用消息阻断BP SEND跟踪技能CALL的反调试手段，我们使用CTRL+F9无法跨越CALL6 和CALL 7 ，只能在 CALL7 和SEND()之间无限循环。
而以上过程在堆栈中能在BP SEND断下时留下什么呢？答案是会留下CALL 6  CALL 7的踪影，我们并不会看到我们想要找到的技能CALL，会得到类似的堆栈内容：

0012F07C  003AF1D5  返回到 Lua5.003AF1D5 来自 Lua5.0039AAD0
0012F080  00000000
0012F084  /0012F0A0
0012F088  |77D1B6A3  返回到 USER32.77D1B6A3 来自 USER32.OffsetRect
0012F08C  |0012F1F8
0012F090  |FFFFFFFC
0012F094  |FFFFFFE9
0012F098  |0012F174
0012F09C  |0D3A3000
0012F0A0  ]0012F0B0
0012F0A4  |77D1C1A2  返回到 USER32.77D1C1A2 来自 USER32.77D1C1AE
0012F0A8  |00721B88
0012F0AC  |77F0ED36  返回到 GDI32.77F0ED36
0012F0B0  \00000006
0012F0B4  003AAEFE  返回到 Lua5.003AAEFE 来自 Lua5.003AAE90
0012F0B8  1994BFB0
0012F0BC  00000050
0012F0C0  0347DC70
0012F0C4  00000000
0012F0C8  12630438
0012F0CC  0012F0E8
0012F0D0  /0012F0E8
0012F0D4  |0039ABA7  返回到 Lua5.0039ABA7 来自 Lua5.003ADEC0
0012F0D8  |12630438

堆栈中记录的是模块与模块中相联系的CALL的返回地址，同时还会残留下来部分模块内部曾经压入到堆栈的对后面进程有用的参数。

事有蹊跷，人有傻笨的，有聪明的，我们先讲体无脑方法：
老天是公平的 辛勤的汗水总会有回报，在寻找CALL之前如果做足了准备工作的话，那一些基本的数据例如人物ID 技能ID  怪物ID这些通过看就能看出来大概是个什么样子，数据是几位，都什么开头，例如角色ID  23e7 怪物ID 4000329 技能ID 77512等等，有了这些辛勤的劳动成果，我们很容易在堆栈中发现他们，有这些数据传递的过程就是我们要找的地方，自然通过反复的跟踪测试我们能够找到最终想要的技能CALL，但是，事无绝对，如果你在堆栈中捕捉不到这些ID 的踪影那再辛苦的劳动也会徒劳一场。


下面就介绍个简单易行的办法：

我们都知道技能CALL释放的时候是有许多条件限制的，例如蓝是否足够，目标是否存在，是否有障碍等等，我们就抓住这里，进行展开。

方法：使用内存搜索工具CE或者其他的可以搜索该游戏的工具对提示信息进行搜索，例如：“没有目标”，得到这些数据的存储地址，然后再OD或者其他调试器里，对该段内存下内存访问段，断下来之后，我们就会得到一个完整的堆栈内容，我们将所有的堆栈内容拷贝出来，存到一个文本文件里。
然后，我们使用BP SEND下断，截获技能CALL释放的包，同样也会得到一个完整的堆栈数据，存放到另一个文本文件里，我们对得到的2组 堆栈数据进行对比，从下向上，找到不同的地方就是你们该关注和下手的地方了。至于BP SEND的一些技巧就不详细说了，多数都是使用条件断点来达到截取特定数据的。

通过上面的“堆栈对比法”，我们就能找到合适的切入点，找到技能CALL，并且顺带将一些技能相关的错误处理CALL也给找到，什么CD冷却呀，障碍物啊等等。

小结：
上面通过很长篇幅来说明如何灵活应用BP SEND，也就是不能单纯的使用BP SEND，要和其他的一些断点和方法结合起来使用，才能达到理想的效果。在实际应用中我们还有更多这样的应用实例，大家也不要看完本文就心满意足，啊！我又学到了一种找技能CALL的方法啦，这样就太令我失望了，我要教给大家的不是一种技巧，是一种思维方式，我希望的是你们自己能创造出来更多更灵活的使用方法，这才是我写本文的目的，学习分几个阶段，基础知识，基础技巧，熟练后就要自己创造技巧，方为尚。



联系我时，请说是在 挂海论坛 上看到的，谢谢！

zhuzhuli

……

YING仔094

好好的帖子，必须得顶起

最复杂的单纯

顶，楼主v5

开心快乐

怎么没看懂， 还得加油，学些基础的再来看