通常用于保护 SWF 免遭反编译或至少防止代码/密钥被盗的方法是什么?

发布于 2024-10-09 17:47:27 字数 201 浏览 0 评论 0原文

由于 SWF 非常容易反编译,如果我要分发带有安全密钥的 SWF 或一些有价值的代码,我应该如何保护它?

编辑: 我认为反编译SWF非常容易,因为它是字节编码为SWF然后编译运行的。 Java 编译和执行也会发生同样的情况。这是否意味着即使是java代码也不够安全?

那么,为什么 Java 更加值得信赖和可靠,而 SWF 在任何地方都不被认为是安全的呢?

As SWFs are notoriously easy to decompile, If I am distribution SWF with secure keys inside or some valuable peace of code, how should I secure it?

EDIT:
I think it is very easy to decompile SWF because it is byte coded to SWF and then jitted to run. This same happens with Java compilation and execution. Does this mean even java codes are not secure enough?

Why, then, Java is far more trusted and reliable and SWF is not considered secure anywhere?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

二智少女 2024-10-16 17:47:27

简短的回答是不要这样做。即使使用代码混淆或将数据存储在字节数组中,也无法阻止有决心(并且能够)从您的来源获取任何内容的人。

您尝试将什么类型的安全密钥放入您的 swf 中?它将用来做什么?

The short answer is DON'T do that. Even with code obfuscation, or storing data in a byte array, there is NO WAY to prevent someone who is determined (and able) from getting anything and everything from your source.

What type of secure key are you trying to put into your swf? What will it be used for?

热风软妹 2024-10-16 17:47:27

钥匙盗窃事件可能已经结束。如果有人致力于此,他们就会找到一种方法,尽管令人困惑,但仍能找到关键。

代码保护&知识产权则是另一回事。这里,混淆和“加密”(即为防止反编译器正常运行而采取的任何措施)是有效的方法。如果您的代码足够模糊,竞争对手就很难窃取它或了解太多关于您代码的内部结构。这是不可行的。哎呀,尝试学习别人的代码已经够难的了,所以尝试破译看起来像 loc_12312++; 的代码。 if (loc_23423) loc_4345(); 不值得任何人花时间。

我强烈建议,如果您关心应用程序设计和内部工作中的 IP,请使用 SecureSWF 等工具来尽可能地混淆代码。与许可证密钥不同,这里的保护并不像最薄弱的环节那么弱——您混淆得越多,窃取您的 IP 就越困难。

编辑

我使用 Flex 混淆工具的经验是,您必须对混淆进行大量调整才能获得所需的内容。简单地告诉混淆软件重命名所有变量、类等必然会破坏您的应用程序,除非它真的非常简单。因此,您必须选择要混淆和调整各种其他参数的包和类,以获得有效的应用程序。

但在我看来,一旦它被混淆了,就很难破译了。这是一个示例,只是为了获得一个视角:

alt text

Key theft is probably out. If someone is dedicated to it, they will find a way, despite obfuscation, to get at the key.

Code protection & IP is another matter. Here obfuscation and "encryption" (i.e. whatever is done to prevent decompilers from functioning properly) are valid methods. If your code is sufficiently obfuscated it would be very hard for competitors to steal it or to learn too much about your code's internals. It's just not feasible. Heck, trying to learn someone else's code is hard enough as it is, and so trying to decipher code that looks like loc_12312++; if (loc_23423) loc_4345(); is just not worth anybody's time.

I strongly recommend that if you care about the IP in your application's design and internal workings, you use a tool like SecureSWF to obfuscate the code as much as you can. Unlike with license keys, here the protection isn't as weak as its weakest link - the more you obfuscate the harder you make it to steal your IP.

Edit

My experience with Flex obfuscation tools is that you have to tweak the obfuscation quite a lot to get what you need. Simply telling the obfuscation software to rename all variables, classes, etc. is bound to break your application, unless it's really really simple. So you have to choose which packages and classes to obfuscate and tweak various other parameters in order to get a working application.

Once it's obfuscated though, it's pretty hard to decipher, in my opinion. Here's a sample, just to get a perspective:

alt text

浅浅 2024-10-16 17:47:27

我会重新考虑您在 SWF 中放入的内容。不过,如果您没有看到其他选项,NitroLM 有一个 SWF 加密器,可以让您加密 SWF。 Sharify 是一种替代服务。

理论上,您可以编写自己的 SWF 加密机制和您自己的“EncryptedSWFLoader”。当然,我怀疑 SWF 中的任何键很可能都是您需要发送回服务器的内容;与解密 SWF 相比,让某人使用 ServiceCapture 或 Charles 等工具嗅探数据包更有可能成为“密钥泄露”的根源。

I'd rethink what you're putting in the SWF. But that said, if you see no other options, NitroLM has a SWF encrypter which allows you to encrypt the SWF. Sharify is an alternative service.

In theory you could write your own mechanism for encrypting a SWF and your own "EncryptedSWFLoader." Of course, I suspect that any key in the SWF will most likely be something you need to send back to a server; and having someone sniff the packets--with a tool such as ServiceCapture or Charles--is more likely to be a source of "key leakage" than decrypting the SWF.

陈甜 2024-10-16 17:47:27

您不会获得真正的安全性,但要使反编译变得更加困难,请使用代码混淆工具,例如 doSWF ,和/或将重要数据存储为字节数组。

You won't get real security, but to make decompilation a little harder, use a code obfuscation tool, like doSWF, and/or store important data as byte array.

揽月 2024-10-16 17:47:27

编辑:忽略此答案:没有发现“分发”部分 **

如果从网络服务器运行,您可以将安全密钥存储在文本中文件,然后从资产文件夹中将此文本文件读入 swf(使用 urlLoader)。如果您不设置公共权限,人们将无法访问资产,并且反编译的 swf 将不具有该值(仅具有变量名称)。

它是如何分配的?

Edit: Ignore this answer: didnt spot the 'distributing' part **

If run from a webserver you can store your secure key in a text file, and read this text file into the swf from an assets folder (using urlLoader). People wont be able to get to the assets if you dont set public permissions, and the decompiled swf wont have that value (will just have a variable name).

How is it being distributed?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文