有逆向工程师有 secureSWF 的经验吗？
我正在编写一个 Flash 应用程序，担心它会被反编译。 为了尽量减少这种机会，我想混淆该文件。
我听说过 secureSWF (http://www.kindisoft.com/)，他们确实列出了一些“用户评论”。 然而，这些人过于乐观，以至于很难相信。 没有一条悲观的评论（甚至没有关于用户界面或支持的评论），所以有人告诉我他们可能不会全部发布。 根据我的经验，即使是最好的公司也会时不时地受到某种批评。
那么，这里的任何逆向工程师都可以告诉我您在工作中的经验如何 - 以及您是否成功地对 secureSWF 混淆文件进行了逆向工程？ 如果是这样，您大约花了多长时间？ 您会推荐这个软件吗？
预先非常感谢。
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.
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.
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?
Thanks a lot in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
规则1：
无论是否有 SecureSWF，人们都会遇到麻烦吗？
Google 快速表明，尚未多次尝试反编译使用 secureSWF 创建的 SWF 文件...但它们仍然必须满足编译字节码的规范...所以这只是混淆。 缺乏测试表明：
我认为前者更有可能。 如果您说了 Flash 应用程序的用途，那么这些要点可能会更具体。
我会寻找与发布后多久后这些事情被逆转相关的数据来源，而不是系统本身的安全性（这是不相关的）。
还要确保使您的源代码安全（而不是与社区合作）是最好的策略，因为考虑到在某些时候，坚定的头脑将能够访问您的逻辑。
从商业角度来看，你的战略定位不应该是让你的逻辑混乱……因为这是徒劳的。 你可以随心所欲地专有......但人们会绕过它（只需询问游戏行业即可）。 严厉的安全措施会引起强烈反对（请参阅 DRM）。
如果您确信您的应用程序如此令人惊叹以至于人们会努力扭转它，请寻找另一个价值主张。
Flash 就是其中之一，就像 JavaScript 一样，你能做的只有这么多，这真的很重要吗？ 如果没有链条中的其他环节，应用程序逻辑有什么用呢？
无论如何，寻找逆转编码所需的努力，而不是软件客户端的感知强度。
无论如何，祝你好运！
Rule 1:
With or without SecureSWF, will people go to the trouble?
A quick Google suggest that not many attempts have been made to decompile SWF files created with secureSWF ... but they must still meet the specification of compiled bytecode ... so it just amounts to obfuscation. The lack of testing suggests:
I think the former is more likely. If you said what the Flash app does, then these points might be more specific.
I would look for sources of data relating to how long after release these things have been reversed rather than the security of the system itself (which is irrelevant).
Also ensure that making your source secure-ish (rather than cooperating with the community) is the best strategy considering that at some point, a determined mind will be able to access your logic.
From a business point of view, your strategic position should not be in keeping your logic scrambled ... as this is futile. You can be as proprietary as you want ... but people will get around it (just ask the games industry). And heavy-handed security causes backlash (see DRM).
If you are convinced your application is so amazing that people will go to the effort of reversing it, look for another value proposition.
Flash is one of those things, like JavaScript, where there is only so much you can do and does it really matter? What good is the apps logic without the other links in the chain?
Anyway, look for the required effort to reverse the encoding rather than the perceived strength of the software's clients.
Anyway, Good Luck!
免责声明：我在 Kindisoft 工作。
secureSWF 是目前最好的 ActionScript 混淆器。 我相信这一点是毫无疑问的：
https://www.mochiads.com/community /forum/topic/which-obfuscator-should-i-use-as3
http://asgamer.com/2009/why-how-to-encrypt-your-flash-swf
代码混淆器应该使逆向工程师无法使用可以检索的自动化工具可读的源代码（即反编译器）。 其中，secureSWF 非常成功。 由于不再可能实现该过程的自动化，因此对模糊应用程序进行逆向工程的时间和精力取决于其大小。 应用程序越大，逆向工程就越复杂且耗时。 从头开始重写代码通常更简单。
混淆不是加密。 这应该是一个单向过程。 当您重命名标识符时，原始名称将不再存在。 把它们找回来的唯一方法就是猜测。 同样的事情也适用于控制流混淆。 修改指令并更改字节码中代码的执行方式并不遵循与 ActionScript 相同的规则。 考虑以下内容：
现在想象一下这适用于您的所有代码。 每次都以不同的方式。 我想说的不仅仅是逆向工程 SWF 文件变得和本机代码一样困难。 我说这变得更加困难。
但这可能吗？当然可能。 如果你有一些如此重要的东西，以至于攻击者会陷入所有这些麻烦，那么它绝对不应该在可能敌对的环境（客户端）中执行。 尽管混淆有帮助，但不应将其主要视为一种安全措施。 更多信息可以在这里找到：
http://en.wikipedia.org/wiki/Security_through_obscurity
其他替代方案 包括保持敏感代码在服务器上运行和加密。 服务器端编码并不总是可行。 在许多情况下，您确实需要代码在客户端上运行。 加密更糟糕，解密必须在客户端进行，您必须将解密代码和密钥发送给客户端，不留下任何东西来阻止攻击者自己解密代码。
我希望我提供了足够的技术内容来支持我的观点。 现在回到无耻的营销:)。 下载演示版并自行测试。 它没有时间限制，并且功能齐全，除了我们在处理的文件上留下的水印之外。 由于我们在论坛和 stackoverflow.com 上寻求帮助，因此我们的技术支持服务绝对超出了预期；）
可以在此处找到更多信息：
http://www.kindisoft.com/secureSWF/faq.php
DISCLAIMER: I work for Kindisoft.
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-how-to-encrypt-your-flash-swf
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.
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:
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.
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
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.
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 ;)
More information can be found here:
http://www.kindisoft.com/secureSWF/faq.php
我对混淆器没有丰富的经验，但几个月前，我被要求在一个特定项目中尝试其中的几个（这实际上是一个相当简单的多人游戏）。 我尝试了 SecureSWf 和 Amayeta SWFEcript（这两个试用版，如果我没记错的话，功能齐全）。
两者在更“高级”的功能上都存在一些问题。 如果我选择只重命名标识符，事情就会顺利进行。 但即使使用默认设置（最小的控制流混淆），混淆器之一也会生成非法字节码，即它会被玩家的验证者拒绝。 这会产生一个异常，仅此而已。 我实在记不清是哪一个了，但是一运行swf就失败了。
我没有进一步测试，但这让我意识到这也是你必须考虑的事情。 使用此工具需要支付额外费用。 对于您的目的来说，它可能是可接受的，也可能不是，但您应该考虑到它。 一旦您更改并扭曲了 swf，它就不再是您调试和测试过的 swf。 因此，现在您将进行两倍的工作测试，因为混淆器有可能引入错误。 我看到的这一点非常明显，立刻就让玩家震惊了，但可能还有更微妙、更难的。 如果您碰巧有一个仅在您的“安全”版本中显示的错误（或更糟糕的是，它看起来只发生在您的安全版本中，但您并不积极），那么调试它不会很有趣。
当然，这并不是一个正确的评论，只是我有限的经验。 大多数混淆器都有免费试用版，因此您可以自己尝试。 我还应该说，反编译和反汇编的代码非常非常混乱，理解它的意义将是一项艰巨的任务。
然而，我想我应该添加一个不经常被提及的不同观点。
I don't have extensive experience with obsfuscators, but some months ago I was asked to try a couple of them for a specific project (it was actually a --rather simple-- multiplayer game). I tried SecureSWf and Amayeta SWFEncript (both trial versions, which were fully functional, if I recall right).
Both had some problems with the more "advanced" features. If I'd choose just to rename identifiers, things would work smoothly. But even with the default settings (a minimum of control flow obfuscation), one of the obfuscators produced illegal bytecode, i.e. it would be rejected by the player's verifier. This produces an exception and that's about it. I really can't recall which one, but it failed as soon as you run the swf.
I didn't test much further, but it made me see this is something you have to take into account as well. There's an extra cost in using this tools. It could be acceptable or not for your purposes, but you should account for it. Once you change and twist you swf, it's not the same swf you've debugged and tested anymore. So, now you'll have twice as work testing, cause there's a chance the obfuscator has introduced bugs. The one I saw was pretty evident and blew the player right away, but there could be subtler, harder ones. And if you happen to have a bug that only shows in your "secure" version (or worse, it looks like it only happens in your secure version, but you're not positive), debugging it will not be fun.
Of course, this is not a proper review, just my limited experience. Most obfuscators have free trials so you can try them yourself. And I should also say that the decompiled and disassembled code was well, really obfuscated, and making sense out of it would be a daunting task.
Yet, I thought I would add a different perspective, which is not often mentioned.
看看开源编译器，比如 SWFMill 和 Haxe http://haxe.org/ 它们生成不同的字节 -最终 swf 中的代码可能会导致许多流行的反编译器崩溃。
很明显，可以像普通的 adobe 编译的 swf 一样获得代码，但是许多反编译器无法使用它，所以如果您想增加“所需的工作量”，我建议您看看这个解决方案也许可以创造一些混合所有这些的东西。
Take a look at open source compilers, like SWFMill and Haxe http://haxe.org/ they generated different byte-code in their final swf an can crash many of popular decompilers.
Is obvious that the code can be obtained just like the ordinary adobe compiled swf, but many decompilers will just not work with it, so if you want to increase the 'amount of effort needed' I would suggest you to take a look at this solution and maybe create something mixing all of it.