我在写一个Flash应用程序，恐怕真的会被反编译。为了尽量减少这个机会，我想进行模糊处理文件。

I'm writing a flash application and am afraid that it will be decompiled. In order to minimize this chance, I want to obfuscate the file.

我听说sec​​ureSWF（ http://www.kindisoft.com/ ）的，他们这样做列出一些用户评论。这些都是然而，如此乐观，他们很难相信。这里没有一个单一的悲观评论（甚至没有关于比如，用户界面​​或支持），所以东西告诉我，他们可能不会张贴他们。从我的经验，即使是最好的公司有一些评论家飘飞。

I have heard of secureSWF (http://www.kindisoft.com/), and they do list some "user comments". These are however so optimistic that they are hard to trust. There's not a single pessimistic comment (not even about eg. the user interface or support), so something tells me that they might not post them all. From my experience, even the best companies have some kind of critic every now and then.

所以，在这里任何反向工程师，能告诉我怎么经历你是在工作 - 您是否设法反向工程secureSWF模糊处理的文件？如果是的话，多久没它带你约？你会推荐这个软件？

So, any reverse engineers here, could tell me how experienced you are in the job - and whether you managed to reverse engineer a secureSWF obfuscated file? If so, how long did it take you approximately? Would you recommend this software?

感谢很多提前。

推荐答案

免责声明：我的Kindisoft工作的

secureSWF是最好的动作混淆在那里。我相信这是绝对毫无疑问的： 的https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3

secureSWF is the best ActionScript obfuscator out there. I believe there is absolutely no doubt about that: https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3

http://asgamer.com/2009/why-如何对加密 - 您 - 闪光的SWF

code混淆器应该使它不可能对反向工程师使用自动化的工具，它可以检索可读的源$ C ​​$ C（即反编译器）。和范围内的，secureSWF是非常成功的。因为自动化过程不再可能，时间和精力进行反向工程的模糊处理的应用取决于其大小。应用越大，越复杂和耗时的反向工程变得越大。再从头开始编写的code是通常更简单。

Code obfuscators should make it impossible for reverse-engineers to use an automated tool that can retrieve readable source code (i.e. a decompiler). And within that, secureSWF is very successful. Since automating the process is no longer possible, the time and effort to reverse-engineer the obfuscated application depends on its size. The larger the application is, the more complex and time consuming reverse-engineering becomes. Re-writing the code from scratch is usually simpler.

模糊处理是不加密。它应该是一个单向的过程。当您重命名标识符，原来的名称不再存在。让他们回来的唯一方法是通过猜测。同样的道理也适用于控制流混淆。重整的指令，并改变了code字节code如何执行不跟随动作的同样的规则。考虑以下几点：

Obfuscation is not encryption. It should be a one-way process. When you rename identifiers, the original names no longer exist. The only way to get them back is by guessing. The same thing applies to control flow obfuscation. Mangling the instruction and changing how the code executes in bytecode does not follow the same rules of ActionScript. Consider the following:

// swapping the values of a and b
var t = a;
a = b;
b = t;
// will be compiled to something similar to:
get a
set t;
get b;
set a;
get t;
set b;
// and will be obfuscated to something similar to:
get a
get b
set a
set b
// then it can become:
goto l1:
l2:
set a
set b
goto l3
l1:
get b
get a
swap
goto l2
l3:...
// after that it becomes:
goto l1:
l2:
set a
set b
goto l3
get b
dup
add
l1:
get b
get a
swap
goto l2
l3:...
// and finally (? denotes an unprinted char)
goto l1:
l2:
set ?
set ?
goto l3
get ?
dup
add
l1:
get ?
get ?
swap
goto l2
l3:...

现在，假设应用到所有code。以不同的方式每一次。我会走得更远比声称逆向工程SWF文件变得坚硬如本地code。我说这变得更加困难。

Now imagine that applied to all your code. Every time in a different way. I would go further than claiming reverse-engineering SWF files becomes as hard as native code. I say it becomes even harder.

但是，这可能吗？当然是。如果您有什么很重要，攻击者将进入所有这些麻烦，那么它绝对不应该在可能的恶劣的环境（客户端）执行。虽然有帮助，混淆不应该主要认为是一种安全措施。更多信息可以在这里找到： http://en.wikipedia.org/wiki/Security_through_obscurity

But is it possible? Of course it is. If you have something so important, that attackers will go into all this trouble for, then it definitely shouldn't be executed in a possibly hostile environment (the client). Although it helps, obfuscation shouldn't be mainly thought of as a security measure. More information can be found here: http://en.wikipedia.org/wiki/Security_through_obscurity

其他替代品包含保持敏感code服务器和加密上运行。服务器端编码并不总是可能的。在很多情况下，你真的需要你的code在客户机上运行。加密更糟糕的是，解密已发生在客户端上，你将有发送解密code和关键，从解密Ç自己的$ C $分文未留prevent攻击者在客户端。

Other alternatives include keeping sensitive code running on the server and encryption. Server-side coding is not always possible. In many cases, you really need your code to run on the client. Encryption is even worse, decryption has to happen on the client and you will have to send the decryption code and key to the client leaving nothing to prevent the attacker from decrypting the code himself.

我希望我提供了足够的技术内容来支持我的观点。现在回无耻营销:)。下载演示版和测试它自己。这不是时间有限，而且是全功能的，除了我们在处理的文件留下水印。因为我们去的人在论坛上后stackoverflow.com助阵，我们的技术支持服务，绝对超出预期;）

I hope I provided enough technical content to support my views. Now back to shameless marketing :). Download the demo version and test it yourself. It's not time limited and is fully functional except for a watermark we leave on processed files. Since we go after people on forums and stackoverflow.com to help out, our technical support service definitely exceed expectations ;)

更多信息可以在这里找到： http://www.kindisoft.com/secureSWF/faq.php

More information can be found here: http://www.kindisoft.com/secureSWF/faq.php