-
-
[原创]【从源码过反调试】二、过PTRACE_TRACEME
-
2022-10-10 17:10
-
PTRACE_TRACEME 反调试
原理有两条
反调试先附加自己，防止其他ptrace附加。
反调试后附加自己失败，则被其他ptrace附加
其实就这样：
1 2 3 4 | if (ptrace(PTRACE_TRACEME,...) == -1) { // exit ... } |
常见的过这个反调试是hook ptrace调用，过滤参数，返回。
我的反反调试思路也和这个差不多：
伪造ptrace(PTRACE_ME,...)的返回值为0，这样
反调试先附加自己，以为自己附加成功了，实际上失败了，我们调试器可以附加上。
反调试后附加自己，以为自己附加成功了，实际上他失败了，所以认为没有其他ptrace附加。
这也就骗过了反调试。
可修改源码的情况下，这里直接return即可。
但是这样相当于禁用了全局的 ptrace 的PTRACE_TRACEME功能， 有没有其他影响我还没有发现，目前还没遇到有问题的地方，后面遇到的话打算在这里加个pid筛选功能，只针对特定进程开启过滤。
和这帖子的方法有异曲同工之处，也是自己改完想学学大佬的方法，才发现的。比较下来，还是感觉改系统源码这种方式一劳永逸，但也学习了大佬的思路。（如果没有破坏稳定性的话）
https://bbs.pediy.com/thread-212404.htm
如果有其他方式调用，绕过了这种反反调试，还是可以在ptrace_traceme函数内部直接return的
[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界
|
|
|---|---|
|
|
|
|
|
感谢指点，进程第一次attach自己返回成功，之后再attach自己，若再attach前已detach则本次attach返回成功，若未detach则返回失败。基于这个思路，并且尽可能的少改源码，我维护了两个全局变量，一个是上次traceme的进程task指针，一个是判断是否detach。原理： 未detach 连续ptraceme，若取得的task指针相同，说明连续attach自己，所以第一次ptraceme返回0，后面一直返回-1 若detach ptraceme后detach，则下次ptraceme后，还让其返回成功。 对于单进程traceme可以过反调试，但存在“A进程traceme，再B进程traceme，再A进程traceme，会绕过这种反反调试”所以更合适的办法是维护一个动态数组，保存{进程、调用traceme状态、调用detach状态}，根据不同状态返回不同值。 但实现起来稍复杂，还没摸清内核的c语言能用哪些已经内置的数据机构，担心破坏系统稳定性，后面遇到可以再写。
最后于 2022-10-11 11:44
被xxxlion编辑
，原因：
|
|
|
|
|
|
这个考虑到了，有方式过，我现在手头没试验环境，验证ok了的话 下篇帖子发。 |
|
|
无论是用cat命令 还是用fopen打开文件 最后都会调用到open函数，可以在open.c中。过滤掉proc status字符串，发现打开文件直接return -1。 现在我担心的主要是 1：是否会有性能问题 2：无法打开这个文件，是否会破坏系统稳定性 等我验证后再下篇帖子详细说明 |
|
|
|
|
|
既然是要改内核源码，那肯定要做到一劳永逸的过检测。 1：设定启动时机，在一个进程启动早期，记录它所有fork的进 程pid，对这些pid 的ptrace行为，伪造出无论traceme和是守护进程都无法检测出的方案。 2：ptrace 黑名单或者白名单，我的下一篇文章给系统增加syscall，传给pid就是为此做铺垫的。只允许特定进程ptrace，其余进程一律直接返回失败，或者只不允许特定进程ptrace。 2：去掉ptrace内部的锁，允许多个进程附加到同一个进程上。这个我觉得可能比较有意思。如果ptrace附加只是为了读写内存 不调试的话，感觉没有问题。调试的话需要再看看怎么处理 |
|
|
|
|
|
|
|
|
不好意思帖子没看到消息，linux 5.10， 其实这些源码各个版本不会变动太多的 |
|
|
|
|
|
修改后frida可以附加hunter了 |
|
|
|
|
|
感谢感谢 |
|
|
大佬能不能把frida server分享一下 |
|
|
|
