我不确定术语是否正确，您可以使用哪些代码实践来使某人难以修改二进制/程序集以绕过检查：
例如在源代码中。
bool verificationResult = verify();
if (verificationResult){
allow_Something();
}else{
prevent_Something();
}
如果查看上述代码的反汇编版本的人可以修改“跳转操作码（？）”以运行allow_Something，即使验证结果为假。
此处介绍了类似的内容 http://www.codeproject.com/Articles/18961/Tamper-Aware-and-Self-Healing-Code#pre0
请注意，我正在 C++ 中创建二进制文件，以便通过 Android 上的 NDK 使用它。
到目前为止，普遍的共识是，不可能阻止任何人一心想“破解”您的 APK 这样做。混淆技术只会增加一次“破解”APK 所需的复杂性。在它被上传到无数提供免费托管 APK 的网站后，它只是一个谷歌搜索，甚至远离 Android 新手的“noob-est”。
此外，通过默默无闻的安全性不会让你走得太远。
关于保护您的 APK 免受黑客攻击，我建议您阅读以下文章，讨论Android 上 APK 的许可证验证的当前状态。其中描述的技术应该让您了解需要防范的常见攻击向量。
在您设法获得混淆后的 APK 后，请通过以下工具运行它并观察反编译的源代码。所有这些都是非常流行的免费和开源工具，并且肯定是任何体面的“破解者”都会尝试的第一件事：
1. baksmali
2. apktool
3. Dex2Jar + JD-Gui
继续为您的代码添加混淆层，直到您对上述工具的输出相当复杂而有意义为止感到满意。（同样不要低估一个拥有可乐、披萨和DVM 操作码知识的大学毕业生在一个周末可以完成的工作）。
关于您共享的链接中讨论的技术，我看不到如何实施它们来保护.dexAndroid 上的。如果你最终在一个单独的地方实现了验证逻辑，.so那么所有“破解者”需要做的就是将你的 java 代码中的调用修补到.so.
更新：
额外的混淆步骤来保护.so.
1. 不要遵循或多或少的线性路径。
在整个地方添加额外的跳转可以通过将大量潜在目标淹没“破解器”来工作，如果保护已被绕过，则需要单独修改、修补和验证这些目标。
2. 添加时序检查 这主要是通过使代码在调试和实际运行时遵循不同的路径来摆脱“破解者”。如果两点之间花费的时间比平时多得多，那么它清楚地表明您的程序正在调试。即是时候跳入计算世界上钢琴数量的那部分垃圾代码了。
3. 编写自修改代码
这再次阻碍了静态分析。例如，如果您跳转到验证函数在二进制文件中不存在，但作为.so.
所有上述技术（以及更多）都在以下关于反调试技术的文章中通过示例进行了描述。
避免使用过于透明的检查。尝试一些基本的工作流混淆（例如 XOR-ing 结果），这有助于防止简单的操作码替换。但我向你保证，如果有人想（非常非常）破解你，他可以做到，不管你的保护有多复杂。
Dexguard是由制作 Proguard 的同一个人制作的，但它允许更细粒度的选项。也就是说，Proguard 或多或少是 Android 混淆的行业标准。但是，如上所述，如果有专业知识的人想要破解您的应用程序，那么对于爱情或金钱就没有任何保护措施。
一个简单的事实：你不能。
您可以购买实用程序来混淆您的目标代码，但它们都会被任何稍有动机的攻击者轻易绕过。如果您的用户可以写入程序映像（在磁盘上或内存中），那么再多的混淆都无法抵御它。
如果它非常重要，我建议将重要的组件移动到您控制的设备上，并提供某种形式的质询-响应代码来访问它。它不会阻止人们破解它，但它可以为它设置一个更重要的障碍。