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.

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

使用已知(私有)可逆密钥进行加密是最简单的方法。我不完全使用AS，所以我不确定有哪些类型的加密提供商。

但你也可以加入游戏长度(同样是加密的)和点击次数等变量。

所有这类事情都可以逆向工程，所以可以考虑扔进一堆垃圾数据来迷惑人们。

编辑:可能也值得加入一些PHP会话。当玩家点击“开始游戏”时便开始游戏，并记录时间。当他们提交分数时，你可以检查他们是否有一个开放的游戏，他们没有过早或过大地提交分数。

也许有必要计算出一个标量，比如每秒钟/分钟游戏的最大分数。

这两件事都不是不可避免的，但这将有助于在Flash之外的地方设置一些逻辑，让人们可以看到它。

It is only possible by keeping the all game logic at server-side which also stores the score internally without knowledge of the user. For economical and scientific reasons, mankind can not apply this theory to all game types excluding turn-based. For e.g. keeping physics at server-side is computationally expensive and hard to get responsive as speed of hand. Even possible, while playing chess anyone can match AI chess gameplay to opponent. Therefore, better multiplayer games should also contain on-demand creativity.

Whenever your highscore system is based on the fact that the Flash application sends unencrpyted/unsigned highscore data via the network, that can be intercepted and manipulated/replayed. The answer follows from that: encrypt (decently!) or cryptographically sign highscore data. This, at least, makes it harder for people to crack your highscore system because they'll need to extract the secret key from your SWF file. Many people will probably give up right there. On the other hand, all it takes is a singly person to extract the key and post it somewhere.

真正的解决方案包括在Flash应用程序和高分数据库之间进行更多的通信，以便后者能够验证给定的分数是否真实。这可能很复杂，这取决于你的游戏类型。

一种简单的方法是提供高分值的加密散列及其本身的分数。例如，当通过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与服务器通信，并确保客户端预先配置为只信任由您单独有权访问的特定证书颁发机构签署的证书来避免这种来回。

根据我的经验，这最好是一个社会工程问题，而不是一个编程问题。与其专注于让作弊变得不可能，不如专注于通过消除作弊动机来让它变得无聊。例如，如果主要动机是公开可见的高分，那么简单地延迟高分的显示时间就可以通过消除作弊者的正反馈循环来显著减少作弊。