安全性 – 在编译之前保护SWF

GOOGLE充满了所谓的SWF加密器/阻碍器/储物柜.

但其中99%会导致复杂应用程序出错.在使用导入的3D库或使用外部文件的应用程序中.或者在内部有数千行代码且内部有许多动画的复杂应用程序中.

我一直在使用KINDISOFT软件,我的团队使用ADOBE FLASH CS5和CS6以及FLEX开发了200多款游戏.从FLEX生成的SWF能够由KINDISOFT和其他SWF保护器编码,而由ADOBE FLASH导出的其他SWF文件非常混乱,错误从开始出现.

所以我有两个问题:

a)当使用诸如SWFENCRYPT或secureSWF之类的软件或其他用作SWF文件输入的类似产品时,它们实际上会反编译您的文件,插入封套和一些安全性,然后重新编译?或者他们只是改变字节码?

b)是否无法在原始源文件中插入保护,这样可以大大降低出现bug的风险?

这个问题的目的是在编译之前找到如何保护你的FLASH应用程序,如果你有源代码,那么在编译之后,代码将100%起作用,而不是在编译后保护你的SWF并冒生成风险错误.

感谢您的时间

最佳答案 我认为混淆软件正在改变字节码.例如,添加了无效的字节码,用于打破过去的decomplilers,而Flash Player仍然正确地播放swf.这是剑和盾的无尽战斗(但似乎混淆器处于更好的位置.)

更具体的是,如果您的应用程序在混淆后中断 – 您可以做什么:

>从混淆中排除脆弱的资源,如动画剪辑.如果你绝对需要保护它们,你可以用简单的算法加密它们,比如RC4(它很快),并在混淆保护部分解密(见as3crypto).
>与KindiSoft合作,向他们发送错误报告,并提供破损swf示例.
>添加自己的混淆方法,比如在图片/其他资源中隐藏逻辑.

点赞