如何防止SWF文件被反编译 如何防止SWF文件被反编译(1)

这篇文章的标题所提出的问题的答案是“不可能”。至少对我来说是不可能的。借助适当的工具，我们可以反编译任何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中的actionscript是强有力的。你可以参考例子，了解如何利用这种技术来优化3D代码，但是怀有恶意的用户能够“编辑”SWF文 件，SWF中的任何保护措施都可以不费力的移除。我们不需要知道密码就可以移除保护措施。

这儿有个通用、知名的技术来保护我们的影片不被 偷窃并在其它的范围内显示。我们编辑脚本来检查_url属性，如果_url不是我们（合法）的范围，就使功能失效并显示一条“You are thief”的消息。可是，借助Flasm可以很容易删除这条脚本语句。不需要1分钟便可以破解这种保护措施。

ACTIONSCRIPT VIEWER AND "void (a)<=b>"c" || 0(!1 && !0)"

ASV（ActionScript Viewer）能够从SWF中提取出角色，例如:：声音、形状和位图等都可以被窃取。

它 同样可以提取actionscript字节码，ASV 2尝试将p-codes匹配成高级别的actionscript。当遇到"push ''a'', 3", "setVariable";时显示"a=3"这样的等同于actionscript的语言。然而我们能够创造没有任何模式来匹配的代码，从而破坏ASV 的解析。利用Flasm，可以容易的编写不同于标准模式的代码，从而使ASV不能进行匹配工作。扰乱ASV 2工作的一句有名的代码是“；”，这是一条jung代码。它不做任何事，但是能搞乱ASV 2的工作。

但是，当保护脚本众所周知时，ASV的作者（Burakk）当然不会放过它。这种保护技术对于ASV 3来说就失效了。

飞速发展的反编译工具

之后是MX时代的到来，许多反编译工具的出现，加快了Flash厄运的速度。

现 行版本的ASV 4除了显示得到匹配的actionscript代码，得不到匹配的代码以p-codes形式显示。如果解释成p-codes发生问题，将显示SWF中的字 节码。它同样能够显示代码在SWF文件中所处的偏移量，这意味着它不会失效。你不可能扰乱它的工作，因为，至少它能显示SWF文件中的“字节码”。

更甚的是，Flash MX2004提供通过JavaScript API来生成”fla”文件。那使它能够建立发布成SWF格式的fla文件。此刻，所有的东西都在那边了。

更不用说声音、形状和位图了，偷窃者不喜欢这些东西，因为它们套容易取得了。偷窃者喜欢切的actionscript，因为其中隐藏着密码，因为其中有阻止此影片正常播放的脚本代码，

如果ASV只能将脚本反编译成字节码，那么它对于大多数偷窃者是没有用处的。因此很多人进他们的最大努力来阻止ASV 4将脚本反编译成actionscript或者p-codes。实际上，对于大多数反编译者来说，脚本得不到匹配，反编译工具就无用了。

这是曾经用过的一些技术，当它们在因特网上发布并且被反编译组织揭示之后，每种技术的保护效果最终都会变得非常薄弱和气数将尽。

依据数据尺寸（句子）分块反编译

大多数之所以能够成功的迷惑或者破坏反编译器，原因在于播放器和反编译器的不同行为。播放器逐个的执行字节码，就像现实世界中的读书一样，一个单词，接着下一个单词。然而反编译器通常将字节链分成有意义的片断，犹如现实世界中的读书一样，一个句子，接着下一个句子。

反 编译器的行为如此简单的原因在于大多数的p-code都是遵循数据大小规律的。对于字节码("96 08 00 00 61 00 07 03 00 00 00 1D")，反编译器遇到代表"push"操作的0x96时会想“push什么呢”?下个字节(0x0008)指示的内容：接下去8个字节中的内容压入堆 栈，即把("00 61 00 07 03 00 00 00")压入堆栈。所以，通常反编译器依据数据大小将简短的片断切成一块一块的，这样便会解释成“push something”。因此，("96 08 00 00 61 00 07 03 00 00 00")就成为一个句子。下一个字节是下一个句子的开始，就是代表"setVariable"的0x1D。这样8个字节的"something"，将被更 进一步解释成一个字符串“a”和一个数字“3”。

让我们来看一下字节码：("99 02 00 05 00 96")。0x99意味着分支（或者跳转），在哪里分支呢？接下去的是(0002)，因此数据存储在机下去的两个字节中，将它在下面两个字节处截断。总 之，我们知道"99 02 00 05 00"是个句子。接下去的是0x96，代表下个句子的开始。

再看第三个例子，字节码：("88 08 00 03 00 63 00 62 00 61 00 96 07 00")。0x88代表定义常数，定义的常数内容是什么呢？后续字节(0008)，表明常数内容存储在后继的8个字节中。所以，句子就是：("88 08 00 03 00 63 00 62 00 61 00")。代表下个句子开始的("96 07 00 ...)，意味着将7个字节的数据压入堆栈。

因此，字节码砍成单独的句子。每个句子由命令和数据组成，并且以命令打头。因此，每个句子都是一个基本的单元。理论上来说，对于这种方法没有什么错误。

使播放器从句子中间开始读数据

让我们开始讨论“是播放器从句子中间读数据”的破坏反编译器的技术。

首先，我举一个现实世界的例子：

John says good morning.
Mary says thank you. 现在生成SWF文件：

skip 9 words
Tom says John says good morning.
skip 3 words
back 7 wordsMary says thank you. 如果逐个字读的话，结果和原来一样，然而反编译器按句子来读取，自然发生错误。第一，它知道Tom说了什么，但语法不对，汇报出错；第二，它没有看到第二 个“skip”命令，因为它处于句子中间；第三，当它被迫退回7个字后，感到迷惑，认为应该从“Tom said”开始执行整个句子；第四，这个错误使它在第二行和第三行之间陷入无限循环之中。

总之，我们增加了“Tom said”这句垃圾代码，并提供整个句子长度的错误数据大小信息。这个错误的长度覆盖了“skip”命令。

来看个真实的例子，请注意，这些技术需要操作字节码，纯actionscript不能够实现。

例1 ：

向前跳转的包含无效尺寸数据的死代码。

push True
branchifTrue label2
constants ''''label2:push ''a'',3setVariable 你仔细看的话，会发现"constants ''''"这行是垃圾代码，它不可能被执行到。然而，理论上，当第二行的结果为"not True"时，它将被执行。因此，反编译器尝试对它进行反编译。

让我们来增大"0x88 - constants"后面的"sentence size"，从而包括知道脚本结尾的所有字节。你知道，反编译器将把字节码砍成像这样的3个句子：

push True
branchifTrue label2
constants label2: push ''a'',3 setVariable 如 果你试图反编译此SWF文件，根据我前面提到的4个错误，一些反编译器将碰壁。仍旧有些反编译器幸存，但只是显示："if(false){};"。ASV 3也不能显示此脚本，但是ASV 4能够显示。为了破解这个SWF，我们移除死代码"constant xxxx", (0x88和随后两个字节)，然后所有的东西都得到反编译。

这儿 是zip格式的文件，将详细解释怎样制作这样的受保护文件。

例2：

先后跳转的包含无效尺寸数据的死代码。



push ''b''
label1:
push ''a'',3
setVariable
branch label2
branch label1



label2:push ''b''是句垃圾代码，我们将修改它，用来使ASV 4碰壁。让我们来修改push ''b''的"length of sentence"。修改"0x96"后面的2个字节的数据，使句子的长度增长到分支Label1之前。这样，反编译器将把字节码作为3个句子：



push label1: push ''a'',3 setVariable branch label2
branch label1
label2:



现 在，反编译器不知道将把什么压入堆栈，同样它将在第一个句子和第二个句子之间形成死循环。这种技术将使大部分反编译器碰壁。Flasm、ASV 4同样也无效。为了破解这个SWF，我们手工删除"push b" (0x96和后随的2个字节)，这样所有的东西都可反编译了。

当这个技术流传后，burakk将修改ASV 4，使它能正确处理死循环。这样下个版本的ASV就可对付这种技术了。

这儿 是zip格式的文件，将详细解释怎样制作这样的受保护文件