如何在我们的(多人)游戏中防止作弊？

Question

如果你正在写一个游戏，你应该考虑作弊的人，以及如何防止他们作弊。

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

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

我制作了自己的p2p游戏，一段时间后，作弊的人出现了。他们只是使用作弊引擎的scriptkiddies，并尝试过速度攻击和内存攻击。

大多数speedhacks钩子都有gettickcount。我用下面这个简单的技巧整理了一下speedhackers。我只是跟踪time()-GetTickCount()的值，如果差值发生变化，就是作弊。

内存损坏可以通过将散列副本保存在某个位置并始终移动它，并总是通过随机值重新散列它来解决。不匹配会导致崩溃。

要找出作弊引擎，只需检查：

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

(一个朋友告诉我的，我还没有测试过。)

这些把戏挑出了作弊最多的人。但当然还有更多的作弊技巧。我打开这个维基，讨论更多的另一种作弊技巧和避免他们的方法。

Answer 1

我不认为你应该做任何事来停止在单人游戏中作弊。你的用户购买了游戏，他们应该能够作弊，如果他们想要的话，只要他们不是在和别人玩游戏。

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

1)在可能的情况下，“永远不要相信客户”是你最安全的坚持原则。在服务器上执行所有操作，并且只向客户端提供所需的知识，以便在任何给定时间呈现他应该能够在屏幕上看到的内容。也就是说，如果客户不知道隐藏在墙后的玩家的位置，那么墙黑客对用户没有任何好处。对于高速动作游戏来说，这可能是非常困难的-特别是现在实时阴影和诸如此类的是常态，用户可能需要能够看到阴影，即使玩家的身体是可见的-但它应该总是在您的选择的顶部。在点对点游戏上也很难做到，但有一些方法可以限制同行之间的知识。只有当性能变得令人望而却步，或者超出了您的时间/金钱预算时，才应该考虑以下事项。

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

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

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

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

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

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

8)使用自定义专有PE打包器，防止您的游戏被有用的拆解。

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

10)如果使用着色器，请对着色器和着色器常量值进行校验和。

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

Answer 2

你可能会发现Cheat Proof Game Protocols上的这篇论文很有趣。它们都是同一想法的变体:使用散列作为承诺，然后在满足其他参与者的行为条件时揭示散列承诺的含义。它很复杂，而且对性能有影响，但其中一些想法可能是有用的，特别是对于点对点游戏。

Answer 3

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

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

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

这是一种在渲染大型3D场景时提高效率的技术，其本身早已为人所知并应用于游戏/模拟行业。

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

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

尽管如此，还是要区分相关性和“可见性”：被门隔开的两个玩家实际上可能不会“看到”对方，但根据周围环境的不同，很可能会听到对方的声音。因此，区分不同类型的“可见性”：传播可听状态并不一定意味着传播玩家在游戏坐标中的实际位置。反之亦然:仅仅因为你“看到”了一个玩家，你就不一定有资格听到客户的声音(例如，想象一下步枪上的范围)。

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

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