我不确定术语是否正确您可以使用哪些代码实践来使某人难以修改二进制/程序集以绕过检查:
例如在源代码中.
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使用它.
解决方法:
至于普遍的共识是迄今为止,不可能阻止任何人一心想要“破解”你的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代码中的调用修补到.so中的verify()函数.
更新:
额外的混淆步骤来保护.so.
1.不要遵循或多或少的线性路径.
在整个地方添加额外的跳转工作是通过充斥“裂解器”与许多潜在目标,需要单独修改和修补并验证是否已绕过保护.
2.添加时间检查
这主要是通过在调试和实际运行时使代码遵循不同的路径来摒弃“破解者”.如果在两点之间花费的时间比平常多得多,则表明您的程序正在被调试.即时间跳入计算世界钢琴数量的垃圾代码部分.
3.编写自修改代码
这再一次阻碍了静态分析.例如,如果您在二进制文件中不存在跳转到验证函数,但作为.so中某些init()函数的一部分被修补.
以下文章(anti-debugging techniques)中的示例描述了所有上述技术(以及更多).
更全面的指南是Ultimate Anti Debugging Reference by Peter Ferrie.