如何保护swf文件不被反编译软件破解？

How to protect SWFs from decompilers?
如何保护swf文件不被反编译软件破解？
[ April 24, 2004 ] by Eric Lin
原作：EricLin
翻译：aw （www.awflasher.com，转载中文部分请注明出处，谢谢）
后面有点虎头蛇尾的感觉，但是大致意思出来了，如果有错误，忘指正。

A deep explanation of the techniques used to protect and crack SWF files.
一个有关“保护SWF文件与破解SWF文件技术”的比较详细的解释

——————————————————————————–

The answer to the question in the title of this article is: "no way". At least no way to me. By proper tools, I can decompile any SWF.
其实，对于如何保护swf不被破解，答案是并不存在的。至少我无法做到！我可以用一些相应的工具破解任何SWF文件
So, do not incorporate important information in the SWF. Do not include your personal account or password in the SWF.
所以，不要在swf文件中放置任何重要的信息，不要把你的个人账户或密码放在swf中。
I will briefly discuss the history of "protection" technique and how they failed. Then I would discuss how at best we can do. In Chinese old says: "A way able to protect from gentleman but not from professional theft".
我将会简单地论述“保护（不被破解）”技术以及它们是如何失效的。然后我会介绍如何将“尽最大努力”来保护swf文件。中国有一句老话：“防得住君子，防不过小人”？？

OPEN-FILE-FORMAT
开放文件格式
Before any discussion, we must know that, SWF is open format. Open-format means SWF files are not exclusively produced by Flash. Other companies can create SWF that can be played on SWF player. Open-format means what informations get stored in what position are known for public. The meaning of each byte is known for public. So, if I have time to check the SWF byte by byte, I know everything.
在开始探讨这个问题之前，我们要知道，swf文件是开放格式的。这意味着swf文件并不是Flash软件所特定生成的，其他的公司（软件）同样可以创建 swf文件并且能够在任何swf播放器上播放（aw附：比如SwishMax，Swift3d等等）开放格式意味着（swf文件的）什么地方存放什么内容 是公布于众的。（swf文件的）每一个字节（8个bit，比如01001110）也是公布于众的。所以，如果我有时间来逐个字节地分析一个swf文件，我 将会知道一切。

Of course, I won't have the time to check an SWF of 2 mb in size byte by byte. So, there are softwares to help me achieve the jobs. If that software meets trouble, OK, I will take over the job temporarily and check the bytes where troubles occurr. Fix it, and then continue. Nothing can hide. The limitation is my time and my patience.
If the reward of decompiling an SWF is millions of dollars, I surely would like to take years to read it byte by byte.
然而，我当然没有时间去逐字节地分析一个2mb的swf文件。所以，这样就出现了一系列（破解）软件来帮助我完成这样一个工作。如果这个软件遇到麻烦了 （可理解为被设计者人为设置），那么我就要人为地介入这个人物并查出问题所在，找出是哪个（些）字节除了问题。然后恢复它们，并且让工作继续。没有内容可 以被掩盖，唯一的限制是牺牲了我的时间以及耐心。

OK, here is the history of the war between decompiler and protection.
好，下面介绍一下“破解”与“反破解（保护）”的“战争”！

PROTECT FROM IMPORT
＝＝（aw注释:这是官方的一种防“导入“）＝＝
Since the birth of Flash, Macromedia gives authors a function: "password-protected from import". If you protect that SWF from import with a password, then that SWF can not be imported. Some vector graphics in the SWF can be imported to FLA file if we don't protect it. This protection serves nothing but false security.
自从 Flash诞生以来，Macromedia（公司）就给了设计者这样一个功能：“密码防止导入”。如果你对一个swf设置了这样一个参数，那么这个swf 就无法被（flash）导入。要知道，如果不进行此项设置，swf文件中的矢量元件（一般为重要的脚色设定或者创意）就能被导入进入fla文件。然而这项 措施只是一种表面的安全工作而已。

Think about that, your SWF is going to be played by the player of users. You can not protect from that player. So, how does it protect the SWF? Well, the protection is in the Flash software you buy. Flash refuses to import if there is a password string in the SWF. Non-sense, right? I can use hex editor to open that SWF and then delete that password string and then the protection is removed.
这么来想，你的swf文件将在用户的播放器中播放。你总不可能来保护（，或者说限制）播放器吧？
那么原理上，它是如何来保护swf的呢？其实不过是在flash中导入之前检查密码字符串。我可以用十六进制编辑器来打开这些swf文件，并且把密码字符串删除，这样，所谓的保护就被破坏（破解）了。

How easy it is! So, forget about that protect function.
如此简单，所以，忘了那项没有意义的保护措施吧！（Flash提供的所谓的导入密码）

CONVERTION TO PROJECTOR FILE AND COMPRESSION
＝＝转换为可执行文件并且压缩＝＝

If I convert it to a projector file in the format of EXE, can the EXE file be decompiled? Yes. The SWF is still there. There are softwares that can easily extract the SWF out. Compression may make the SWF not readable by hex-editor. Is this a protection? The compression algorithm is similar to zip. It is easily decompressed.
如果把swf文件（邦定播放器）转换为可执行的exe文件，这样的exe文件会被破解么？答案是肯定的，swf文件仍然在那里。有一些软件可以轻而易举的 把swf文件提取出来。压缩也许能让swf文件无法被十六进制编辑器打开，这样能起到保护作用么？压缩算法基本与zip算法类似（可以有相应的解压缩算 法）。所以，仍然容易破解。

FLASM AND THE P-CODE
＝＝FlASM和P-CODE＝＝
Then in the era of Flash 5, two popular tools appear. The free "Flasm" and the commercial "ASV 2.0". Flasm is "Flash asm". It interpretates the byte code in the SWF into understandable short codes (p-codes).
早在Flash5.0的时代，有两个非常流行的工具。免费的“Flasm”和商业版的“ASV 2.0”。Flasm其实就是“flash asm”（Flash+汇编），他能够把swf文件的字节全部转换为汇编短码（p-code）

For example, "a=3" is displayed as "push 'a', 3", "setVariable";
The byte-codes in the SWF is "96 08 00 00 61 00 07 03 00 00 00 1D"
比如，“a=3”被转换为“push 'a', 3", "setVariable ”
swf对应的字节码为“96 08 00 00 61 00 07 03 00 00 00 1D”

This is an in-valuable tool if we want to study the "structure of SWF format".
如果我们要学习“swf文件的结构”，这是一个非常不错的工具。

Programmers like to develop software by high level language, such as C, C++. But, when something needs efficience severely, they incorporate low level assembly codes in it. So, sometimes, authors adopt Flasm to write low level p-codes to add efficiency.
（大多数）程序员们都喜欢使用高级语言，比如，C，C++。但是，当某一些（部分、工序）对效率又非常苛刻的要求时，他们（程序员）喜欢参入一些汇编代码。所以，设计者采用Flasm来编写低级的p-codes以提高效率。

So, Flasm has a power to edit the actionscript in the SWF. You can see examples how they use this optimization technique to improve the 3d codes. However, malicious users can "edit" the SWF. Any lock in the SWF can be easily removed. We don't need a "key" to open the lock. We just remove the lock.
所以，Flasm有一种编辑swf中as脚本的能力。你可以发现有时他们（设计师）用这种优化技术来优化3D（引擎相关的）代码。然而，一些不怀好意的用 户就可以借此“编辑”swf。swf中的任何掩饰都能轻易地（被Flasm）移去。我们作的工作甚至是直接将这些障碍挪走，而并非（再花时间）破解它们。

Here is a common and well known technique to protect our movie from being stolen and shown on other domain. We script a check for _url. If the _url is not our domain, then we disable the functions and display a message "You are thief". However, it is easy to remove this script by Flasm. To crack this protection, it takes not more than 1 minute.
这里有一种非常常见的技术来防止我们的swf被其他域名（即网站、站点）盗用。我们设置一个_url检测机制，如果_url检测机制检测到swf不在我们 的域名播放，那么我们就禁用所有的功能，并且显示一条信息“你是一个小偷！”。然而，有了Flasm之后，就非常容易移出这段（检测_url值）的代码。 不出一分钟，我们就可以破解这种swf了。
aw附：也许很多新手并不熟悉“_url”，我把帮助文档中的一段简洁放在这里，一目了然。

MovieClip._url
可用性
Flash Player 4。

用法
my_mc._url

说明
属性（只读）；获取从中下载影片剪辑的 SWF 文件的 URL。（即，如果swf文件在"http://www.awflasher.com/test.swf "那么我就会返回这个字符串）

ACTIONSCRIPT VIEWER AND "void (a)<=b>"c" || 0(!1 && !0)"
脚本勘测器（著名的asv）与"void (a)<=b>"c" || 0(!1 && !0)"

ASV can extract symbols out, so the sound, shape and bitmaps can be stolen.
asv可以（从swf中）提取任何元件，因此，所有的声音、形状（矢量图）和位图会被盗用。
It also extracts the actionscript byte codes. ASV 2 tries to match the p-codes to high level actionscript. When it meets "push 'a', 3", "setVariable"; it display "a=3", a language which is the same as actionscript. However, we can easily crash it by creating codes that do not match a pattern. The codes created by Flasm are easily off the standard pattern, so ASV won't get a match. The famous script that crashes ASV 2 is ";" This is a jung-codes. It does nothing but confuse the ASV 2.
它（asv）还可以提取as脚本。asv2甚至能够把p-code还原成高级as脚本！
当它遇到 "push 'a', 3", "setVariable" 时，就会显示"a=3"，这完全与我们的as脚本一致！
然而我们也可以用增加（干扰）代码的方法轻易地回避asv。用Flasm非常容易增添不规范的代码，这使得asv无法匹配破解。很著名的扰乱代码是分号“；”。它除了给asv制造麻烦，什么实际作用也没有。

However, when the protection scripts are well known, the author of ASV (Burakk) of course won't let it go. The protection technique did not last long before ASV 3.
然而，当代码的保护措施逐渐传开之后，asv的作者Burakk（burak.com）显然不会“坐以待毙”。这种保护方法也在asv3出现之后失效了。

BOOMING OF DECOMPILERS
轰炸破解者
Then the era of MX comes. Penetration rate of Flash dooms. Many decompilers appear.
MX的时代来到了。？？？很多破解软件涌现了出来（aw附：其中我个人最反感的就是国内XX大学XX软件研究院搬asv的XX破解软件，而且完全针对设计师的原创声音和图形！）

ASV 4 is the present version. It displays not only matched actionscript. It also display p-codes if there is no matches. If it gets trouble to interpretate p-codes, it displays the byte codes in the SWF. It also display the offset in the SWF file. This means that, it never "fails". It wont crash because at least it can display "byte codes", the byte in the SWF.
asv4是目前的（最新）版本。它不但可以显示匹配的脚本，还可以显示不匹配的p-codes。如果他遇到无法解释的p-codes，他就会显示swf的 二进制代码。他甚至还可以显示swf文件的偏移。这意味着，它从不“失败”。再恶劣的情况，它也能为我们显示swf的二进制字节。

Even more, Flash MX2004 gives out Javascript API to create "FLA" file. That makes it able to create a FLA file that can export to that SWF. Everything is there now.
更甚，Flash MX2004设置了JavascriptAPI来创建（编译）“fla”文件。这使得我们能自主地把fla文件编译成为相应的swf。所有的东西都浮出水面！

Let alone the sound, shape and bitmaps. Thief does not like these assets because it is so obvious to be caught. Thief likes to steal "actionscript". Because there are hidden passwords. Because there are scripts that block the normal playing of this movie. Because there are functions they can modify and use with less risk of being caught.
我们除去声音、形状和位图不谈，“剽窃者”们对这些显而易见的资源不感兴趣。他们更喜欢找出脚本代码（算法）。因为这些代码中可能有某些密码、或者对影片播放的控制。而且，某些算法可以被他们（剽窃者）修改来投入应用，这样他们被“捉住”的可能性就更小了！

If ASV can only decompile the script into byte codes, then it is useless to most thief. So, many try their best to prevent ASV 4 to decompile the script into actionscript or p-code. In fact, for most other decompiler, when the script fails to match patterns, the decompiler crashes.
如果asv只能把脚本破解成为二进制代码，那么它对大多数剽窃者而言是没有意义的。所以，很多人想方设法地来保护自己的代码，从而使得ASV4把它们（代 码）解释成为二进制代码而非脚本或者p-codes。事实上，大多数没什么技术含量的破解软件在遇到这种情况下就会出现“破解崩溃”。

Here are techniques in the history. The protection effect of each technique last only for a short while and expires soon after it is "published" in the internet and revealed to the decompiler group.
这些历史上所有的保护的技术，在他们“公布”（或者因某种原因用诸于众，比如发布在互联网上）之后，都难逃厄运。

CHUNK DECOMPILING BY THE DATA SIZE – THE SENTENCE

The success of most of the technique to confuse or crack the decompiler is because of the behavior difference between player and decompiler. Player executes byte codes one by one. In real world, it is like reading a book, one word and then the next world. While decompiler usually chop the chain of byte codes into meaningful pieces. In real world, it is like reading a book, one sentence and then the next sentence.
由于“设计师”和“剽窃者”的行为差别，大多数防破解的措施都获得了成功。“设计师”逐“词”地执行代码，好比在真实的世界中一个词接一个词地阅读一本书（逐词）；剽窃者则要把一段一段的代码分解成有意义的内容，好比在真实世界中一个句子接一个句子地阅读一本书（逐句）。

The reason why decompiler behaves like this is simple. Most of p-code command are followed by size of data.
剽窃者进行这种行为的原因很简单。大多数p-code是这样记录的：

For byte codes ("96 08 00 00 61 00 07 03 00 00 00 1D"), decompiler meets 0×96, which means "push". Push what? The next two byte shows (0×0008). What get pushed is the thing stored in the next 8 bytes. ("00 61 00 07 03 00 00 00"). So, usually decompiler chops the short segment in a chunk by the data-size. This inevitably is interpretated as "push something". So, the sentence is ("96 08 00 00 61 00 07 03 00 00 00"). Period is here. The next byte is the begining of the next sentence.
What follows is 0x1D, which means "setVariable". Well, the 8 bytes "something" will be parsed further to be a string 'a' and a number 3.
对于这样一段代码
("96 08 00 00 61 00 07 03 00 00 00 1D")
破解软件遇到味着“push”的十六进制的“96”，可是它“push”什么呢？答案是接下来的两个字节，0800。而运算的结果最终保存在下面的八个字节中("00 61 00 07 03 00 00 00")。所以，通常情况下，破解软件

Lets see the byte codes: ("99 02 00 05 00 96"). 0×99 means branch (or jump). Branch to where? What follows is (0002), so the data is stored in the next 2 bytes. Chop it down. Anyway, we know "99 02 00 05 00" is a sentence. What follows is 0×96, that is the start of next sentence.
现在，我们看看这一段代码："99 02 00 05 00 96". 0×99相当于跳转。跳转到哪里呢？后面紧跟着0002，所以数据被存放在后面两个字节里面，把他们截取下来即可。总之，我们知道"99 02 00 05 00"是（独立的）一句话。后面的“96”则是下一句话的开始。

As third example, byte codes: ("88 08 00 03 00 63 00 62 00 61 00 96 07 00"). 0×88 means define constants. What constants data are defined? What follows is (0008), the constants data are stored in the next 8 bytes. So the sentence is ("88 08 00 03 00 63 00 62 00 61 00"). What follows is the start of the next sentence ("96 07 00 …), which is a "push with a data of 7 bytes.
下面列举第三个例子，这样的代码："88 08 00 03 00 63 00 62 00 61 00 96 07 00"。其中0×88用于定义常量。什么常量呢？紧跟着的0008。那么常量的值就存放在后面的八位字节里。所以这一句话是"88 08 00 03 00 63 00 62 00 61 00"。而后面的"96 07 00 …"则是下一句的开始。它的意义是对一个数据执行七个字节的push操作。

So, the byte codes are chopped down into several sentence. Each sentence starts with a command and data. So, a sentence is a basic unit. Theoretically, nothing is wrong with such approach.

"MAKE PLAYER READ FROM THE MIDDLE OF A SENTENCE"

OK, lets start to discuss the。 technique to crash decompiler. "Make player read from the middle of the sentence".
那么，让我们现在讨论一下终结剽窃软件的技术吧！“让播放器从句子中间阅读”

First I would try to give an example in the real world.
首先，我想来举一个真实世界中的例子。

John says good morning.
Mary says thank you.
约翰说，早上好。
马莉说，谢谢。

Now let's create an SWF:
现在让我们建立一个SWF：

skip 9 words
Tom says John says good morning. skip 3 words
跳过9个
back 7 words
Mary says thank you.
If you read it word by word, the result is the same as original one. But, decompiler reads it sentence by sentence. Several errors occurr. First, it knows Tom says something, but the grammar is not correct. It will report "error". Second, it does not see the second "skip" is a command because it is within the sentence. Third, when it is forced back 7 words, it gets puzzled and it assumes that it should execute the whole sentence start from "Tom said". Fourth, this error makes it looping infinitely between the second and third line.
如果你逐词地来理解这句话，它跟原意没有什么区别。但是，破解软件会逐句的来分析。一些小错误就会发生。比如，开始破解软件知道Tom说了什么，但是语法 却是错误的。它（破解软件）将会报错。第二，它不会把第二个“skip”理解成指令，因为它（这个“skip”）是包含在这句话中的。第三，当它回退七个 单词的时候，将会被困惑。它认为应该从“tom said”开始整句执行。第四，这个错误使得破解软件陷入一个死循环。

In summary, we add a junk codes "Tom says" and give a wrong data size about the length of this sentence. This wrong length covered the "skip" command.
大体说来，我们加入了一段干扰代码“Tom says” 并且给定了一个错误的句长。这个错误的句长包含了“skip”这条命令。

Lets give real examples. Please note that, these technique need manipulate bytecode. It can not be done by pure actionscript.
现在我们来给具体的例子 。请注意，这项技术对字节码的熟练程度要求的很高。它是不能通过纯粹的AS脚本实现的。

EXAMPLE 1
Forward jump with dead codes containing invalid data size
例子一
向前跳过那些含有干扰代码的信息

push True
branchifTrue label2
constants ''
label2:
push 'a',3
setVariable

OK, if you see carefully, the line "constants ''" is a junk-codes. It will never be executed. But, theoretically, it should be executed if the result of the second line is "not True". So decompiler will try to decompile it.
好，如果你稍作分析就会发现“constants”是一段干扰代码。它将不会被执行。但是，理论上而言，它将在第二行为假时执行！而这时破解软件就会分析它。

Lets make the "sentence size" after "0×88 – constants" to include the bytes till the end of script. You know, decompiler will chop the bytecodes into 3 sentences like this:
让我们把句长放到“0×88 – constants”的后面。你知道，破解软件会把字节码分成三部分。

push True
branchifTrue label2
constants
label2: push 'a',3 setVariable

If you try to decompile the SWF, some decompiler will crash due to the four errors I mentioned above. Some decompiler will survive but only display: "if(false){};". ASV 3 also failed to reveal the script. But ASV 4 succeeds. To crack this SWF, we remove the dead codes "constant xxxx", (0×88 and the following two bytes), then everything gets decompiled.
如果你试图破解它，一些破解软件就会出现我提到的四个错误。一些破解软件不会崩溃，但是只能显示
“if(false){}”。 ASV3对此无效，但是asv4就能成功了。要破解它，我们把constans给去掉便可以了。

Here is the zip file explaining the detail how to create such protected file.

EXAMPLE 2
Backward jump with dead codes containing invalid data size

push 'b'
label1:
push 'a',3
setVariable
branch label2
branch label1
label2:
OK, the -push 'b'- is really a junk codes that we are going to modify to crash ASV 4. Let's modify the "length of sentence" for -push 'b'-. Modify the 2 byte data after "0×96". Make the sentence length cover the bytes till before -branch label1-. Thus the decompiler will take the bytecodes as 3 sentences:

push label1: push 'a',3 setVariable branch label2
branch label1
label2:
Now, decompiler complains that it does not know what is pushed. Also, it interpretates this to be an infinite loop between the first sentence and the second sentence. This technique crashes most decompiler including Flair. Flasm fails. ASV 4 fails. To crack this SWF, we manually remove the dead code "push b" (0×96 and the two folowing bytes), then everything gets decompiled.

After this technique is known, burakk has fixed ASV 4 and handled that dead codes correctly. The next version will survive.

Here is a zip file explaining the detail and example to create such protected file.

THE NON-DISPLAYABLE CHARS AND OBFUSCATOR

In addition to the technique of blocking the decompilation, we can make the decompiled result not easy to read. You may check the web sites about Obfuscator.

Basically, it renames the variables and functions names.

function -3(-4){trace(-4);}
function -1(0,-2){
if(0<-2){-3(1);}
}
Surely, theft could not just copy and paste these script for use. The compiler won't let you name a function like this.

The limitation of Obfuscator is that th changing of functions names might cause some troubles in the script below.

function myFun(){trace("myFun");}
a="my";
b="Fun";
this[a+b]();
Another technique is to make functions names non-displayable. For example, if I name my function with Chinese characters, the decompiler might fail to display it well. Then we will see:

function ?(){?,?){?.?=?;}
ASV 4 will uses unicode to display undisplayable characters. So, it is readable. It only add slight difficulties.

SELF MADE PROTECTION

If you find a good way to protect your SWF from decompiler, don't share it with others. At least don't publish it on the internet. Of course, it is impossible to protect 100%, and at least it is not protected from me. However, not every one knows SWF format very well. Many theft can only decompile the SWF by software available. So, if your goal is to keep as less theft as possible, you keep your method secret.

Just remind you once again. Your SWF is naked. For one who knows SWF format, everything is revealed. If your goal is just to protect your "some functions you figured out", it should be safe. They are unlikely to steal your function, they like to write their own.

COMMON PROTECTION

We create a game on our website for online playing. Unfortunately, many visit our site only once and then keep a downloaded version offline to play. Sometimes we even see our game appear on other's domain.

To avoid this, here come some ways of protection:

1. CHECK DOMAIN

We write a script to check _url. If _url is "http://www.myDomain.net/game.SWF " then the movie plays otherwise stops or quits. When it is played offline, the _url should be something like "file://C| someSub/game.SWF", when it is put on other's domain, the _url should be "http://www.others.net/game.SWF ". So, this technique correctly add some protection. Of course, not to malicious decompiler. Those script can be easily removed or changed by Flasm to disable the check. Although it is unlikely to see a cracked SWF on others domain publicly, it may be passed as a offline playable SWF.

方法一：检查域名

我们可以写一段脚本来检测域名。当域名为http://www.myDomain.net/game.SWF时，说明（用户）在我们的网站上浏览。那么flash就播放。否则，就退出或者停止。因为当flash在硬盘时，域名变量返回的是 "file://C| someSub/game.SWF"；而当flash在他人的网站上，则是他人的域名："http://www.others.net/game.SWF "。虽然它还是给很多破解者制造了一定的麻烦，然而通过Flasm能轻松化解这种障碍。哪怕人家不把你的文件挂到他的服务器上。他也可以在本地直接运行这个swf（而不再登录你的网站）

2. SERVER PASSWORD

We write a script, and when the game plays, it loads a password from the server. If it is null, then the game stops or quit. This is easily cracked by the malicious user who edits the SWF and removes those script. What scripts can not be removed?
When our game starts to play, it loads from the server a map data which is essential to the game. Well, the malicious user can not remove the script. He must supply the map data.
Of course, he can pick the map data from the cache in the temporary directory and supply it to the SWF to activate the game.

方法二：设置服务器端密码

我们可以写一段脚本，当（flash）游戏执行时，从服务器读取一段密码，如果为空，则停止或者退出。这也可以被恶意破解者轻松化解。
或者，我们可以把一个游戏必备的地图数据放到服务器端。然而，破解者仍然可以从缓存中读取这样的数据。

3. HOLD THE SWF OR VARIABLES ON THE SERVER

It is an extention of the second technique. This technique is widely used. Initially, the game SWF is only a loader. When play button is clicked, another SWF is loaded in. When a map is needed, it loads map data from the server. When it meet an obstacle, the obstacle SWF is loaded from the server again. The data of new level is also sent from the server.
Here we see the principle: the best way to protect from decompiling is "do not give".
If some stupid theft downloads only the game.SWF, he can not play the game. He would need to pick all the SWFs and variables in the cache. Open all the SWFs, edit the variable name to conform to the variable name in the cache.
If our map is randomly generated by CGI, the theft might have only one copy of map. He will not have the power to generate maps randomly. If that is a maze game, then at best, he can only play one puzzle. He has lost the fantastic "dynamically creating maze" funciton.
If the malicious user plays the game but meets a new obstacle, that game might fail because he does not have the new obstacle SWF in his cache.
So, many algorithm and functions are kept in server side. The SWF is nothing by an interface. Perfect protection. The pitfall is that, this turns out to be a game of CGI, not Flash. We are discussing about the protection of SWF. The solution is not fair, because it is not protecting the SWF itself.

方法三：让服务器来保管变量

他是第二种方法的扩展。这种技术目前被广泛应用。最初，swf只是一个在入的（容器）。当按下播放按钮。另一个swf文件被加载进入。当需要地图数据，就从服务器端载入一个地图数据（文件）