简单说下SWF文件的混淆原理，（已经明白的请跳过本段）：我们的AS源代码被编译完成后，SWF内部会形成一个字符串映射表，包含源码里出现的所有字符串（类名，包名，成员变量名，常量等）。一个数字(相当于地址指针)对应一个全局唯一的字符串。而原本的代码片段包含的字符串都会被替换为对应的数字指针。代码实际执行过程用的都是这些数字指针。所以即使你修改了映射表内的字符串内容（不能修改Flash API的关键字，会导致调用接口失效），通常对代码执行过程也不会产生影响。而反编译就是根据数字指针从这个映射表取出对应字符串填回代码，最后生成人可以阅读的源代码。其实所有语言生成的程序都是可以被反编译的。只是其他语言编译后没有存储明文字符串。还原了也没有可读性。SWF可以被反编译破解出来正是因为存储了明文的字符串。所以我们选择性的替换这个映射表的内容为毫无意义的其他字符串。这个程序就像二进制一样没有可读性了。这就是混淆的基础。
还有另一种流行的SWF保护方式：加密。简单说就是对SWF文件的字节流按一定规则篡改，然后运行时再还原回来。但是加密无论如何层层处理，最终都是要在内存中还原出原始的swf。所以有经验的破解者根本不用去猜你的加密算法，直接从最终结果内存抓取即可。不像加密，混淆才是真正二进制安全的方法。因为生成的SWF文件本身已经不包含可读性的代码了，这是一个不可逆的过程。
混淆之所以一直没有被主流采用，我认为最主要的原因是它很容易带来隐藏Bug。先说下传统的混淆方式。都是在导出发新版的SWF后，用第三方的库去解析SWF文件字节流，然后修改里面的字符串映射表内容。（这个方式有现成的第三方库，可以参考这个帖子）因为所有的字符串都是合并起来的，你修改一个字符串，就会同时影响到所有引用它的地方。举个例子：你自定义了一个类叫Sprite，那么这个类的类名会和flash.display.Sprite的“Sprite”共用一个数字指针。你要是修改了这个字符串的内容，你可以实例化你自定义的那个类（只是名字改了无所谓），但想实例化Flash API的Sprite时就会出错，会提示在那个包里找不到这个修改过的类名。还有通过字符串属性去访问的方式，被修改了之后也会带来各种问题。
所以混淆的关键其实是：确定哪些是可以安全修改的关键字列表。答案是没有通用办法。大家都只能根据自己项目的特点来写。很少能做到一个工具通吃所有情况。而且即使针对自己项目写的，也不敢100%保证获取的关键字列表是安全的，因为项目代码一直在变化。你每次发版本都得测试一遍，如果是隐藏很深的Bug，基本都很难发现，也无从测试。加上学习成本，大部分人自然就优先选择加密的保护方式了。因为写一次工具就可以无限复用。
原文：http://blog.domlib.com/articles/582.html