良好的软件工程与安全性答案

【问题标题】：Good software engineering vs. Security良好的软件工程与安全性
【发布时间】：2012-02-06 13:17:29
【问题描述】：

Security and Design 指南详细介绍了各种方法，以使攻击者更难破坏应用内计费实施。

特别要注意的是，逆向工程.apk 文件是多么容易，即使是通过 Proguard 进行了混淆。因此他们甚至建议修改所有示例应用程序代码，尤其是“已知入口点和出口点”。

我发现缺少的是对将某些验证方法包装在单个方法中的任何引用，例如返回 boolean 的静态 Security.verify()：一个好的设计实践（减少代码重复、可重用、更易于调试、自记录等），但攻击者现在需要做的就是识别该方法并使其始终返回true...所以无论我使用它多少次，延迟或不延迟，随机与否，它根本没有'没关系。

另一方面，Java 没有像 C/C++ 中那样的宏，可以减少源代码重复，但没有 verify() 函数的单一退出点。

所以我的问题：

众所周知的软件工程/编码实践与所谓的安全性设计之间是否存在固有的争论？（至少在 Java/Android/安全事务的上下文中）

可以做些什么来减轻“为安全而设计”的副作用，就本可以更简单、更易于维护和更易于调试的过于复杂的软件而言，这似乎是“在脚上开枪”？

你能推荐一些好的资源来进一步研究这个主题吗？

【问题讨论】：

对于应用内我相信安全类必须是你的应用服务器。
代码混淆的价值被热议，这不是stackoverflow的用途。
@coder_For_Life22 很好的幽默感。 :) 见youtu.be/TnSNCXR9fbY
@Vincent 你是对的。我只带了Security.verify() 作为一个简单的例子。但是将验证中继到服务器并不总是更好，正如here 所描述的案例所示。
@GregS 我不知道代码混淆的价值是有争议的。我认为 Google 决定将 Proguard 与 ADT 捆绑在一起是有原因的。你能详细说明一下吗？或者提供链接？

标签： java android encryption reverse-engineering decompiling

【解决方案1】：

像往常一样，这是一个权衡。使您的代码更难逆向工程/破解涉及使其可读性降低和难以维护。您可以根据您的目标用户群、您自己在该领域的技能、时间/成本等来决定走多远。这并不特定于 Android。观看this Google I/O presentation 了解混淆和防止代码篡改的各个阶段。然后决定你愿意为自己的应用走多远。

另一方面，您不必混淆/强化等。所有您的代码，只需处理许可等的部分。这通常是非常小的一部分整个代码库，实际上并不需要经常更改，因此您可能会忍受它难以遵循/维护等。只需记下它的工作原理，以便在 2 年后提醒自己 :)。

【讨论】：

【解决方案2】：

您所描述的反生产力只是冰山一角...没有软件在发布时是 100% 没有错误的，那么当用户开始报告问题时您会怎么做？

在禁用日志记录、堆栈跟踪和各种其他有助于逆向工程师但也有助于合法开发团队的信息后，您如何解决或调试字段问题？

【讨论】：

【解决方案3】：

无论混淆方法有多难，总有一种方法可以对它们进行逆向工程。我的意思是，如果您的软件在 hakers 社区中越来越受欢迎，最终会有人尝试对其进行逆向工程。

混淆只是一种使逆向工程过程更加困难的方法。

打包也是如此。我认为有许多打包方法可用，但对它们进行逆向工程的过程也是如此。

您可以查看www.tuts4you.com，了解有多少指南可用。

我不像其他许多人一样是专家，但这是我在学习逆向工程过程中的经验。最近我也看到了很多关于 Android 应用逆向工程的指南。我什至在 nullc0n（不确定）CTF 中看到，在 Reversing Android 中有一个应用程序。如果您愿意，我可以在搜索后提及该网站。

【讨论】：