[原创]【从源码过反调试】二、过PTRACE_TRACEME

你瞒我瞒 大佬，这是那个版本的内核代码？

不好意思帖子没看到消息，linux 5.10， 其实这些源码各个版本不会变动太多的

[原创]【从源码过反调试】三、源码实现一些过检测（文件过滤，进程隐藏，notify bypass，mincore bypass）

Editor 建议若文章不是太长，尽量发同一帖里，也可以分1楼，2楼，3楼等其他楼层

5k+的字还短吗，这代码都是一行行敲出来的

[原创]【从源码过反调试】一、安卓12过IsDebuggerConnected检测

你瞒我瞒 我发现很多修改源码的帖子，都不会告诉读者他们修改的是那个系统版本的源码。头疼。

我改的是安卓12，内核5.10-168

[原创]【从源码过反调试】二、过PTRACE_TRACEME

lxcoder TracePid的话网上有很多方法，那个双进程守护的话可以从ptrace入手，ptrace里面有个task结构体，里面有pid和ppid，遍历一下，如果ptrace的主体与目标存在父子关系就返回，这样 ...

既然是要改内核源码，那肯定要做到一劳永逸的过检测。
1：设定启动时机，在一个进程启动早期，记录它所有fork的进
程pid，对这些pid 的ptrace行为，伪造出无论traceme和是守护进程都无法检测出的方案。
2：ptrace 黑名单或者白名单，我的下一篇文章给系统增加syscall，传给pid就是为此做铺垫的。只允许特定进程ptrace，其余进程一律直接返回失败，或者只不允许特定进程ptrace。
2：去掉ptrace内部的锁，允许多个进程附加到同一个进程上。这个我觉得可能比较有意思。如果ptrace附加只是为了读写内存 不调试的话，感觉没有问题。调试的话需要再看看怎么处理

[原创]【从源码过反调试】二、过PTRACE_TRACEME

残页 再升级： 先附加自己，成功后检查 /proc/self/status 里的 TracerPid 是否为自己的 pid，如果不是则该结果为攻击者伪造的

无论是用cat命令 还是用fopen打开文件 最后都会调用到open函数，可以在open.c中。过滤掉proc status字符串，发现打开文件直接return -1。
现在我担心的主要是
1：是否会有性能问题
2：无法打开这个文件，是否会破坏系统稳定性
等我验证后再下篇帖子详细说明

[原创]【从源码过反调试】二、过PTRACE_TRACEME

残页 再升级： 先附加自己，成功后检查 /proc/self/status 里的 TracerPid 是否为自己的 pid，如果不是则该结果为攻击者伪造的

这个考虑到了，有方式过，我现在手头没试验环境，验证ok了的话 下篇帖子发。

[原创]【从源码过反调试】二、过PTRACE_TRACEME

KuCha128 反调试升级：连附加自己两次，检测第一次是否成功且第二次是否失败

感谢指点，进程第一次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语言能用哪些已经内置的数据机构，担心破坏系统稳定性，后面遇到可以再写。

[求助]在覆盖了跳板地址的返回地址之后布置“shellcode header”，引导处理器跳转到位于缓冲区真正的shellcode中去，书看到这儿代码没跑起来
jmp  esp这种的操作要DEP不能开启，不知道是否开启了

[求助]ret2_libc_csu_init后int 80H错误
不止是write函数，read函数也会报错，也是这个系统调用错误