admin/rom-course
1
0
Fork 0
mirror of https://github.com/feicong/rom-course.git synced 2025-11-05 10:23:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

第11章优化

Browse Source
This commit is contained in:
dqzg12300 2023-05-20 21:23:06 +08:00
parent 9ca20df7d1
commit b8f0fc5a4b
1 changed files with 9 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
chapter-11/README.md
View File

@ -270,16 +270,16 @@ $ frida -U -p 27507
围绕常见的反调试技术，都有相应的反反调试，也就是反调试绕过技术方案。
1. Hook技术
Hook技术是一种常见的反调试绕过方案。它可以修改目标进程的内存数据与代码，绕过应用程序的反调试技术。Hook技术在程序运行时替换函数的实现，从而绕过应用程序的反调试技术。例如，使用Frida注入程序，然后修改进程的调试标志读取接口，修改返回的内容，即可完成自身的调试标志检测。
1. `Hook`
`Hook`是一种常见的反调试绕过方案。它可以修改目标进程的内存数据与代码，绕过应用程序的反调试技术。`Hook`技术在程序运行时替换函数的实现，从而绕过应用程序的反调试技术。例如，使用`Frida`注入程序，然后修改进程的调试标志读取接口，修改返回的内容，即可完成自身的调试标志检测。
2. 内存修改技术
2. 内存修改
内存修改技术是一种常见的反调试绕过方案，它可以让黑客修改应用程序的内存，从而绕过应用程序的反调试技术。例如，可以使用内存修改工具来修改应用程序的内存，从而绕过应用程序的反调试技术。
3. 反编译技术
反编译技术是一种常见的反调试绕过方案，通过分析App程序的代码，反编译修改掉代码中的反调试检测逻辑部分，从而绕过应用程序的反调试技术。这种技术需要对目标程序进行大量的分析工作，结合多个工具执行反编译与重打包，在安卓安全技术相对不成熟的时期，这种方案被大量使用。目前，使用Hook方案与系统级别反反调试技术的场景会更加普遍。
3. 反编译
反编译技术是一种常见的反调试绕过方案，通过分析`App`程序的代码，反编译修改掉代码中的反调试检测逻辑部分，从而绕过应用程序的反调试技术。这种技术需要对目标程序进行大量的分析工作，结合多个工具执行反编译与重打包，在安卓安全技术相对不成熟的时期，这种方案被大量使用。目前，使用`Hook`方案与系统级别反反调试技术的场景会更加普遍。
4. 系统级别反反调试技术
4. 系统级别反反调试
系统级别反反调试技术是一种底层的反调试绕过方案，它通过修改系统反调试相关的代码逻辑，让系统输出程序为非调试状态。这种绕过应用程序的反调试技术比较稳定，且不易被检测，是一种常用的反反调试技术。
@ -288,36 +288,7 @@ Hook技术是一种常见的反调试绕过方案。它可以修改目标进程
​ 了解常见的反调试检测后，就可以对其进行修改，这些修改并不会完美解决反调试的所有问题，主要是处理掉一些常规的检测办法。来尽量减少分析成本。下面开始简单的对几种检测方式进行修改处理。
### 11.3.1 过系统调试检测接口检测
​ 然后修改属性`ro.debuggable`的值，让其固定显示为0，修改文件`build/make/core/main.mk`，修改代码如下。
```
# ADDITIONAL_SYSTEM_PROPERTIES += ro.debuggable=1
ADDITIONAL_SYSTEM_PROPERTIES += ro.debuggable=0
```
​ 函数`__android_log_is_debuggable`是`AOSP`中用来快速获取`ro.debuggable`属性的，将该函数默认返回值修改为1。修改如下。
```c++
int __android_log_is_debuggable() {
return 1;
// static int is_debuggable = [] {
// char value[PROP_VALUE_MAX] = {};
// return __system_property_get("ro.debuggable", value) > 0 && !strcmp(value, "1");
// }();
//
// return is_debuggable;
}
```
这样修改后的系统代码，检测"ro.debuggable"将永远返回0，但不影响我们使用调试相关的能力。
### 11.3.2 过调试标志检测
​ 除此之外，还有多个针对调试标志检测的处理，修改内核文件`fs/proc/array.c`，修改如下。
​ 修改内核文件`fs/proc/array.c`，修改如下。
```c++
static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
@ -415,7 +386,7 @@ static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
## 11.4 集成反反调试功能
所有这些对系统的修改，都是针对不同场景反调试而产生的对应解决方案，需要重新编译系统代码。涉及内核代码的部分，需要重新编译内核，涉及framework的部分编译生成ROM。整个过程可以编写自动化操作脚本，将重复性的工作做简化处理。
​ 所有这些对系统的修改，都是针对不同场景反调试而产生的对应解决方案，需要重新编译系统代码。涉及内核代码的部分，需要重新编译内核，涉及`framework`的部分编译生成`ROM`。整个过程可以编写自动化操作脚本，将重复性的工作做简化处理。
在实践过程中，调试与反调试技术都是随时攻防的不断升级实时变化的，例如，有一些软件壳会对系统状态与接口作检测，这个时候，这里介绍的一些公开的方法可能就失效了。这种情况下，需要结合实际，使用安全分析技术，对目标程序做进一步的分析，确定其使用的反调试技术，重新调整系统文件修改点，然后编译打包测试效果。
​ 在实践过程中，调试与反调试技术都是随时攻防的不断升级实时变化的，例如，有一些软件壳会对系统状态与接口作检测，这个时候，这里介绍的一些公开的方法可能就失效了。这种情况下，需要结合实际，使用安全分析技术，对目标程序做进一步的分析，确定其使用的反调试技术，重新调整系统文件修改点，然后编译打包测试效果。