。尽管在其它公开场合未必能看到被破解的SWF文件，但是离线也能够播放的SWF就可能发生上述情况。
2. 服务端口令验证
编写脚本，并且在开始游戏时从服务端加载密码。如果密码为空，则停止游戏或者退出游戏。这很容易被怀有恶意的用户破解，他们只要编辑SWF文件，将那些脚本删除即可。哪些脚本不可以被删除呢？当开始游戏时，从服务端加载的地图数据是进行游戏必须的，所以心存不良的用户不可能删除这些脚本。为了进行游戏，它必须提供这些地图数据。当然，它可以从缓存在临时文件夹中的数据中挑选地图数据，提供给SWF，从而激活游戏。
3.将SWF或者变量置于服务端
这是第二种技术的扩展、延伸，该技术已经广泛的使用着。起初的游戏（SWF）文件只是个装载器，当单击播放（或开始）按钮后，将加载另一个SWF文件。当需要地图文件的时候，便从服务端加载地图数据。当加载数据遇到阻碍时，将从服务段再次加载受到阻碍的SWF文件。新层上的数据也是从服务端传过来。
从这儿。我们可以看到一个原则：防止反编译的最好方法是“不给”。
如果一些愚蠢的窃贼只下载game.SWF文件，他不可能玩这个游戏。 他需要在缓存中挑选出所有的SWF文件和变量。打开所有的SWF文件，编辑这些变量的名字，使它与缓存中的变量的名字一致。
如果我们的地图由CGI随机产生，那么窃贼只可能拥有一份地图，他没有随机产生地图的权力。如果是个迷宫游戏的话，充其量，他只能玩一个迷宫，他没有“动态产生迷宫”的功能。如果心存不良的用户玩这个游戏将碰到一个新的阻碍，因为在他的缓存中没有这个新的受到阻碍的SWF文件，所以将无法进行游戏。
因此，许多算法和功能都放在服务端，那个SWF文件只是个界面而已。这是个完美的保护措施，但是缺陷是这件产生一个转为游戏工作的CGI，而不是Flash。我们正在讨论关于SWF的保护问题，这个解决方案是不妥当的，因为SWF文件自身得不到保护。
（完）
