MASTG-TEST-0046: 测试反调试检测

此测试即将更新

此测试目前可使用，但将作为新的 OWASP MASTG v2 指南的一部分进行全面修订。

请通过提交 PR 来帮助我们：MASTG v1->v2 MASTG-TEST-0046：测试反调试检测 (android)

绕过调试器检测¶

没有通用的绕过反调试的方法：最好的方法取决于用于阻止或检测调试的特定机制以及整体保护方案中的其他防御措施。例如，如果没有完整性检查或者您已经禁用了它们，那么修补应用程序可能是最简单的方法。在其他情况下，hook 框架或内核模块可能更可取。以下方法描述了绕过调试器检测的不同方法

修补反调试功能：通过简单地用 NOP 指令覆盖它来禁用不需要的行为。请注意，如果反调试机制设计良好，则可能需要更复杂的补丁。
使用 Frida 或 Xposed 在 Java 和本机层 hook API：操作诸如 isDebuggable 和 isDebuggerConnected 之类的函数的返回值以隐藏调试器。
更改环境：Android 是一个开放的环境。如果其他方法都不起作用，您可以修改操作系统以破坏开发人员在设计反调试技巧时所做的假设。

绕过示例：Android Level 2 的 UnCrackable App¶

在处理混淆的应用程序时，您经常会发现开发人员故意将数据和功能“隐藏”在本机库中。您可以在 Android UnCrackable L2中找到一个例子。

乍一看，这段代码看起来像是之前的挑战。一个名为 CodeCheck 的类负责验证用户输入的代码。实际的检查似乎发生在 bar 方法中，该方法被声明为本机方法。

package sg.vantagepoint.uncrackable2;

public class CodeCheck {
    public CodeCheck() {
        super();
    }

    public boolean a(String arg2) {
        return this.bar(arg2.getBytes());
    }

    private native boolean bar(byte[] arg1) {
    }
}

    static {
        System.loadLibrary("foo");
    }

请参阅 GitHub 中Android Crackme Level 2 的不同建议解决方案。

有效性评估¶

检查反调试机制，包括以下标准

附加 jdb 和基于 ptrace 的调试器失败或导致应用程序终止或发生故障。
多种检测方法分散在应用程序的源代码中（而不是全部位于单个方法或函数中）。
反调试防御在多个 API 层（Java、本机库函数、汇编程序/系统调用）上运行。
这些机制在某种程度上是原创的（而不是从 StackOverflow 或其他来源复制和粘贴的）。

努力绕过反调试防御并回答以下问题

这些机制可以很容易地被绕过吗（例如，通过hook单个 API 函数）？
通过静态和动态分析识别反调试代码有多困难？
您是否需要编写自定义代码来禁用防御措施？您需要多少时间？
您对绕过这些机制的难度的主观评估是什么？

如果缺少反调试机制或太容易绕过，请根据上述有效性标准提出建议。这些建议可能包括添加更多检测机制以及更好地将现有机制与其他防御措施集成。