这篇文章的标题所提出的问题的答案是“不可能”。至少对我来说是不可能的。借助适当的工具，我们可以反编译任何SWF文件。所以，不要将重要的信息置于SWF文件中。SWF文件中不要包含个人的帐号或者密码。

我将简要的论述“保护”技术的历史，和他们是如何失败的，接着我将说明我们能尽的最大努力。中国古语有云，“规则只能防君子，不能仿小人”。

公开的文件格式

在讨论之前，我们先要知道，SWF的文件格式是公开的。公开的文件格式，意味着SWF文件并不是只能由Flash生成。其他公司也能制作可以在SWF播放器上播放的SWF文件。公开的文件格式意味着从什么位置获取什么信息是众所周知的，也就意味着每个字节都是众所周知的。因此，如果我有时间来一个字节一个字节的检查SWF文件，我可以了解所有的细节。

当然，对于一个2M大小的SWF文件，我没有时间来逐个字节的检查。因此，我就借助软件来完成这个工作。如果软件遇到问题，我会暂时接管这个工作，检查发生问题的字节。修正它，然后继续。所以，没有什么东西能够掩藏的住，其限制只是我的时间和我的耐性。如果反编译一个SWF文件的酬劳是数百美元的话，我想我会花上数年时间来逐个字节的读取它。

好了，以下是反编译和保护技术之间的战争历史。

防止被导入

伴随着Flash的出现，Macromedia提供给开发者一个“防止导入的口令保护”功能。如果你给SWF文件加上导入口令的话，这个SWF文件就不能被导入了（知道倒入密码除外）。SWF文件不加保护的话，其中的矢量图形可以被导入到fla文件中。这种保护没有什么用处，仅仅是假想的安全。

试想一下，你的SWF被用户的播放器来播放的，你不可能利用用户的播放器来保护你的SWF文件。因此，它是如何来保护SWF文件的呢？很简单，这种保护存在于你所买的Flash开发工具中。Flash开发工具不能导入有（导入）密码的SWF文件。没关系，对吧？我可以用十六进制编辑打开那个SWF文件，删除保护密码，从而也就移除了保护功能。

如此简单，所以忘记导入保护功能吧。

转换成放映机文件并且压缩

如果我将它转化成exe格式的放映机文件，还可以被反编译吗？答案：是的，SWF文件仍然存在其中。借助软件可以很容易的将SWF文件从exe文件中释放出来。压缩可以使SWF文件不能被十六进制编辑器读取，压缩是一种保护措施吗？压缩算法类似于zip算法，很容易被破解。

FLASM AND THE P-CODE

在flash5的时代，出现了两种流行的工具，免费的“Flasm”和商业的“ASV 2.0”。Flasm就是“Flash asm”，它将SWF中的字节码解释成可理解的简短代码（p-codes）。比如“a=3”显示为"push ''a'', 3", "setVariable";SWF中的字节码是："96 08 00 00 61 00 07 03 00 00 00 1D"。如果想学习“SWF格式结构”的话，这是个非常有价值的工具。

程序员喜欢用高级语言（比如：C、C++）来开发软件，但是当讲求效率的时候，他们会在其中混合使用低级的汇编语言。因此，有时候开发者会利用Flasm编写低级别的p-codes来增加效率。所以，Flasm编辑SWF中的acti;
    b="Fun";
    this[a+b]();

另一个技术是使函数的名字不可显示。比如，用汉字作为函数名，反编译器可能就会不能很好的显示它。然后，我们便会看到：

function ?(){?,?){?.?=?;}

ASV 4使用unicode编码显示不可显示字符，所以，结果是易读的，只不过增加了点轻微的难度。

自我保护

如果你找到一个很好的方法来保护自己的SWF不备反编译，不要与别人分享这个方法，至少不要再因特网上公开它。当然，它不能过100%的防反编译，至少对我来说是这样。但是，不是所有的人都对SWF的格式了如指掌。许多，偷窃者仅仅只会借助软件来反编译SWF。因此，如果你的目的是尽可能少的偷窃者能够偷窃你的SWF，那么请保护好你的（白虎SWF的）秘密方法。

只是在此提醒你，你的SWF是无保护的。对于熟悉SWF格式的人来说，所有东西都是毫无遮掩的。如果你的目标只是保护“一些函数”的话，它应该是安全的。他们未必会窃取你的函数，他们会编写自己的函数。

通用保护措施

我们在网站上放了个联机游戏，不幸的是，许多访问者只是访问我们的站点仅仅一次而已，然后利用下载的版本来离线玩。有时，我们甚至发现我们的游戏出现在其他的站点上。

为了避免这种情况发生，下面是可采取的保护措施：

1. 所属领域检查

编写脚本检查_url，如果_url是"http://myDomain/game.SWF"就播放影片，否则不播放或者退出。当离线播放的时候，_url应该像"file://C| someSub/game.SWF"；但它在其它domain中时，_url就形如"http://others/game.SWF"。因此，这个技术可以恰当的加上一些保护。当然，对于心存不良的反编译者来说是无用的。那些脚本可以借助Flasm来删除或者修改为不检查。尽管在其它公开场合未必能看到被破解的SWF文件，但是离线也能够播放的SWF就可能发生上述情况。

2. 服务端口令验证

编写脚本，并且在开始游戏时从服务端加载密码。如果密码为空，则停止游戏或者退出游戏。这很容易被怀有恶意的用户破解，他们只要编辑SWF文件，将那些脚本删除即可。哪些脚本不可以被删除呢？当开始游戏时，从服务端加载的地图数据是进行游戏必须的，所以心存不良的用户不可能删除这些脚本。为了进行游戏，它必须提供这些地图数据。当然，它可以从缓存在临时文件夹中的数据中挑选地图数据，提供给SWF，从而激活游戏。

3.将SWF或者变量置于服务端

这是第二种技术的扩展、延伸，该技术已经广泛的使用着。起初的游戏（SWF）文件只是个装载器，当单击播放（或开始）按钮后，将加载另一个SWF文件。当需要地图文件的时候，便从服务端加载地图数据。当加载数据遇到阻碍时，将从服务段再次加载受到阻碍的SWF文件。新层上的数据也是从服务端传过来。

从这儿。我们可以看到一个原则：防止反编译的最好方法是“不给”。

如果一些愚蠢的窃贼只下载game.SWF文件，他不可能玩这个游戏。 他需要在缓存中挑选出所有的SWF文件和变量。打开所有的SWF文件，编辑这些变量的名字，使它与缓存中的变量的名字一致。

如果我们的地图由CGI随机产生，那么窃贼只可能拥有一份地图，他没有随机产生地图的权力。如果是个迷宫游戏的话，充其量，他只能玩一个迷宫，他没有“动态产生迷宫”的功能。如果心存不良的用户玩这个游戏将碰到一个新的阻碍，因为在他的缓存中没有这个新的受到阻碍的SWF文件，所以将无法进行游戏。

因此，许多算法和功能都放在服务端，那个SWF文件只是个界面而已。这是个完美的保护措施，但是缺陷是这件产生一个转为游戏工作的CGI，而不是Flash。我们正在讨论关于SWF的保护问题，这个解决方案是不妥当的，因为SWF文件自身得不到保护。

无忧站长学院，建站自然无忧www.5ucms.org