向 什 么 ， 瞬 间 移 动 ， 就 不 是 发 送 了 一 个 平 常 的 数 据 把 坐 标 发 过 去 就 可 以 了。但是有些做得好的网络游戏 ， 它的主机会判断你在这么短的时间里面 ， 不可能移动着么远的距离 。
所以有些 辅 助 程 序 只 能 穿 墙 ， 等 等 那 就 是 移 动 了 一 点 点 距 离。服务器的解决办法 ， 把墙加厚 ， 厚到你不可能在短时间通过 ， 哈哈辅助程序失效 。
我 可 以 提 供 我 写 的 截 获 网 络 封 包 程 序 ， 解 密 工 作 要 大 家 自 己 做 了。应 为 我 的 汇 编 也 不 怎 么 的 ， 只 能 拿 到 汇 编 论 坛 ， 请 大 哥 翻 译。
动 态 调 试 工 具 softi ce, trw2000 trw2000 国 产 软 件 ， 简 单 好 用。支 持 98 softi ce 功 能 强 大。
支 持 98 , 2000。大家要的话在这里留言 ， 好多的人话我把我原来的程序改写一下 ， 提供给大家 。
QQ 登入这些信息都可以截 获 ， 但 是 乱 码 ！ 你 要 自 己 破 解 了 加 密 算 法 才 行。我 说 两 句 ， 1 、网 络 游 戏 ， 客 户 端 和 服 务 器 端 的 几 种 通 讯 方 式 a 、直 接 通 过 Wi nSock 编 程 接 口 进 行 ， 大 多 数 的 网 络 游 戏 采 用 这 个 方 式。
b 、通 过 HTTP 协 议 进 行 通 讯 ， 有 些 网 络 游 戏 利 用 I E 的 组 件 进 行 通 讯。很 少 C、一种设想： 可以同过 SOAP 协议进行通讯 ， 还没有见过这样的大型网络游戏 ， 可能很快就会有 。
2 、服 务 器 端 程 序 的 构 造 方 式 通常是一个接受客户端数据提交和响应客户端数据请求的数据库服务程序 。很多的网络游戏用 SQLServer 作为数据库 ， 服务程序其实很简单 ， 就是接受数据提交和响应数据请求 。
有些服务器端程序给予客户-服务模型 ， 只有客户请求数据他才向客户传输数据 ， 这样这个服务器端演变成了一个普通的数据库应用的服务器端 。客户之间数据同步也都是基于请求-响应模型 。
服务器端通常不主动地向客户端发送数据 。这种模型有一个漏洞 ， 就是客户端可以加快请求的频率以获得更多的服务器相应 ， 这是某些辅助程序的基本原理 。
有些服务器端可以主动地向客户端发送数据 ， 从而避免了这类辅助程序的干扰 。这类服务器端构造比较复杂 ， 它需要纪录链接的客户信息等等 。
为了加快响应时间 ， 平衡负载 ， 某些服务器端使用了 Com+技术 ， 每次客户请求数据或者更新数据的时候需要提供一个连接标志 ， 或者当前客户的状态 。还有的服务器端为了加快响应速度 ， 他根本不纪录客户端的状态 ， 他也不去数据库请求数据进行验证 ， 客户端必须自己记住当前的状态 。
为了防止恶意辅助程序 ， 通常他会检查新数据和客户端提交的状态之间的关系 。3 、辅 助 程 序 的 基 本 方 式 a、提高客户端的时间节律 ， 这里面有很多的方式 ， 一种 ， 提高时钟硬件的节律 ， 和 I ntel 系列的 CPU 的配合的主板在时间控制方式上和早期的 8086 没有任何差异 ， 可以直接修改 ， 在 Wi n2000 下面需要取得 Ri ng0 的权限 ， 可以通过Servi ce 程序获得 。
还有一种截获时间频率的 API 比如 SetTi mer 之类的 API ， 替换成自己的函数 ， 但是这样根据不同的游戏控制节律的方式决定 。这一类方式对于服务器端控制节律的网络 游 戏 是 没 有 效 果 的。