我正在写一个flash应用程序,我担心它会被反编译.为了尽量减少这种机会,我想混淆文件.
我听说过secureSWF(http://www.kindisoft.com/),他们确实列出了一些"用户评论".然而,这些都是如此乐观,以至于难以信任.没有一个悲观的评论(甚至不是例如用户界面或支持),所以有些东西告诉我他们可能不会发布所有评论.根据我的经验,即使是最好的公司也时不时会有某种批评.
那么,这里的任何逆向工程师都可以告诉我你在工作中的经验是多少 - 以及你是否设法对secureSWF混淆文件进行逆向工程？如果是这样,你需要多长时间？你会推荐这个软件吗？
非常感谢提前.
规则1:
任何有智慧和决心的人都将始终获得您的代码/密钥/源/文件/数据
您所做的一切只会增加妥协所需的潜在时间/精力
无论有没有SecureSWF,人们都会遇到麻烦吗？
一个快速的谷歌建议,没有多少尝试反编译使用secureSWF创建的SWF文件...但它们仍然必须符合编译的字节码的规范...所以它只是混淆.缺乏测试表明:
没有人真正独立测试它,因此没有任何安全价值
人们对它进行了测试,非常有效,人们没有发布结果
我认为前者更有可能.如果您说Flash应用程序的功能,那么这些点可能更具体.
我会寻找与释放后这些事情被逆转多久而不是系统本身的安全性(这是无关紧要的)有关的数据来源.
同时确保使您的源安全(而不是与社区合作)是最佳策略,因为在某些时候,坚定的头脑将能够访问您的逻辑.
从商业角度来看,你的战略地位不应该让你的逻辑陷入困境......因为这是徒劳的.你可以像你想要的那样专有......但人们会绕过它(只要问游戏行业).严厉的安全措施导致反弹(见DRM).
如果您确信您的应用程序如此惊人以至于人们会努力扭转它,那么寻找另一个价值主张.
Flash就是其中之一,比如JavaScript,你只能做很多事情,这真的很重要吗？没有链中其他链接的应用程序逻辑有什么用？
无论如何,寻找所需的努力来扭转编码而不是软件客户端的感知强度.
无论如何,祝你好运!
免责声明:我为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的相同规则.考虑以下:
// 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:...
现在想象一下,应用于你的所有代码.每次都以不同的方式.我要求进一步声称反向工程SWF文件变得像本机代码一样难.我说它变得更难了.
但这可能吗？当然如此.如果你有一些如此重要的东西,攻击者会遇到所有这些麻烦,那么绝对不应该在可能充满敌意的环境(客户端)中执行.虽然它有所帮助,但混淆不应主要被视为安全措施.有关更多信息,请访问:http: //en.wikipedia.org/wiki/Security_through_obscurity
其他替代方案包括保持敏感代码在服务器上运行和加密.服务器端编码并不总是可行的.在许多情况下,您确实需要在客户端上运行代码.加密更糟糕,解密必须在客户端上进行,您必须将解密代码和密钥发送给客户端,不留任何东西以防止攻击者自己解密代码.
我希望我提供足够的技术内容来支持我的观点.现在回到无耻的营销:).下载演示版并自行测试.除了我们留在处理过的文件上的水印之外,它没有时间限制并且功能齐全.由于我们在论坛和stackoverflow.com上寻求帮助,我们的技术支持服务肯定超出预期;)
有关更多信息,请访问:http: //www.kindisoft.com/secureSWF/faq.php
我没有丰富的混淆器经验,但几个月前我被要求尝试一些特定的项目(实际上是一个简单的 - 多人游戏).我试过SecureSWf和Amayeta SWFEncript(两个试用版,如果我没记错的话,它们都是完全正常的).
两者都有更多"高级"功能的问题.如果我只选择重命名标识符,那么事情就会顺利进行.但即使使用默认设置(最小控制流混淆),其中一个混淆器也会生成非法字节码,即播放器的验证者会拒绝它.这产生了一个例外,就是它.我真的不记得是哪一个,但是当你运行swf时它就失败了.
我没有进一步测试,但它让我发现这是你必须考虑的事情.使用此工具需要额外付费.它可以接受或不接受你的目的,但你应该考虑到它.一旦你改变并扭曲你的swf,它就不再是你已经调试和测试的swf了.所以,现在你将有两倍的工作测试,因为混淆器有可能引入了bug.我看到的那个非常明显,并立刻吹响了球员,但可能会有更微妙,更难的球员.如果你碰巧有一个只在你的"安全"版本中显示的错误(或者更糟糕的是,它看起来只发生在你的安全版本中,但你并不积极),调试它将不会很有趣.
当然,这不是一个适当的评论,只是我有限的经验.大多数混淆器都有免费试用,所以你可以自己尝试一下.而且我还应该说,反编译和反汇编的代码很好,非常混淆,并且从中理解它将是一项艰巨的任务.
然而,我认为我会添加一个不同的视角,这是不经常提到的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 