In short, no. However, you can obfuscate Javascript to make it much more difficult.
For things like scores, a user could in theory POST any score to your handler script. In this case you could use a session and regularly post back to the server through AJAX.
Store the games internal state sever side and check the input send by clients on the server.
Autoaim: Create fake sprites which are invisible to normal players, if they get hit too often you have a bot. (will not always work as the bots may be updated to check for invisibility)
check client reaction time to changes on the server, check for too many too fast reactions. (has to accept a large number of fast responses before reacting as a human could react fast and the time has to account for the network delay to catch anything). Give the player some sort of captcha, a regular player would never see it.
Client side:
use obfuscation to make it harder to interface with your code
check for functions defined in the hacks you know about. Has to be modified/updated often as the creators of such hacks can work around those.
Game design: making your game less repetitive this makes it harder to write tools/bots for it.
update the client to change parts of its structure from time to time. While this will not stop bots it will take work to keep them running. Either make it transparent to the user or disguise it with a new feature.
Important: make sure your server interface checks the user input, obfuscation and client side checks wont help against someone writing their own client.
I like the question, and while there are probably better answers, here are a few off the top of my head that may (or may not) work:
Obfuscation. Yea, it's not guaranteed and someone can eventually get to it, but it's a pain in the butt to deal with sometimes.
Generate the JS with a new temporary token each time. You may be able to templatize the .js running the code and insert a server generated token that differs per each instance. The token could be temporary and it could be one way to validate the authenticity of the code
There's probably some way to determine the proper location of the script being run - but this could probably be faked
In general, its hard, and all of the suggestions above can be worked around. I guess the key is to make it hard for them to cheat, but given that there are cheaters for even secure online mode games, it's going to be hard to prevent JS games from being susceptible to that as well.
Is there any fundamental way to protect people from doing this sort of thing by designing your game code in a certain way?
The only sane method is to keep critical pieces of the code on servers you control and never give it to the users' computers at all. The hard part is making this square with keeping the game fast enough to be playable.
You're attempting to do the impossible. The best advice I can give you is that if you are plan on persisting any data like coins/money/gold, levels, whatnot you make sure you never trust the client and make as much logic server sided as a possible.
{
task: "mynamespace.baz=mynamespace.foo;mynamespace.foo=undefined;",
challenge: "mynamespace[11].toString().substr(10,22)"
// get part of a well-known functions source code
}
{
task: "mynamespace.bar=function(){ /* new code here */ }",
challenge: "var xy=0;mynamespace.each(function(item){xy+=item.toString().lastIndexOf(';')}); xy"
// accumulate the last index of a semicolon in all elements
// of the namespace
}
I think the way to go would be to write the client in a way such that you dynamically alter the client code and verify the use of thusly created code on the server.
E.g. have a namespace like this
window.mynamespace = {
foo : function(){
// some stuff here
},
bar : function(){
// some more stuff here
}
}
which contains all your client code and make all your server methods require a token that is the result of a previous dynamic evaluation of the code base. make this harder by redefining methods and changing method names. Here are a few sample challenges (this only makes sense if challenges are created dynamically and not predictable). All contain a task first and then a challenge that will be used to create the authorization token for the next request. (These are response objects from the ajax calls). Basically the task will be eval'd and the result of the eval'd challenge will be the next token.
{
task: "mynamespace.baz=mynamespace.foo;mynamespace.foo=undefined;",
challenge: "mynamespace[11].toString().substr(10,22)"
// get part of a well-known functions source code
}
{
task: "mynamespace.bar=function(){ /* new code here */ }",
challenge: "var xy=0;mynamespace.each(function(item){xy+=item.toString().lastIndexOf(';')}); xy"
// accumulate the last index of a semicolon in all elements
// of the namespace
}
To beat that and still get valid authorization tokens, the client would have to write an entire javascript emulation layer. Although that can be done, I would try to make the server code change in fundamental ways very often to make this technique almost impossible (so the emulation layer won't know what to emulate).
they could write a function that autoaims at the nearest enemy sprite for example.
You can do this even for games were most processing happens server-side! You just need to analyse the display quickly enough.
You can even re-implement parts of the game AI to try to predict how bots will move. Not an easy task if you don't have access to the game's source code but if you log lots of gameplay time, you could apply machine learning techniques.
Is there any fundamental way to protect people from doing this sort of thing by designing your game code in a certain way?
Don't forget that you can change the game itself, not just how it is implemented. For instance, use randomly-generated levels rather than static ones, use human players rather than bots, make your art/sprites more complex, make more use of audio, put a limit on how fast the cursor can be moved, add cooldown times to weapons, add hidden hazards, and so on.
In theory you are playing a game against hackers. You can't win this game but you make it challenging.
My suggestion would be to use as much server side logic as you can possibly use and use Javascript Obfuscation.
Javascript obfuscation will make it extremely hard to understand the code, but even better it will make it possible for you to release several thousand versions of your code while maintaining the same code base.
I have used JScrambler to do this on one occasion. Instead of having to hack the code of 1 game, hackers will have to hack several thousand versions of the code! :)
(function() {
var cantSeeMe = function() {
// do some game stuff!
};
})();
在闭包之外，很难获取“注入黑客”的代码（例如覆盖控制台上的函数） 。这不会阻止某人重写您的代码，而是通过加壳器甚至闭包编译器传递内容 会让你的代码很难阅读/修改...（看看 jQuery min
总而言之，任何运行客户端的游戏都是可破解的。
You can put everything the code ever calls inside of a closure:
(function() {
var cantSeeMe = function() {
// do some game stuff!
};
})();
Outside of the closure, it will be very difficult to get at the code for "injection hacks" (overriding a function on the console for instance). This wont stop someone from rewriting your code, but passing things through a packer, or even closure compiler can make your code pretty hard to read/modify... (take a look at jQuery min
All in all, ANY game running client side is hackable.
travian(http://www.travian.us/) is a good example of a larger scale game that runs in DHTML and it has a ton of issues with client side abuse. Just installing grease monkey in firefox opens a rather large door to all kinds of exploitative behavior. That said, they seem to keep the game somewhat functional since most of the exploits seem to revolve around automation of common in-game tasks and not direct violations of the internal domain logic of the game. Keep in mind that this example is far from being run with only JS and relies largely on server side controls.
现在，假设采取了适当的步骤来确保代码始终正确运行，那么黑客是非常狡猾的人，如果黑客有足够的决心，仍然有办法跟踪这些代码。至少一种方法是搜索关键代码结构，例如具有一定数量元素的 switch 语句，或具有 x 数量语句的 for 循环等虽然这些都可以被反击，比如通过在开关中添加虚拟 case 语句或在代码中随机添加几个 if(true) 位，但反击黑客总是会的。这是一场持续不断的（并且可能是一场失败的）战斗。
希望这能给你一些想法。我不知道有人会如何准确地实现这一点，但这至少是一个想法。
祝你好运！
Disclaimer: This is a terrible method and probably too much effort than it is worth.
Suppose that you had a method of processing the javascript code before you sent it.
First of all, every method has a ident variable which is attached to the result of every function (i.e. every function would return {ident:"special code",result:"actual useful function result"}). You also have a testIdent() function which would accept the function name to call as well as "test data" to give it (if any is needed). The purpose of testIdent() would be to send the ident returned from said function to the server for verification (the idea being that the server can request a test whenever you deem it appropriate). The ident for every function should be randomized and recorded specially for the specified user before sent.
Second, before the code is sent to the client, the function order is randomized and function names are obfuscated in some random fassion. This way there is no way for a hacker to look for some variable ident in function x() as it will be named randomly. Also, it would be another plus if every variable name is obfuscated randomly as well, just to add yet another step to the complication and headaches of... well... everyone (I told you this is a terrible method).
Now, assuming proper steps are taken to make sure the code will always function correctly, hackers are very cleaver people, and there are still ways for hackers to track this code if they are determined enough. At least one way will be to search for key code structures, such as a switch statement with a certain number of elements, or a for loop with x number of statements, etc. While each of these can be countered, say by adding dummy case statements in the switches or a couple of if(true) bits randomly throughout the code, countering hackers will always be a constant (and possibly a loosing) battle.
Hopefully this can give you some ideas. I don't know how someone would implement this exactly, but it is at least an idea.
发布评论
评论（13）
没有什么。
没有。
Nothing.
Nope.
这就是为什么大多数 JavaScript 游戏严重依赖服务器状态来防止作弊。
This is why most JavaScript games rely heavily on a server state, to prevent cheats.
简而言之，不。但是，您可以混淆 Javascript 使其变得更加困难。
对于分数之类的事情，理论上用户可以将任何分数发布到您的处理程序脚本中。在这种情况下，您可以使用会话并通过 AJAX 定期回发到服务器。
In short, no. However, you can obfuscate Javascript to make it much more difficult.
For things like scores, a user could in theory POST any score to your handler script. In this case you could use a session and regularly post back to the server through AJAX.
一些想法
服务器端：
在服务器端存储游戏内部状态并检查客户端发送的输入。
在服务器端
自动瞄准：创建普通玩家看不见的假精灵，如果它们经常被击中，那么你就有了一个机器人。 （并不总是有效，因为机器人可能会更新以检查隐形）
检查客户端对服务器上更改的反应时间，检查是否有太多太快的反应。 （在做出反应之前必须接受大量快速响应，因为人类可以快速反应，并且时间必须考虑网络延迟才能捕获任何内容）。给玩家某种验证码，普通玩家永远不会看到它。
客户端：
使用混淆使与您的代码交互变得更加困难
检查您所了解的黑客中定义的函数。必须经常修改/更新，因为此类黑客的创建者可以解决这些问题。
游戏设计：减少游戏的重复性，这使得为其编写工具/机器人变得更加困难。
游戏
更新客户端以不时更改其部分结构。虽然这不会阻止机器人，但需要付出努力才能让它们继续运行。要么使其对用户透明，要么用新功能伪装它。
重要提示：确保您的服务器接口检查用户输入，混淆和客户端检查不会帮助阻止某人编写自己的客户端。
Some thoughts
Server side:
Store the games internal state sever side and check the input send by clients on the server.
Autoaim: Create fake sprites which are invisible to normal players, if they get hit too often you have a bot. (will not always work as the bots may be updated to check for invisibility)
check client reaction time to changes on the server, check for too many too fast reactions. (has to accept a large number of fast responses before reacting as a human could react fast and the time has to account for the network delay to catch anything). Give the player some sort of captcha, a regular player would never see it.
Client side:
use obfuscation to make it harder to interface with your code
check for functions defined in the hacks you know about. Has to be modified/updated often as the creators of such hacks can work around those.
Game design: making your game less repetitive this makes it harder to write tools/bots for it.
update the client to change parts of its structure from time to time. While this will not stop bots it will take work to keep them running. Either make it transparent to the user or disguise it with a new feature.
Important: make sure your server interface checks the user input, obfuscation and client side checks wont help against someone writing their own client.
我喜欢这个问题，虽然可能有更好的答案，但我想到的一些答案可能（或可能不起作用）：
一般来说，这很难，并且所有建议以上可以解决。我想关键是让他们很难作弊，但考虑到即使是安全的在线模式游戏也有作弊者，很难防止 JS 游戏也受到影响。
I like the question, and while there are probably better answers, here are a few off the top of my head that may (or may not) work:
In general, its hard, and all of the suggestions above can be worked around. I guess the key is to make it hard for them to cheat, but given that there are cheaters for even secure online mode games, it's going to be hard to prevent JS games from being susceptible to that as well.
唯一明智的方法是将关键代码片段保留在您控制的服务器上，并且根本不将其提供给用户的计算机。困难的部分是在保持游戏速度足够快的情况下制作这个方块。
The only sane method is to keep critical pieces of the code on servers you control and never give it to the users' computers at all. The hard part is making this square with keeping the game fast enough to be playable.
你正在尝试做不可能的事情。我能给你的最好建议是，如果你打算保留任何数据，如硬币/金钱/黄金、级别等，你要确保你永远不信任客户端，并尽可能多地在服务器端提供逻辑。
You're attempting to do the impossible. The best advice I can give you is that if you are plan on persisting any data like coins/money/gold, levels, whatnot you make sure you never trust the client and make as much logic server sided as a possible.
我认为正确的方法是以动态更改客户端代码并验证在服务器上创建的代码的使用的方式编写客户端。
例如，有一个像这样的名称空间
，其中包含所有客户端代码，并使所有服务器方法都需要一个令牌，该令牌是先前对代码库进行动态评估的结果。通过重新定义方法和更改方法名称使这变得更加困难。以下是一些示例挑战（只有当挑战是动态创建且不可预测时这才有意义）。所有这些都首先包含一个任务，然后包含一个质询，该质询将用于为下一个请求创建授权令牌。 （这些是来自 ajax 调用的响应对象）。基本上，任务将被评估，评估挑战的结果将是下一个令牌。
为了克服这个问题并仍然获得有效的授权令牌，客户端必须编写整个 JavaScript 模拟层。尽管可以做到这一点，但我会尝试经常以基本方式更改服务器代码，以使这种技术几乎不可能（因此模拟层不知道要模拟什么）。
I think the way to go would be to write the client in a way such that you dynamically alter the client code and verify the use of thusly created code on the server.
E.g. have a namespace like this
which contains all your client code and make all your server methods require a token that is the result of a previous dynamic evaluation of the code base. make this harder by redefining methods and changing method names. Here are a few sample challenges (this only makes sense if challenges are created dynamically and not predictable). All contain a task first and then a challenge that will be used to create the authorization token for the next request. (These are response objects from the ajax calls). Basically the task will be eval'd and the result of the eval'd challenge will be the next token.
To beat that and still get valid authorization tokens, the client would have to write an entire javascript emulation layer. Although that can be done, I would try to make the server code change in fundamental ways very often to make this technique almost impossible (so the emulation layer won't know what to emulate).
即使对于大多数处理发生在服务器端的游戏，您也可以执行此操作！您只需要足够快地分析显示即可。
您甚至可以重新实现游戏人工智能的部分内容，以尝试预测机器人将如何移动。如果您无法访问游戏的源代码，这不是一件容易的任务，但如果您记录了大量的游戏时间，则可以应用机器学习技术。
不要忘记您可以改变游戏本身，而不仅仅是它的实现方式。例如，使用随机生成的关卡而不是静态关卡，使用人类玩家而不是机器人，使您的艺术/精灵更加复杂，更多地使用音频，限制光标移动的速度，添加冷却时间武器、添加隐藏危险等等。
You can do this even for games were most processing happens server-side! You just need to analyse the display quickly enough.
You can even re-implement parts of the game AI to try to predict how bots will move. Not an easy task if you don't have access to the game's source code but if you log lots of gameplay time, you could apply machine learning techniques.
Don't forget that you can change the game itself, not just how it is implemented. For instance, use randomly-generated levels rather than static ones, use human players rather than bots, make your art/sprites more complex, make more use of audio, put a limit on how fast the cursor can be moved, add cooldown times to weapons, add hidden hazards, and so on.
理论上，你正在玩一场对抗黑客的游戏。你无法赢得这场比赛，但你却让它变得具有挑战性。
我的建议是尽可能多地使用服务器端逻辑并使用 Javascript 混淆。
Javascript 混淆将使代码变得极其难以理解，但更好的是，它使您可以在维护相同的代码库的同时发布数千个代码版本。
我曾使用 JScrambler 来执行此操作一次。黑客不必破解 1 个游戏的代码，而是必须破解数千个版本的代码！ :)
In theory you are playing a game against hackers. You can't win this game but you make it challenging.
My suggestion would be to use as much server side logic as you can possibly use and use Javascript Obfuscation.
Javascript obfuscation will make it extremely hard to understand the code, but even better it will make it possible for you to release several thousand versions of your code while maintaining the same code base.
I have used JScrambler to do this on one occasion. Instead of having to hack the code of 1 game, hackers will have to hack several thousand versions of the code! :)
您可以将代码调用的所有内容放在闭包内：
在闭包之外，很难获取“注入黑客”的代码（例如覆盖控制台上的函数） 。这不会阻止某人重写您的代码，而是通过加壳器甚至闭包编译器传递内容 会让你的代码很难阅读/修改...（看看 jQuery min
总而言之，任何运行客户端的游戏都是可破解的。
You can put everything the code ever calls inside of a closure:
Outside of the closure, it will be very difficult to get at the code for "injection hacks" (overriding a function on the console for instance). This wont stop someone from rewriting your code, but passing things through a packer, or even closure compiler can make your code pretty hard to read/modify... (take a look at jQuery min
All in all, ANY game running client side is hackable.
travian(http://www.travian.us/) 是大型游戏的一个很好的例子，在 DHTML 中运行，并且存在大量客户端滥用问题。只要在 Firefox 中安装油脂猴，就为各种剥削行为打开了一扇相当大的大门。也就是说，它们似乎使游戏保持了一定的功能，因为大多数漏洞似乎都围绕常见游戏内任务的自动化，而不是直接违反游戏的内部域逻辑。
请记住，这个示例远非仅使用 JS 运行，而是很大程度上依赖于服务器端控制。
travian(http://www.travian.us/) is a good example of a larger scale game that runs in DHTML and it has a ton of issues with client side abuse. Just installing grease monkey in firefox opens a rather large door to all kinds of exploitative behavior. That said, they seem to keep the game somewhat functional since most of the exploits seem to revolve around automation of common in-game tasks and not direct violations of the internal domain logic of the game.
Keep in mind that this example is far from being run with only JS and relies largely on server side controls.
免责声明：这是一种糟糕的方法，而且可能付出了太多的努力。
假设您有一种在发送 JavaScript 代码之前处理该代码的方法。
首先，每个方法都有一个ident变量，它附加到每个函数的结果（即每个函数都会返回
{ident：“特殊代码”，结果：“实际有用的函数结果” “}）。您还有一个 testIdent() 函数，它将接受要调用的函数名称以及为其提供的“测试数据”（如果需要的话）。testIdent()的目的是将所述函数返回的ident发送到服务器进行验证（其想法是服务器可以在您认为任何时候请求测试）合适的）。每个函数的ident在发送之前应该被随机化并专门为指定用户记录。其次，在将代码发送到客户端之前，函数顺序是随机的，并且函数名称以某种随机方式进行混淆。这样，黑客就无法在函数 x() 中查找某些变量 ident，因为它将被随机命名。另外，如果每个变量名也被随机混淆，这将是另一个优点，只是为了让……好吧……每个人的复杂性和头痛又增加一步（我告诉过你这是一个糟糕的方法）。
现在，假设采取了适当的步骤来确保代码始终正确运行，那么黑客是非常狡猾的人，如果黑客有足够的决心，仍然有办法跟踪这些代码。至少一种方法是搜索关键代码结构，例如具有一定数量元素的
switch语句，或具有 x 数量语句的 for 循环等虽然这些都可以被反击，比如通过在开关中添加虚拟case语句或在代码中随机添加几个if(true)位，但反击黑客总是会的。这是一场持续不断的（并且可能是一场失败的）战斗。希望这能给你一些想法。我不知道有人会如何准确地实现这一点，但这至少是一个想法。
祝你好运！
Disclaimer: This is a terrible method and probably too much effort than it is worth.
Suppose that you had a method of processing the javascript code before you sent it.
First of all, every method has a ident variable which is attached to the result of every function (i.e. every function would return
{ident:"special code",result:"actual useful function result"}). You also have atestIdent()function which would accept the function name to call as well as "test data" to give it (if any is needed). The purpose oftestIdent()would be to send the ident returned from said function to the server for verification (the idea being that the server can request a test whenever you deem it appropriate). The ident for every function should be randomized and recorded specially for the specified user before sent.Second, before the code is sent to the client, the function order is randomized and function names are obfuscated in some random fassion. This way there is no way for a hacker to look for some variable ident in function x() as it will be named randomly. Also, it would be another plus if every variable name is obfuscated randomly as well, just to add yet another step to the complication and headaches of... well... everyone (I told you this is a terrible method).
Now, assuming proper steps are taken to make sure the code will always function correctly, hackers are very cleaver people, and there are still ways for hackers to track this code if they are determined enough. At least one way will be to search for key code structures, such as a
switchstatement with a certain number of elements, or a for loop with x number of statements, etc. While each of these can be countered, say by adding dummycasestatements in the switches or a couple ofif(true)bits randomly throughout the code, countering hackers will always be a constant (and possibly a loosing) battle.Hopefully this can give you some ideas. I don't know how someone would implement this exactly, but it is at least an idea.
Good luck!