35

如果您正在编写游戏，您应该考虑作弊者以及如何防止他们作弊。

我不认为只有 MMO 多人游戏，还有单人游戏或“自制”p2p mp 游戏。

当游戏完全基于服务器 - 客户端架构时，我认为这项工作几乎完成了，但也有墙壁黑客或其他东西。

我制作了自己的 p2p 游戏，一段时间后出现了作弊者。他们只是使用作弊引擎并尝试过速度黑客和记忆黑客的脚本小子。

大多数speedhacks钩子gettickcount。我通过以下简单的技巧整理出了快速黑客。我只是跟踪time()-GetTickCount()价值，如果差异发生变化，那就是作弊。

可以通过将散列副本保存在某处并始终移动它并始终按随机值对其进行重新散列来解决内存损坏问题。不匹配会导致崩溃。

要彻底解决作弊引擎，只需检查：

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0)
{
   // Cheat Engine runs.
}

（朋友告诉我的，我还没有测试过。）

这些招数把骗子最多。但当然还有更多的作弊技巧。我打开了这个wiki，来讨论更多其他的作弊技巧和避免它们的方法。

4

3 回答 3

58

我认为你不应该做任何事情来停止在单人游戏中作弊。您的用户购买了游戏，只要他们不与其他人对战，他们就应该可以作弊。

以下是我做过的几件事。这些主要是针对锦标赛游戏中的反作弊系统完成的，其中金钱是有风险的，并且对用户系统的一定程度的入侵被认为是可以接受的。我会小心在休闲游戏上做一些这样的事情，因为如果你的游戏不稳定，就有可能导致他们的系统出现问题。

1) 在可能的情况下，“永远不要相信客户”是您要遵守的最安全的原则。在服务器上执行所有操作，并且只向客户端提供尽可能多的知识，以便在任何给定时间呈现他应该能够在屏幕上看到的内容。即，如果客户端不知道隐藏在墙后的玩家的位置，那么墙黑客对用户没有任何好处。对于高速动作游戏来说，这可能非常困难——尤其是现在实时阴影等已成为常态，即使玩家的身体可见，用户也可能需要能够看到阴影——但它应该始终是在您的选项顶部。在点对点游戏中也极难做到，但有一些方法可以限制同伴之间的知识。仅当它变得性能过高或超出您的时间/金钱预算时，

2）打开所有其他进程，并钩住它们的WriteProcessMemory函数，这样它们就不能在你的游戏进程中写入内存。正确完成这一步将阻止 90% 的所有作弊和作弊引擎。

3）做同样的事情，挂钩各种鼠标和键盘仿真功能。这将阻止许多瞄准机器人和其他类型的自动化机器人。

4) 在您的游戏自己的进程中连接到 VirtualProtectEx/VirtualAllocEx/etc 函数，并监控哪些模块正在更改保护级别或分配新的内存块。当您的游戏进行大量分配时，您必须巧妙地处理这一点，以防止它过于占用 CPU，但这是可以做到的。

5) 挂钩 LoadLibrary 函数并监视任何动态加载的 DLL，以防止 DLL 注入。

6) 在你的游戏连接上使用一些轻量级的多态编码。

7) 使用一些反调试技术来防止调试器附加到您的进程。谷歌反调试，你应该能找到很多东西。

8) 使用定制的专有 PE 打包程序来防止对您的游戏进行有用的反汇编。

9) 连接到处理透明度和 alpha 混合的 OpenGL 或 Direct3D 函数和方法。

10) 如果使用着色器，校验和你的着色器和着色器常数值。

11) 对玩家角色使用额外的遮挡剔除技术，以防止他们在视线被其他几何体阻挡时被渲染。它可能对你的表现也有帮助，也可能没有帮助，但它会防止许多墙黑客。

于 2009-06-06T22:25:20.407 回答
16

您可能会发现这篇关于作弊证明游戏协议的论文很有趣。它们都是同一个想法的变体：使用散列作为承诺，然后在满足其他玩家行为的条件时揭示散列承诺的含义。它很复杂，并且会对性能产生影响，但其中一些想法可能很有用，尤其是对点对点游戏。

于 2009-06-07T03:04:29.750 回答
5

当游戏完全基于服务器 - 客户端架构时，我认为这项工作几乎完成了，但也有墙壁黑客或其他东西。

如果您无法将大部分逻辑转移到服务器端运行，那么至少在每个游戏阶段尽可能少地共享状态，换句话说：考虑每个玩家的活动游戏模式，并且只共享信息在当时确实相关。

这不仅可以减少作弊的可能性，还可以减少您的协议造成的流量，即提高效率。

这是一项在游戏/模拟行业中早已广为人知的技术，用于提高渲染大型 3D 场景时的效率。

在那里，“平截头体剔除”用于确定场景的哪些部分实际可见，以便仅渲染相关部分。

类似地，可以使用相同的技术来限制多人客户端仅在它们实际上相关的情况下接收某些更新/信息，例如如果其他客户端实际上在“相关范围”内，以便其他客户端可以检索相应的更新。

不过，请区分相关性和“可见性”：被门隔开的两个玩家实际上可能不会“看到”彼此，但根据周围环境，可能会很好地听到彼此的声音。因此，区分不同类型的“可见性”：传播可听状态并不一定意味着传播玩家在游戏坐标中的实际位置。反之亦然：仅仅因为你“看到”了一个玩家，你不一定有权听到客户的声音（例如，想象一下步枪上的瞄准镜）。

换句话说，尝试将你支持的更新包松散耦合，这样它们就不会相互依赖，也可以独立传播/订阅。

作弊可以通过应用适当的封装和数据隐藏机制在很大程度上得到控制，这样多人客户端通常不会共享全局状态，而是共享状态直接取决于玩家的活动上下文（位置、航向、方向、速度等）。

于 2009-06-07T19:28:02.287 回答