良好的软件工程与安全性

Question

Security and Design指南详细说明了各种方法，使攻击者更难以破解应用内结算实施。

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

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

另一方面，Java没有C / C ++中的宏，它允许减少源代码重复，但没有verify()函数的单个退出点。

所以我的问题：

众所周知的软件工程/编码实践与所谓安全设计之间是否存在内在争用？ （至少在Java / Android /安全交易的背景下）

可以采取哪些措施来缓解“安全设计”的副作用，这种副作用在过于复杂的软件方面似乎“在脚下拍摄”，这些软件本来可以更简单，更易于维护，更容易调试？ / p>

您能否为进一步研究这一课题推荐合适的资源？

Answer 1

像往常一样，这是一个权衡。使代码更难以进行逆向工程/破解，这使得它的可读性降低，难以维护。您可以根据预期的用户群，自己在该地区的技能，时间/成本等来决定要走多远。这不是Android特有的。观看this Google I/O presentation以了解各种混淆阶段并使您的代码防篡改。然后决定你愿意为你自己的应用程序做多远。

另一方面，您不必混淆/强化等等所有代码，只需处理许可等部分。这通常只是一小部分整个代码库并没有真正需要经常改变，所以你可能很难接受/维护，等等。只需记下它是如何工作的，所以你提醒自己2年后:)。

Answer 2

您所描述的反制效率是冰山一角......没有软件在发布时100％无错误，那么当用户开始报告问题时您会怎么做？

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

Answer 3

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

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

这就是包装。我认为有很多包装方法可供选择，但对它们进行逆向工程的过程也是如此。

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

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