所谓简单聊下，就是大致提一下，不做深入研究，毕竟自己好久没涉及Flash这一块了。这里一方面是给好友Tony(http://www.greatony.com)开发的工具做一下宣传，另外也算分享一些我之前的想法吧。
和目前炒得很火的HTML5不同的几处之一，Flash产生的最终发布格式是SWF，而非可见代码的HTML tag + js 组合。这样虽然被很多人批评诸如对搜索引擎不透明、难以做第三方扩展等问题，但却有另外一个好处：对知识产权保护比较有利。
虽然位图、声音、矢量图等信息仍旧以原先的格式打包进入了SWF文件，这部分内容还是可以轻易被各类Flash逆向工程工具获得，但是最核心的AS3源代码已经被编译成为了Bytecode，理论上，这是可以做到令逆向工程者无法获取与源代码100%相同的逆向结果的。另外，扯开点说，swf本身也作了LZ压缩，在网络通讯上，与下载等量功能的HTML5也具有优势，同时Adobe也给出了比较清晰(?)的swf specification。所以我近期还是比较看好Flash的未来的。
好了，不扯远了，这里接说说前面我提到那个“理论上，这是可以做到令逆向工程者无法获取与源代码100%相同的逆向结果的。”相信凡是做过Flash开发的朋友们都知道这条目前是不成立的，诸如ASV等逆向工具均可以得到几乎是与源代码一致的反编译结果，甚至连内部变量都可以获得。造成这样的原因主要还是Flash编译器，比如mxmlc，对Bytecode没有做过多复杂的处理。
就像我之前在Flash交流会(http://www.csksoft.net/blog/post/avm2_intro.html)提到的，该编译器并没有在编译阶段对AS3源代码做任何的优化。(Flash VM将在JIT阶段做出简单的优化) 相反，他甚至会产生比源代码更加糟糕的Bytecode，同时，也会包含很多源代码的细节。这就给反编译提供了很多的便利。
其实相同的问题在Native程序开发时就早已遇到过，搞反汇编的朋友应该很了解混淆、花指令这类的概念。简单的来说就是插入无关的指令来干扰反汇编程序，使得他崩溃或者无法得到正确结果。同时，混淆的汇编代码也会造成人工分析汇编的障碍，从而提高了软件分析的难度，最终达到了保护软件核心算法不被逆向的手段。
同样，我们也可以利用这些技术来达到保护SWF文件的办法。关于这个，Tony同学比我有更多的研究，大家不妨阅读他Blog的几篇文章以及他前不久在Flash交流会做的演讲：
演讲：《Swf文件格式和Abc代码混淆工具的开发》
http://v.ku6.com/show/MwjMgfhEgUFoiZhx.html
SWF文件格式和ABC代码混淆工具的开发 （一） – 出发点和目标
http://www.greatony.com/?p=84
SWF文件格式和ABC代码混淆工具的开发（二） – SWF和ABC文件格式
Tony也开发了一款针对AS3.0 SWF的代码混淆与分析工具 SWFSpy，目前已经支持对Bytecode进行符号名替换、插入无关代码等混淆操作，对付ASV等工具已经绰绰有余，同时可以用来观察SWF各Tag数据，比如其中的图像资源，也可以反汇编ABC代码。受他之托，这里介绍此工具给各位。我个人认为此工具虽然目前还在不断完善中，但核心的混淆和分析功能均已经实用。
他网站提供了该混淆分析器的免费版本。
SWFSpy
http://www.orandea.com/product?lang=cn
下面是几张截图，分别为支持的混淆选项、Tag分析和反汇编。
再回来文章的主题上来，其实目前Flash的保护除了Bytecode混淆还可以做更进一步的扩充，比如已经广泛用于native程序的加壳技术，不过AVM2对代码执行权限的限制可能会制约加壳的实施，但不妨作为一个有益的尝试。加壳不但可以保护代码，同时也能降低代码尺寸，这个在Scene Demo中有很好的体现，如果今后谁实现个Flash版本的kkrunchy壳(http://www.csksoft.net/blog/view.asp?id=165)进行PAQ7算法的压缩，那或许Scene Demo比赛中说不定还真有Flash影子了，当然，Adobe需要继续优化AVM2才行。这就权当一种假设吧。
虽然工作后已经很久没有使用Flash开发过完整的东西，不过我还是会时刻关注这方面的技术，回想高中时候最早接触的Flash4到目前的Flash11，变化还是很大的。另外也想到自己Flash网站好久没有更新了，现在都是AS3得天下了，当年花费我比较大心血的AS1.0的网站，或许是可以开源了...
................