您不能相信客户端返回的任何数据。验证需要在服务器端执行。我不是游戏开发者，但我确实制作商业软件。在这两种情况下，都可能涉及金钱，而且人们会破坏客户端混淆技术。

可能会定期将数据发送回服务器并进行一些验证。不要把注意力集中在客户端代码上，即使您的应用程序就在客户端代码上。

The way that a new popular arcade mod does it is that it sends data from the flash to php, back to flash (or reloads it), then back to php. This allows you to do anything you want to compare the data as well bypass post data/decryption hacks and the like. One way that it does this is by assigning 2 randomized values from php into the flash (which you cannot grab or see even if running a realtime flash data grabber), using a mathematical formula to add the score with the random values then checking it using the same formula to reverse it to see if the score matches it when it finally goes to the php at the end. These random values are never visible as well as it also times the transaction taking place and if it's any more than a couple seconds then it also flags it as cheating because it assumes you have stopped the send to try to figure out the randomized values or run the numbers through some type of cipher to return possible random values to compare with the score value.

如果你问我，这似乎是一个很好的解决方案，有人认为使用这种方法有什么问题吗?或者可能的解决方法?

这是网络游戏和竞赛的一个经典问题。你的Flash代码与用户一起决定游戏的得分。但是用户不受信任，Flash代码运行在用户的计算机上。你是SOL，你无法阻止攻击者伪造高分:

Flash甚至比你想象的更容易进行反向工程，因为字节码有良好的文档记录，并描述了一种高级语言(Actionscript)——当你发布一款Flash游戏时，你就是在发布你的源代码，不管你是否知道。 攻击者控制Flash解释器的运行时内存，因此任何知道如何使用可编程调试器的人都可以在任何时候改变任何变量(包括当前分数)，或者改变程序本身。

对系统最简单的攻击是通过代理运行游戏的HTTP流量，捕获高分保存，然后以更高的分数重放。

你可以尝试通过将每个高分保存绑定到游戏的单个实例来阻止这种攻击，例如在游戏启动时向客户端发送加密令牌，如下所示:

hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))

(您也可以使用会话cookie来达到同样的效果)。

游戏代码将这个令牌用高分保存回服务器。但攻击者仍然可以再次启动游戏，获得令牌，然后立即将该令牌粘贴到重放的高分保存文件中。

因此，接下来不仅要提供一个令牌或会话cookie，还要提供一个高分加密会话密钥。这将是一个128位AES密钥，它本身是用硬编码到Flash游戏中的密钥加密的:

hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))

现在，在游戏发布高分之前，它会解密高分加密会话密钥，这是因为你将高分加密会话密钥硬编码到Flash二进制文件中。你用这个解密的密钥加密高分，以及高分的SHA1哈希值:

hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))

服务器上的PHP代码检查令牌，以确保请求来自一个有效的游戏实例，然后解密加密的高分，检查以确保高分与高分的SHA1匹配(如果跳过这一步，解密只会产生随机的，可能非常高的高分)。

So now the attacker decompiles your Flash code and quickly finds the AES code, which sticks out like a sore thumb, although even if it didn't it'd be tracked down in 15 minutes with a memory search and a tracer ("I know my score for this game is 666, so let's find 666 in memory, then catch any operation that touches that value --- oh look, the high score encryption code!"). With the session key, the attacker doesn't even have to run the Flash code; she grabs a game launch token and a session key and can send back an arbitrary high score.

你现在已经到了大多数开发者放弃的时候了——在与攻击者纠缠了几个月之后:

用异或操作打乱AES键 用计算键的函数替换键字节数组 在二进制文件中散布假密钥加密和高分帖子。

这基本上是在浪费时间。不用说，SSL也帮不了你;当两个SSL端点中的一个是邪恶的时，SSL无法保护您。

以下是一些能够有效减少高分作弊的方法:

Require a login to play the game, have the login produce a session cookie, and don't allow multiple outstanding game launches on the same session, or multiple concurrent sessions for the same user. Reject high scores from game sessions that last less than the shortest real games ever played (for a more sophisticated approach, try "quarantining" high scores for game sessions that last less than 2 standard deviations below the mean game duration). Make sure you're tracking game durations serverside. Reject or quarantine high scores from logins that have only played the game once or twice, so that attackers have to produce a "paper trail" of reasonable looking game play for each login they create. "Heartbeat" scores during game play, so that your server sees the score growth over the lifetime of one game play. Reject high scores that don't follow reasonable score curves (for instance, jumping from 0 to 999999). "Snapshot" game state during game play (for instance, amount of ammunition, position in the level, etc), which you can later reconcile against recorded interim scores. You don't even have to have a way to detect anomalies in this data to start with; you just have to collect it, and then you can go back and analyze it if things look fishy. Disable the account of any user who fails one of your security checks (for instance, by ever submitting an encrypted high score that fails validation).

记住，你只是在阻止高分欺诈。你无法阻止它的发生。如果你的游戏中存在金钱风险，那么总有人会打败你所想出的任何系统。我们的目标不是阻止这次袭击;这是为了让攻击变得更加昂贵，而不仅仅是精通游戏并击败它。

一种简单的方法是提供高分值的加密散列及其本身的分数。例如，当通过HTTP GET发布结果时: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

当计算这个校验和时，应该使用一个共享秘密;这个秘密永远不应该通过网络传输，而应该在PHP后端和flash前端中硬编码。上面的校验和是通过将字符串“secret”前置到分数“500”前，并通过md5sum运行来创建的。

Although this system will prevent a user from posting arbitrary scores, it does not prevent a "replay attack", where a user reposts a previously calculated score and hash combination. In the example above, a score of 500 would always produce the same hash string. Some of this risk can be mitigated by incorporating more information (such as a username, timestamp, or IP address) in the string which is to be hashed. Although this will not prevent the replay of data, it will insure that a set of data is only valid for a single user at a single time.

为了防止任何重放攻击的发生，必须创建某种类型的挑战-响应系统，例如:

The flash game ("the client") performs an HTTP GET of http://example.com/highscores.php with no parameters. This page returns two values: a randomly generated salt value, and a cryptographic hash of that salt value combined with the shared secret. This salt value should be stored in a local database of pending queries, and should have a timestamp associated with it so that it can "expire" after perhaps one minute. The flash game combines the salt value with the shared secret and calculates a hash to verify that this matches the one provided by the server. This step is necessary to prevent tampering with salt values by users, as it verifies that the salt value was actually generated by the server. The flash game combines the salt value with the shared secret, high score value, and any other relevant information (nickname, ip, timestamp), and calculates a hash. It then sends this information back to the PHP backend via HTTP GET or POST, along with the salt value, high score, and other information. The server combines the information received in the same way as on the client, and calculates a hash to verify that this matches the one provided by the client. It then also verifies that the salt value is still valid as listed in the pending query list. If both these conditions are true, it writes the high score to the high score table and returns a signed "success" message to the client. It also removes the salt value from the pending query list.

请记住，如果用户可以访问共享秘密，则上述任何技术的安全性都会受到损害

作为一种替代方法，可以通过强制客户端通过HTTPS与服务器通信，并确保客户端预先配置为只信任由您单独有权访问的特定证书颁发机构签署的证书来避免这种来回。

没有办法使它完全不可攻击，因为它很容易反编译swf，一个熟练的开发黑客可以跟踪您的代码，并找出如何绕过您可能使用的任何加密系统。

如果你只是想通过使用TamperData这样的简单工具来阻止孩子作弊，那么你可以生成一个加密密钥，在启动时传递给SWF。然后，在将高分传递回PHP代码之前，使用http://code.google.com/p/as3crypto/之类的东西对高分进行加密。然后在服务器端解密，然后将其存储到数据库中。

通过AMFPHP与后端通信可能是个好主意。它至少应该阻止那些试图通过浏览器控制台推送结果的懒人。