【问题标题】:Prevent/Make it difficult to patch Binary Assembly防止/使其难以修补二进制程序集
【发布时间】:2013-06-18 00:21:57
【问题描述】:

我不确定术语是否正确,您可以使用哪些代码实践来使某人难以修改二进制/程序集以绕过检查:

例如在源代码中。

bool verificationResult = verify();
if (verificationResult){
 allow_Something();
}else{
 prevent_Something();
} 

如果查看上述代码的反汇编版本的人可以修改'jump opcodes(?)'以运行allow_Something,即使验证结果为假。

这里有类似的内容 http://www.codeproject.com/Articles/18961/Tamper-Aware-and-Self-Healing-Code#pre0

注意,我正在 C++ 中创建二进制文件,以便在 Android 上通过 NDK 使用它。

【问题讨论】:

  • 如果您使用了一些确定性的通用/通用代码最佳实践,那么它可能很容易被检测和击败,并且总是调用 allow_something()
  • 您能否详细说明什么是“确定性通用/通用代码最佳实践”?
  • 您可以在加载前检查.so库的加密哈希值。但是接下来要比较什么值,是否可以保证该值的安全成为下一个问题。
  • 这只是一个题外话:为什么不将您的程序或许可证数据放在应用程序服务器上并对其进行检查?
  • Vasily - 购买服务器和为其创建应用程序的开销太大。我只是想知道是否有编码技术使修改跳转代码变得困难。我已经搜索了互联网,但没有找到。

标签: android android-ndk disassembly patch


【解决方案1】:

到目前为止,普遍的共识是,不可能阻止任何人一心想“破解”您的 APK 这样做。混淆技术只会增加一次“破解”APK 所需的复杂性。在它被上传到无数提供免费托管 APK 的网站后,它甚至只是一个谷歌搜索,甚至远离 Android 新手的“noob-est”。

还有security through obscurityNOT 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.编写自修改代码
这再次阻碍了静态分析。例如,如果您的 jump 进入验证函数在二进制文件中不存在,但作为 .so 中某些 init() 函数的一部分在各处进行了修补。

anti-debugging techniques 上的以下文章中通过示例描述了所有上述技术(以及更多)。

更全面的指南是Ultimate Anti Debugging Reference by Peter Ferrie

【讨论】:

  • 关于 >>所有“破解者”需要做的就是将您的 java 代码中的调用修补到 verify() 函数
  • @pt123 使用保护.so 的技术更新了答案。
  • 谢谢,这就是我要找的东西
【解决方案2】:

简单的事实:你不能。

您可以购买实用程序来混淆您的目标代码,但它们都会被任何稍有动机的攻击者轻易绕过。如果您的用户可以写入程序映像(在磁盘上或内存中),那么再多的混淆都无法抵御它。

如果它非常重要,我建议将重要的组件移动到您控制的设备上,并提供某种形式的质询-响应代码来访问它。它不会阻止人们破解它,但它可以设置一个更大的障碍来阻止它。

【讨论】:

    【解决方案3】:

    Dexguard 是由制作 Proguard 的同一个人创建的,但它允许更细粒度的选项。也就是说,Proguard 或多或少是 Android 混淆的行业标准。但是,如上所述,如果有专业知识的人想要破解您的应用程序,那么爱情或金钱就没有任何保护措施了。

    【讨论】:

      【解决方案4】:

      避免使用过于透明的检查。尝试一些基本的工作流混淆(例如 XOR-ing 结果),这有助于防止简单的操作码替换。但我向你保证,如果有人想要(非常非常)破解你,无论你的保护有多复杂,他都可以做到。

      【讨论】:

      • 当我在 Google 上搜索时,是否还有另一个术语“工作流混淆”我没有得到有用的结果。我只是想让它变得困难,我不希望某些脚本小子更改二进制文件中的一行来破坏保护
      • 试试 Proguard。它重命名代码中的符号,因此看不到特定方法负责某些验证。我相信,最简单的保护就足够了。
      • proguard 几乎没用,有反 LVL 工具可以轻松击败它
      • 那么,请明确您想要达到的保护级别。
      • 就像我在最初的帖子中所说的那样,我希望代码实践能够防止黑客修改我展示的代码中的跳转操作码,以绕过我使用 NDK 用 C++ 编写的验证检查
      猜你喜欢
      • 2011-05-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-09-05
      • 1970-01-01
      相关资源
      最近更新 更多