良好的软件工程与安全性
安全和设计指南详细概述了实现这一目标的各种方法攻击者更难破坏应用内计费实施。
特别值得注意的是，即使通过 Proguard 进行了混淆，对 .apk 文件进行逆向工程也是非常容易的。因此他们甚至建议修改所有示例应用程序代码，尤其是“已知的入口点和出口点”。
我发现缺少的是对将某些验证方法包装在单个方法中的任何引用，例如返回布尔值的静态 Security.verify() ：良好的设计实践（减少代码重复、可重用、更容易调试、自记录等），但攻击者现在需要做的就是识别该方法并使其始终返回 true...所以无论我多少次使用它，延迟或不延迟，随机或不随机，它只是没关系。
另一方面，Java 没有像 C/C++ 那样的宏，可以减少源代码重复，但没有 verify() 函数的单个退出点。
所以我的问题是：
众所周知的软件工程/编码实践和所谓的安全性设计之间是否存在固有的争论？ （至少在 Java/Android/安全交易的背景下）
可以采取哪些措施来减轻“安全设计”的副作用，就过于复杂的软件而言，这似乎是“搬起石头砸自己的脚”是否更简单、更易于维护、更易于调试？
您能推荐进一步研究该主题的好资源吗？
The Security and Design guidelines go to great length outlining various methods to make it more difficult for an attacker to compromise in-app billing implementation.
Especially noted is how easy it is to reverse-engineer a .apk file, even if obfuscated via Proguard. So they even recommend modifying all sample application code, especially "known entry points and exit points".
What I find missing is any reference to the wrapping certain verification methods in a single method, like the static Security.verify() which returns boolean: A good design practice (reducing code duplication, reusable, easier to debug, self-documenting, etc.) but all an attacker needs to do now is identify that method and make it always return true... So regardless how many times I used it, delayed or not delayed, randomly or not, it simply doesn't matter.
On the other hand, Java doesn't have macros like in C/C++, which allows reducing source code duplication, but doesn't have a single exit point for a verify() function.
So my questions:
Is there an inherent contention between the well known software engineering/coding practices and design for so called security? (in the context of Java/Android/secure transactions at least)
What can be done to mitigate the side-effects of "design for security" which seems like "shooting oneself in the foot" in terms of over-complicating software that could have been simpler, more maintainable and easier to debug?
Can you recommend good sources for further studying this subject?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
像往常一样，这是一个权衡。让你的代码更难逆向工程/破解涉及到降低它的可读性和更难维护。您可以根据您的目标用户群、您自己在该领域的技能、时间/成本等来决定走多远。这并不是 Android 特有的。观看此 Google I/O 演示，介绍了混淆和使代码防篡改的各个阶段。然后决定您愿意为自己的应用程序走多远。
另一方面，您不必混淆/强化等。所有代码，只需处理许可等的部分。这通常是整个代码库的一小部分并且并不需要经常更改，因此您可能可以忍受它难以遵循/维护等。只需保留一些关于它如何工作的笔记，以便您在 2 年后提醒自己:)。
As usual, it's a tradeoff. Making your code harder to reverse-engineer/crack involves making it less readable and harder to maintain. You decide how far to go, based on your intended user base, your own skills in the area, time/cost, etc. This is not specific to Android. Watch this Google I/O presentation for various stages of obfuscating and making your code tamper resistant. Then decide how far you are willing to go for your own apps.
On the other hand, you don't have to obfuscate/harden, etc. all of your code, just the part that deals with licensing, etc. That is usually a very small part of the whole codebase and doesn't really need to change that often, so you could probably live with it being hard to follow/maintain, etc. Just keep some notes on how it works, so you remind yourself 2 years later :).
您所描述的反生产力只是冰山一角...没有软件在发布时是 100% 无错误的，那么当用户开始报告问题时您会做什么？
在禁用日志记录、堆栈跟踪和各种其他有助于逆向工程但也有助于合法开发团队的信息后，如何解决或调试现场问题？
The counter productivity you are describing is the tip of the iceberg... No software is 100% bug-free on release, so what do you do when users start reporting problems?
How do you troubleshoot or debug field problems after you disabled logging, stack tracing and all kinds of other information that help reverse-engineers but also help the legitimate development team?
无论混淆方法有多困难，总有一种方法可以对其进行逆向工程。我的意思是，如果你的软件在黑客社区中更受欢迎，最终有人会尝试对其进行逆向工程。
混淆只是使逆向工程过程变得更加困难的一种方法。
打包也是如此。我认为很多打包方法都是可用的，但对其进行逆向工程的过程也是如此。
您可以查看 www.tuts4you .com 查看有多少可用指南。
我不像很多人一样是专家，但这是我学习逆向工程过程中的经验。另外最近我看到了很多Android应用程序逆向工程的指南。我什至在 nullc0n （不确定）CTF 中看到，Reversing Android 中有一个应用程序。如果您愿意，我可以在搜索后提及该网站。
However tough the obfuscation methods are, there is always a way to reverse engineer them. I mean, if your software gets more popular among the hakers community, eventually someone will try to reverse-engineer it.
Obfuscation is just a method to make the process of reverse engineering tougher.
So is packing. I think many packing methods are available, but so is the process to reverse-engineer them.
You can check the www.tuts4you.com to see how tons of guides are being available.
I am not an expert like many others, but this is my experience in the process of learning reverse-engineering. Also recently I have seen a lot of guides for Android applications reverse-engineering. I have seen even in nullc0n (not sure) CTF, there was an app in Reversing Android. If you want, I can mention the site after searching.