这是互联网游戏和竞赛的经典问题。您的Flash代码可与用户一起确定游戏得分。但是用户不受信任，并且Flash代码在用户的计算机上运行。你是SOL。您无法采取任何措施来阻止攻击者伪造高分：
Flash甚至比您想象的要容易进行逆向工程，因为字节码已被很好地记录并描述了高级语言（动作脚本）—发布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-hardpred-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匹配（如果跳过此步骤）
，解密只会产生随机的，可能很高的分数）。
因此，现在，攻击者反编译您的Flash代码，并迅速找到AES代码，该代码像拇指酸痛地伸出来，尽管即使没有找到，也可以在15分钟内通过内存搜索和跟踪器对其进行跟踪（“我知道我在这款游戏中的得分是666，所以让我们在内存中找到666，然后进行任何触及该值的操作-哦，高分加密代码！”）。有了会话密钥，攻击者甚至不必运行Flash代码。她获取了游戏启动令牌和会话密钥，并可以发回任意高分。
现在，大多数开发人员都放弃了—通过以下方式放弃或破坏攻击者几个月：
使用XOR操作加扰AES密钥
用计算密钥的函数替换密钥字节数组
在整个二进制文件中散布伪造的密钥加密和高分发布。
这大部分都是在浪费时间。不用说，SSL也不会帮助您。当两个SSL端点之一为恶意时，SSL无法保护您。
以下是一些可以真正减少高分欺诈的事情：
需要登录才能玩游戏，让登录产生会话cookie，并且不允许在同一会话上进行多个未完成的游戏启动，或者不允许同一用户进行多个并发会话。
拒绝持续时间少于有史以来最短的真实游戏的游戏会话的高分（对于更复杂的方法，对于持续时间少于平均游戏时间2个标准偏差的游戏会话，尝试“隔离”高分）。确保您正在服务器端跟踪游戏时间。
从仅玩过一次或两次游戏的登录中拒绝或隔离高分，因此攻击者必须为创建的每个登录产生合理外观的“纸迹”。
在游戏过程中，“ Heartbeat”得分很高，因此您的服务器可以看到在一个游戏过程中得分的增长。拒绝不遵循合理分数曲线的高分（例如，从0跳到999999）。
游戏过程中的“快照”游戏状态（例如，弹药量，关卡中的位置等），您以后可以将其与记录的临时分数进行核对。您甚至不必以某种方式来检测此数据中的异常。您只需要收集它，然后可以回头再分析一下是否看起来很腥。
禁用所有未通过安全检查之一的用户的帐户（例如，通过提交未通过验证的加密高分）。
请记住，虽然您只是在阻止高分欺诈。有 没有什么 可以做，以防止误。如果您的游戏中有钱，那有人会打败您想出的任何系统。目的不是 阻止
这种攻击；这是使攻击更加昂贵，而不仅仅是真正擅长于游戏并击败它。
