我不确定术语是否正确您可以使用哪些代码实践来使某人难以修改二进制/程序集以绕过检查:
例如在源代码中。
bool verificationResult = verify();
if (verificationResult){
allow_Something();
}else{
prevent_Something();
}
如果查看上述代码的反汇编版本的人可以修改'jump opcodes(?)'以运行allow_Something,即使验证结果为false也是如此。
这里介绍了类似的东西 http://www.codeproject.com/Articles/18961/Tamper-Aware-and-Self-Healing-Code#pre0
注意我正在用C ++创建二进制文件,以便在Android上通过NDK使用它。
答案 0 :(得分:6)
由于普遍的共识是到目前为止,不可能阻止任何人一心想要“破解”你的APK。混淆技术只会增加“破解”APK一次所需的复杂性。在它上传到无数的免费提供主机APK的网站之后,它只是远离Android noob的“noob-est”的谷歌搜索。
另外security through obscurity将NOT get you far。
关于保护您的APK免遭黑客入侵,我建议您阅读以下讨论license validation of APKs on Android当前状态的文章。其中描述的技术应该让您了解需要防范的常见攻击媒介。
Proguard是一个开始obfuscating your APK的好地方。
在您设法获得混淆的APK之后,请通过以下工具运行它并观察解压缩的源代码。所有这些都是免费和开源的工具,非常受欢迎,肯定是任何体面的“破解者”将尝试的第一件事:
1. baksmali
2. apktool
3. Dex2Jar + JD-Gui
继续在代码中添加模糊层,直到您确信上述工具的输出相当复杂才有意义。 (再一次不要低估大学毕业生拿着可乐,比萨饼和 the knowledge of DVM opcodes 可以在一个周末完成的事情。
关于您分享的link中讨论的技术,我无法了解如何实施这些技术来保护Android上的 .dex
。如果您最终在单独的 .so
中实施验证逻辑,那么所有“破解者”需要做的就是将您的java代码中的调用修补到内部的verify()函数中的 .so
强>
<强>更新强>
保护 .so
的其他模糊处理步骤。
<强> 1。不要遵循或多或少的线性路径。
在整个地方添加额外的跳转工作的方法是将“破解者”淹没在如此多的潜在目标中,这些目标需要单独修改并修补并验证是否已绕过保护。
<强> 2。添加时间检查 这主要是通过在调试和实际运行时使代码遵循不同的路径来摒弃“破解者”。如果在两点之间花费的时间比平常多得多,则表明您的程序正在被调试。即是时候跳进那个计算世界钢琴数量的垃圾代码部分。
第3。编写自修改代码
这再一次阻碍了静态分析。例如,如果跳转进入验证函数,则二进制文件中不存在,但作为 .so
中某些init()函数的一部分进行修补。< / p>
所有上述技术(及更多)都在以下 anti-debugging techniques 的文章中举例说明。
答案 1 :(得分:1)
避免使用过于透明的检查。尝试一些基本的工作流程混淆(例如XOR-ing结果),这可以帮助防止简单的操作码替换。但我向你保证,如果有人想(非常非常)破解你,无论你的保护多么复杂,他都可以做到。
答案 2 :(得分:1)
Dexguard是由做过Proguard的人做的,但它允许更细粒度的选项。也就是说,Proguard或多或少是Android混淆的行业标准。但是,如上所述,如果拥有专有技术的人想要破解你的应用程序,那么就没有保护可以获得爱情或金钱。
答案 3 :(得分:1)
简单的道理:你做不到。
您可以购买实用程序来混淆您的目标代码,但任何略有动机的攻击者都可以轻易绕过它们。如果您的用户可以写入程序映像(在磁盘或内存中),则无需进行任何模糊处理。
如果它非常重要,我建议将重要组件移动到您控制的设备,并提供某种形式的质询 - 响应代码来访问它。它不会阻止人们破解它,但它可以对它提出更大的障碍。