Android安全：native层反调试并绕过

最新推荐文章于 2024-09-16 19:09:48 发布

阿阿阿卡

最新推荐文章于 2024-09-16 19:09:48 发布

阅读量830

点赞数 18

文章标签： android 安全

本文链接：https://blog.csdn.net/aka_yoo/article/details/141220123

版权

0x00：前言

本篇文章会介绍如何在Android的native层添加简单的反调试代码，以及站在攻击者的角度分析该反调试的薄弱点，并进行绕过反调试。最后，会说一下个人的想法。

0x01：native层反调试

native层反调试示例代码：

#include <stdio.h>
#include <stdlib.h>
#include <jni.h>
#include <unistd.h>
#include <sys/ptrace.h>

void anti_debug() {
    if(ptrace(PTRACE_TRACEME, 0, 0, 0) == -1){
        _exit(1);
    }
}

JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
    // 只进行一次反调试检查
    anti_debug();
    return JNI_VERSION_1_6;
}

jstring Java_com_example_myapplication_Calc_print(JNIEnv *env, jobject jobj) {
    char *text = "I am from c";
    return (*env)->NewStringUTF(env, text);
}

jint Java_com_example_myapplication_Calc_addThreeNum(JNIEnv *env, jobject jobj, jint a, jint b, jint c) {
    return a + b +c;
}

在JNI_OnLoad函数中添加了反调试代码：ptrace(PTRACE_TRACEME, 0, 0, 0)。而不能在各个函数开始处添加的原因：防止多次调用函数时，多次执行反调试代码，导致程序退出。（注：当多个so同时使用该方式加固时，同样的道理，也可能存在问题）

关于PTRACE_TRACEME反调试的原理：https://blog.csdn.net/aka_yoo/article/details/140996453

0x02：反调试的效果

我先前已对未添加反调试代码的APK进行了测试，可以正常运行，也可以进行动态调试。
现在添加了反调试代码后：APK的各个功能可以正常运行，而使用jeb-demo进行动态调试时，执行这一步会退出：
在这里插入图片描述
这说明在native层所添加的反调试代码是有效的！

0x03：绕过反调试

站在攻击者的角度，一个很显然的绕过方法是：找出反调试代码并去除掉。

步骤1：找出反调试代码

通过IDA对so文件进行反编译，对汇编代码进行分析，找出需要去掉的部分。
注：这里涉及到的一个难点是，需要维持函数堆栈平衡。
在这里插入图片描述

步骤2：去除掉代码

这里说的“去除”，指的是将汇编代码改成nop（0x90）指令，即什么都不干。
使用IDA的patch功能进行修改：光标选中所需修改处，【Edit】->【patch program】-> 【change byte】。
在这里插入图片描述

所有的修改完后，保存修改：【Edit】-> 【patch program】-> 【apply patch to input file】

【create backup】选项：patch功能默认是对现有的文件上进行修改的，如果需要保留原来的文件，勾选该选项进行备份。
【Restore original bytes】选项：功能未知。不过试了勾选后，并没有修改成功，所以不清楚的话，就不要勾选。

最终修改后的样子：
在这里插入图片描述

后续步骤：

在修改so文件后，需要重打包生成APK，并加签。可参考：https://blog.csdn.net/aka_yoo/article/details/140953194
结果测试，反调试绕过的结果：APK的各个功能可以正常执行，jeb-demo可以正常对so调试。说明该绕过方法有效！

0x04：个人想法

本篇文章只是通过一小段简单的反调试代码进行了加固，但不管怎样，对native层插入代码进行加固的方法，所存在的一个绕过方法是：nop掉加固代码。这是无法避免的，那么是否代表我们所做的加固工作无意义呢？当然不是，毕竟加固是为了增加攻击者的破解难度，而不是得到一个终极的安全方案。

那么，该如何评估我们所做的加固工作的价值？个人觉得。可以比较一下攻击者绕过加固的操作是否比加固阻碍攻击者所进行的操作更加有难度。（当然，难度的判断并并不存在客观标准）如果前者明显更有难度，说明该加固是有价值的。如果不是如此，那么绕过该加固对攻击者来说是不痛不痒的，同时把我们拉入了虚假安全的梦境。

基于这个，我们可以增大难度的差距，就本篇文章来说，即提升将加固代码NOP掉的操作的难度。比如说：进行代码混淆，增加静态分析的难度。