[AS3] 如何在另一个的SWF嵌入SWF隐藏库和代码
下面讨论的技术是相当容易执行的，花费几分钟的时间。您可以使用此方法与代码混淆，加密或其他保护的方法-这只是增加了另一层保护。虽然这不会成为一个100 ％万无一失的保护，但它仍然是比完全没有强，并有助于阻止大多数轻松的反编译。
正如标题中提到的.基本想法是在另一个“壳”的SWF简单地嵌入您的实际的SWF 。正是这种“空壳”的SWF ，你将随后部署/分发。
MainShell类
在另一个的SWF嵌入SWF ，您可以使用类似下面文件类：
package
{
import flash.display.Loader;
import flash.display.Sprite;
public class MainShell extends Sprite
{
[Embed(source="ActualSWF.swf", mimeType="application/octet-stream")]
private static const bytes:Class;
public function MainShell()
{
Loader(addChild(new Loader())).loadBytes(new bytes());
}
}
}
当这个“壳”的SWF运行，它会
（一）建立的一个实例flash.display.Loader ;
（二）添加装载实例显示列表;
（三）实例化的一个嵌入的SWF作为一个 ByteArray ;
（四）装入ByteArray到装载实例。
加载外部模块SWF到主机SWF以同样的方式工作 ，但在这种情况下，模块内嵌入的SWF是在主机SWF内 。这和装载外部SWFs不同，因为任何外部的SWF仍然可以很容易地从浏览器的缓存得到并分别反编译得到源码。
这将对最终用户完全透明的-它看起来像实际的SWF已运行。
FlashDevelop
对于使用FlashDevelop IDE的用户中，你可能意识到自己的SWF库浏览器（不像反编译,SWF嗅探出于完成代码用在这里合理，漂亮，等等） 。如果您试图浏览“壳”的SWF在FlashDevelop的项目管理面板中，在嵌入式的SWF您将不会看到库（类别和符号） 。这可以作为一种迅速核实，是否是受使用以上讨论“嵌入技术”保护的SWF。
拒绝反编译
这种保护方法假定反编译不能自动识别，提取和反编译二进制对象作为嵌入式的SWF 。因此，资产（类别和符号）在“ ActualSWF.swf ”将不再被反编译直接访问到 。
我试着使用这一技术嵌入式技术在反编辑软件（Sothink 和Trillix ）试用版下,（actionscript 类，艺术图片,影片剪辑 符号等）的安全隐藏。
因为这代价小很容易实现，我建议你试试，看看效果。如上所述在一个“空壳”的SWF套上SWFs，并使用一个反编译试图破解它。也许有非试用版和/或其他反编译软件我还没有尝试到可以战胜这个简单的保护层，但即使他们这样做了…
进一步思考
虽然有可能反编译制造商可能最终识别 提取 反编译嵌入的SWFs.您可以采取进一步的事情，使保护更加难以破解。
不用直接嵌入的SWF ，你可以通过一些加密和内嵌加密的SWF运行它 -这是MIME类型的“ application /八位字节流” ，这样你就可以真正嵌入任何二进制文件（甚至无效的文件类型） 。随后，“空壳”的SWF将解密ByteArray提供给它面前的loadBytes （ ）装载实例的方法。
必须非常明确，这里的意图是不完全加密。真正的目标是要故意“损坏”嵌入式的SWF ，这样，即使提取， decompilers不能轻易识别并运行/反编译它作为一个独立的SWF 。
为了破坏的SWF ，有无数的方法-使用简单的加密，字节变换 ，附加/ 前缀无用字节，等等哦，你的想法…基本上任何使SWF文件无效，不再作为一个可执行的SWF 。您甚至可以分裂SWF到两个或两个以上的二进制块，并在运行时间时重建损坏的嵌入SWF。
既然有这么多不同的算法损坏SWF ，那么几乎不可能反编译自动识别的方式来重建损坏的嵌入式的SWF 。
免责声明
不用说，如果您决定损坏/加密的SWF ，你必须能够重建，在“空壳”的SWF ，嵌入式二进制对象纳入了工作的SWF 。因此，虽然我们也许能够防止自动解密（主要目标在这里） ，请注意，这不提供保护，防止黑客确定（反编译的“空壳”的SWF ，让解密逻辑，嵌入式的SWF提取手动，解密，然后重新运行的SWF通过闪客） 。
