我正在制作一款多人游戏,我需要验证玩家没有进行速度黑客攻击

发布于 2024-10-07 19:04:37 字数 466 浏览 1 评论 0原文

出于安全原因,我觉得测试应该在服务器端完成。尽管如此,这会对服务器造成相当大的负担,对吗?考虑到玩家佩戴的装备和增益,他们会有更高的移动速度,所以每次他们移动时,我都需要计算新的常数,看看他们的移动是否合法(使用 TCP,所以不需要担心丢失,无序数据包)。我意识到我可以只保存最后的移动速度,并且只有在他们更改了影响其速度的某些内容时才重新计算它,但即便如此,这也是另一项检查。

我的另一个想法是,服务器随机选择客户端发送的数据并验证它,并为每个客户端提供信任评级。足够低的信任评级意味着来自客户端的每条消息都会受到检查,并且他们的所有操作都会以更详细的方式记录。然后我会通过检查日志知道他们正在进行黑客攻击,并可以禁止/暂停它们以及撤销他们可能通过黑客攻击传播的任何好处。

任何建议表示赞赏,谢谢。

编辑:我刚刚意识到还有一种情况是黑客可以连续发送微小的动作(在其正常速度的能力范围内)。每个单独的动作都是合法的,但累积的效果将是速度黑客。有哪些方法可以解决这个问题?

For security reasons I have a feeling that that testing should be done server side. Nonetheless, that would be rather taxing on the server, right? Given the gear and buffs a player is wearing they will have a higher movement speed, so each time they move I would need to calculate that new constant and see if their movement is legitimate (using TCP so don't need to worry about lost, unordered packets). I realize I could instead just save the last movement speed and only recalculate it if they've changed something affecting their speed, but even then that's another check.

Another idea I had is that the server randomly picks data that the client is sending it and verifies it and gives each client a trust rating. A low enough trust rating would mean every message from the client would be inspected and all of their actions would be logged in a more verbose manner. I would then know they're hacking by inspecting the logs and could ban/suspend them as well as undo any benefits they may have spread around through hacking.

Any advice is appreciated, thank you.

Edit: I just realized there's also the case where a hacker could send tiny movements (within the capability of their regular speed) in a very high succession. Each individual movement alone would be legite, but the cumulative effect would be speed hacking. What are some ways around this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

淡淡的优雅 2024-10-14 19:04:37

处理这个问题的标准方法是让服务器计算所有移动。客户端应该发送到服务器的唯一内容是命令,例如“向左移动”,然后服务器应该计算玩家移动的速度等,然后最终将更新的位置发送回客户端。

如果你把任何计算都留给客户,那么迟早有人会找到作弊的方法。

The standard way to deal with this problem is to have the server calculate all movement. The only thing that the clients should send to the server are commands, e.g. "move left" and the server should then calculate how fast the player moves etc., then finally send the updated position back to the client.

If you leave any calculation at all on the client, the chances are that sooner or later someone will find a way to cheat.

诺曦 2024-10-14 19:04:37

[...] 测试应该在服务器端完成。尽管如此,这会对服务器造成相当大的负担,对吗?

没有。这是这样做的方法。这是唯一的方法。所有关于检查信任或任何本质上的缺陷的讨论,都以某种方式存在。

如果您让玩家发送位置:

  • 检查某人声称的位置。
  • 与他们不久前的情况进行比较。允许一点点偏差来解决网络延迟问题。
  • 如果它们移动得太快,请将它们重新放置在更合理的位置。小错误可能是由于长时间的滞后造成的,因此客户应该使用插值来平滑这些更正。
  • 如果它们移动得太快,请将它们断开。并检查代码中的错误。
  • 不要忘记处理长距离的合法遍历,例如。传送。

[...] testing should be done server side. Nonetheless, that would be rather taxing on the server, right?

Nope. This is the way to do it. It's the only way to do it. All talk of checking trust or whatever is inherently flawed, one way or another.

If you're letting the player send positions:

  • Check where someone claims they are.
  • Compare that to where they were a short while ago. Allow a tiny bit of deviation to account for network lag.
  • If they're moving too quickly, reposition them somewhere more reasonable. Small errors may be due to long periods of lag, so clients should use interpolation to smooth out these corrections.
  • If they're moving far too quickly, disconnect them. And check for bugs in your code.
  • Don't forget to handle legitimate traversals over long distance, eg. teleports.
夜还是长夜 2024-10-14 19:04:37

解决这个问题的方法是所有操作都在服务器上完成。永远不要相信来自客户的任何信息。如果有人真正玩你的游戏,就会有人对与服务器的通信进行逆向工程,并找出如何利用它。

您不能随机分配信任评级,因为谨慎的作弊者只有在真正需要时才会作弊。这给他们带来了相当大的优势,被发现作弊的可能性很低。

是的,这意味着您无法使用低级服务器,但确实没有其他方法可以防止客户端作弊。

The way around this is that all action is done on the server. Never trust any information that comes from the client. If anybody actually plays your game, somebody will reverse-engineer the communication to the server and figure out how to take advantage of it.

You can't assign a random trust rating, because cautious cheaters will cheat only when they really need to. That gives them a considerable advantage with a low chance of being spotted cheating.

And, yes, this means you can't get by with a low-grade server, but there's really no other method of preventing client-side cheating.

香草可樂 2024-10-14 19:04:37

如果您使用能够访问 Windows API 函数调用的语言进行开发,我从自己对速度黑客的研究中发现,您可以通过调用两个函数并比较结果来轻松识别速度黑客。

TimeGetTime

和...

GetTickCount

两个函数都会返回秒数自系统启动以来。但是,TimeGetTime 比 GetTickCount 准确得多,而 TimeGetTime 的精确度高达 ~1ms,而 GetTickCount 的精确度约为 ~50ms,

尽管有一点延迟在这两个函数之间,如果您打开速度黑客应用程序(选择您的毒药),您应该会看到两个结果集之间存在非常大的差异,有时甚至长达几秒钟。差异非常明显。

编写一个简单的应用程序,返回 GetTickCountTimeGetTime 结果,而不运行速度黑客应用程序,并使其保持运行。比较结果并显示差异 - 您应该看到两者之间的差异非常小。然后,在您的应用程序仍在运行的情况下,打开速度黑客应用程序,您将看到两个结果集的巨大差异。

诀窍在于弄清楚什么阈值将构成可疑活动。

If you are developing in a language that has access to Windows API function calls, I have found from my own studies in speed hacking, that you can easily identify a speed hacker by calling two functions and comparing results.

TimeGetTime

and...

GetTickCount

Both functions will return the number of seconds since the system started. However, TimeGetTime is much more accurate than GetTickCount, whereas TimeGetTime is accurate up to ~1ms vs. GetTickCount, which is accurate at around ~50ms

Even though there is a small lag between these two functions, if you turn on a speed hacking application (pick your poison), you should see a very large difference between the two result sets, sometimes even up to a couple of seconds. The difference is very noticable.

Write a simple application that returns the GetTickCount and TimeGetTime results, without the speed hacking application running, and leave it running. Compare the results and display the difference -- you should see a very small difference between the two. Then, with your application still running, turn on the speed hacking application and you will see the very large difference in the two result sets.

The trick is figuring out what threshold will constitue suspicious activity.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文