add some true blogs & mv resources

Author: RocketMaDev

source/_posts/dasx0rays2024/WhereIsMySauce.md

@@ -5,6 +5,7 @@ updated: 2024/10/23 19:03:00
 tags:
     - tricks
 sticky: 90
+thumbnail: /assets/dasx0rays2024/debuginfod.png
 ---
 <!-- excerpt -->
 

source/_posts/trueblog/hello-world.md source/_posts/hello-world.md

@@ -5,15 +5,15 @@ updated: 2024/7/25 12:34:56
 tags:
     - tricks
     - not-ctf
-thumbnail: /assets/gdbWithCode.png
+thumbnail: /assets/trueblog/gdbWithCode.png
 ---
 
 <!--excerpt-->
 
 自从做pwn题以来，一直有一个奇怪的现象，当我调试程序时，遇到libc中的函数就会显示源代码，
 但是一旦patchelf了以后Pwndbg就无法显示源代码了
 
-![source code shown](/assets/gdbWithCode.png)
+![source code shown](/assets/trueblog/gdbWithCode.png)
 
 {% note %}
 注：笔者使用Arch Linux
@@ -47,7 +47,7 @@ ln -s "$LIBC/.debug" .
 同时`info share`显示libc.so.6的调试符号是缺失的，哪怕是执行了`set debug-file-directory $LIBC/.debug`，
 亦或是`set debug-file-directory $LIBC/.debug/.build-id`之后
 
-![no debugging symbols](./assets/gdbWithoutDbg.png)
+![no debugging symbols](/assets/trueblog/gdbWithoutDbg.png)
 
 {% note info fa-circle-arrow-right %}
 事实上`set debug-file-directory $LIBC/.debug`是可以加载调试符号的，但***必须***在程序启动前或附加上去前设置
@@ -74,7 +74,7 @@ ln -s "$LIBC/.debug" .
 
 Pwndbg已经自动在~/.gdbinit中写入`set debuginfod enabled on`，此时调试题目，gdb就会自动根据patch的libc下载debuginfo了
 
-![now we have debugging symbols](./assets/gdbWithDbg.png)
+![now we have debugging symbols](/assets/trueblog/gdbWithDbg.png)
 
 有读者可能会问：源码呢？源码还是没下成功啊？很遗憾，ubuntu的debuginfo并不提供源码，
 以下话转自[官网](https://ubuntu.com/server/docs/about-debuginfod)

source/_posts/trueblog/debuginfod.md

@@ -6,7 +6,7 @@ tags:
     - tricks
     - Windows
     - not-ctf
-thumbnail: /assets/success.png
+thumbnail: /assets/trueblog/success.png
 ---
 
 <!--excerpt-->
@@ -30,13 +30,13 @@ pacman -S mingw-w64-ucrt-x86_64-python-pygments
 
 然后又出bug了：
 
-![锟斤拷烫烫烫](/assets/gbk.png)
+![锟斤拷烫烫烫](/assets/trueblog/gbk.png)
 
 怎么锟斤拷都出来了？？于是我就设置了gdb的选项`host-charset`, `target-charset`, `target-wide-charset`,
 `charset`都为`UTF-8`，还是不行，看到有人说，gdb应该读取外部的LANG环境变量来决定编码，但在Windows平台，
 还是要过一遍Windows-console，编码又变回了GBK，必须在运行gdb的时候手动把代码页设置为65001，于是我也跟着做了，
 gdb显示no context，没办法，我只能将Windows全局设为了UTF-8，终于解决了问题
 
-![configuration](/assets/conf.png)
+![configuration](/assets/trueblog/conf.png)
 
-![sucess](/assets/success.png)
+![sucess](/assets/trueblog/success.png)

source/_posts/trueblog/gdbInMsys.md

@@ -6,7 +6,7 @@ tags:
     - libc-hook
     - not-ctf
     - got-hijack
-thumbnail: /assets/disasm.png
+thumbnail: /assets/trueblog/disasm.png
 ---
 
 <!--excerpt-->
@@ -24,8 +24,8 @@ thumbnail: /assets/disasm.png
 
 于是我就在本地调了一下，也是类似有个跳表存在，不过Arch的libc不能改这一项（因为开了Full RELRO）
 
-![what is ABS?](/assets/disasm.png)
-![can not write](/assets/vmmap.png)
+![what is ABS?](/assets/trueblog/disasm.png)
+![can not write](/assets/trueblog/vmmap.png)
 
 可以看到出现跳表的位置对应源码是在`strlen`的位置，在[elixir](https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/ioputs.c#L48)中，
 原始的`puts`函数是这样的：

source/_posts/trueblog/ifuncInPuts.md

@@ -0,0 +1,51 @@
+---
+title: 看电影的学问——IMAX & Dolby Cinema
+date: 2024/10/18 17:41:00
+updated: 2024/10/18 17:41:00
+tags:
+    - not-ctf
+thumbnail: /assets/trueblog/IMAX_blue_logo.svg
+---
+<!-- excerpt -->
+
+暑假前看了流浪地球2，就算在我家的小电视上都能看出冲击感。之后在B站看深度解读的时候，
+看到评论区里都在讨论相比起球1的进步以及自己已经去电影院看了多少次了。
+这不禁让我也有了去电影院二刷的想法，当时我就随便就近挑了一家IMAX，准备寒假排片的时候去看。
+
+随后，流浪地球2 3D版预告上线了。看得早不如看得巧，计划计划我就打算和好友一起去看。
+在官方海报中，写了有IMAX、杜比影院、CINITY和CGS中国巨幕。所有的IMAX影院都一样...吗？
+
+<img src="/assets/trueblog/wandering.jpg" height="30%" width="30%">
+
+## 影院等级
+
+偶然看到了有视频推荐IMAX一代。一代？还有二代吗？继续查下去，具体来说，IMAX出过好几代，
+先是胶卷介质（国内没有），后来又出现了数字介质，分为GT, COLA, Laser XT, 氙灯等四个版本，
+这四个版本沿顺序搭建成本逐渐降低，效果也逐渐变差，氙灯在全国最多，但是其亮度看3D版本的电影完全不够；
+GT在全国只有寥寥几家，效果也最好。在杭州，最好的IMAX只有COLA (Commercial Laser)，有两家，
+一家在 **西湖文化广场** ，还配有12.1声道。还有一家 **万象城店** 就只有5.1声道了。
+
+杜比影院也是具有极佳视听效果的影院。区分于杜比全景声厅，杜比影院会有官方把控质量，
+保证放映时应用杜比视界和杜比全景声的效果（理论上），如果没有IMAX COLA影院，
+杜比影院也是个不错的选择。据查，杭州的杜比影院共有2家，相比起上文提到的IMAX COLA影院，
+离地铁站更远，算是一个小劣势。不过，根据网上的数据， **余杭万达广场店**
+的银幕大小和西湖文化广场差不多大，相信观影体验应当是不错的。 **奥体印象城店**
+暂无银幕数据。
+
+## 选择影院
+
+IMAX在淘票票等官方途径中搜影城时，不会自己写明是什么版本，只会笼统的写 *IMAX厅*，
+有混淆视听的嫌疑，而杜比影院和杜比全景声厅则是分开的，比较好看出来。
+网上有一张[表格](https://docs.qq.com/sheet/DQ3FEUUZJdklNSWJP?tab=lxy0hx)，
+统计了全国各地的IMAX和杜比影院影城可以做参考。
+
+一般来说，选择的优先级是`IMAX GT >> IMAX COLA == Dolby Cinema > IMAX Laser XT >> IMAX 氙灯`
+
+除了在线表格，也可以选择小程序来查电影院，分别是"IMAX PLUS会员中心"和"杜比Dolby
+One"，要注意的是IMAX小程序中没有写明放映技术，只会标明是"激光IMAX"（区别于氙灯），
+不会写第几代。
+
+## 参考
+
+1. [应用图片来源](https://new.qq.com/rain/a/20240812A06VZL00)
+2. [全球IMAX及其他影厅分布](https://docs.qq.com/sheet/DQ3FEUUZJdklNSWJP?tab=lxy0hx)

source/_posts/trueblog/imaxKnowledge.md

@@ -0,0 +1,317 @@
+---
+title: 优化，还是过优化？
+date: 2024/10/20 19:14:00
+updated: 2024/10/20 19:14:00
+tags:
+    - not-ctf
+---
+<!-- excerpt -->
+
+## 起因
+
+在配置tmux的时候，我希望能看到温度、充电状态和点亮，这三个属性分别存放在三个文件中：
+`/sys/class/thermal/thermal_zone0/temp`, `/sys/class/power_supply/ACAD/online`,
+`/sys/class/power_supply/BAT1/capacity`中，并配置为这样的显示效果：
+
+<img src="/assets/trueblog/tempAndBat.png" height="30%" width="30%">
+
+为了得到这样的效果，需要在`.tmux.conf`中配置一长串命令：
+`#(cut -c -2 /sys/class/thermal/thermal_zone0/temp)C #([ $(cat /sys/class/power_supply/ACAD/online) = 1 ] && echo +)#(cat /sys/class/power_supply/BAT1/capacity)%`
+
+## 开始优化
+
+这实在是太长了！为了简化一些工作，我把显示温度单独抽了出来，用C语言写了一遍
+
+```c showtemp.c
+#include <unistd.h>
+#include <fcntl.h>
+
+int main(void) {
+    char buf[3];
+    buf[2] = 'C';
+    int fd = open("/sys/class/thermal/thermal_zone0/temp", O_RDONLY);
+    read(fd, buf, 2);
+    write(STDOUT_FILENO, buf, 3);
+}
+```
+
+然后使用`gcc -O3 -s -o showtemp showtemp.c`将其编译为了elf来替换上面打印温度的部分
+
+## 继续优化
+
+一段时间后，我回看这段命令，感觉仍然有点长，然后想到动不动就两三万的pid，
+每3秒就要刷新一次，每次要起4个进程，还是太低效了。于是我直接把所有打印集成到一个程序中
+
+```c showtemp.c
+#include <string.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+int main(void) {
+    char symbol[1], buf[15];
+    int temp_fd, bat_fd, bat_info_fd;
+    int readin, padded = 0;
+
+    if ((temp_fd = open("/sys/class/thermal/thermal_zone0/temp", O_RDONLY)) < 0) {
+        memcpy(buf, "-1C ", 4);
+        padded = 4;
+    } else {
+        readin = read(temp_fd, buf, 2);
+        if (readin == 0) {
+            memcpy(buf, "??C ", 4);
+            padded = 4;
+            close(temp_fd);
+            goto next_state;
+        }
+        if (buf[1] == '\n') // following return
+            readin--;
+        memcpy(buf + readin, "C ", 2);
+        padded = readin + 2;
+        close(temp_fd);
+    }
+
+next_state:
+    if ((bat_fd = open("/sys/class/power_supply/ACAD/online", O_RDONLY)) < 0) {
+        buf[padded++] = '?';
+    } else {
+        readin = read(bat_fd, symbol, 1);
+        if (readin == 0) {
+            buf[padded++] = 'x';
+            close(bat_fd);
+        } else {
+            if (*symbol == '1') 
+                buf[padded++] = '+';
+            close(bat_fd);
+        }
+    }
+
+    if ((bat_info_fd = open("/sys/class/power_supply/BAT1/capacity", O_RDONLY)) < 0) {
+        memcpy(buf + padded, "??%", 3);
+        padded += 3;
+    } else {
+        readin = read(bat_info_fd, buf + padded, 3);
+        if (readin == 0) {
+            memcpy(buf + padded, "xx%", 3);
+            padded += 3;
+            close(bat_info_fd);
+            goto write_state;
+        }
+        if (buf[padded + readin - 1] == '\n')
+            readin--;
+        padded += readin;
+        buf[padded++] = '%';
+        close(bat_info_fd);
+    }
+
+write_state:
+    write(STDOUT_FILENO, buf, padded);
+}
+```
+
+这次我加入了这种边界判断，然后做了完善的测试，把所有打印功能集成到一个程序中，
+然而...
+
+## 陷入疯狂
+
+当我在使用gdb调试程序的时候，我看到了熟悉的动态绑定：这个每天都要被运行几千次的程序，
+还需要到ld里加载`open`等函数？疑似有点过于低效了！
+
+我用`gcc -S -o showtemp.s -O3 showtemp.c`将程序转换为汇编，然后手动把call
+`open`的地方转写为syscall，再编译：`gcc -nostdlib -O3 -s -static -o showtemp showtemp.s`
+
+继续调试，发现程序不是线性运行的，因为编译器输出汇编时，分支跳转并不是按最高可能的情况输出的。
+为此，我又加入了以下代码应用于分支判断加速
+
+```c
+#define likely(cond)    __builtin_expect((cond), 1)
+#define unlikely(cond)  __builtin_expect((cond), 0)
+```
+并且给整数变量前加上了`register`声明，最后再生成为汇编，并手动syscall，
+得到了如下的汇编
+
+```asm showtemp.S
+	.file	"showtemp.c"
+	.intel_syntax noprefix
+	.text
+	.align 8
+.section .rodata
+    .equ SYS_read, 0
+    .equ SYS_write, 1
+    .equ SYS_open, 2
+    .equ SYS_close, 3
+    .equ SYS_exit, 60
+.LC0:
+	.string	"/sys/class/thermal/thermal_zone0/temp"
+	.align 8
+.LC1:
+	.string	"/sys/class/power_supply/ACAD/online"
+	.align 8
+.LC2:
+	.string	"/sys/class/power_supply/BAT1/capacity"
+	.p2align 4
+
+.section .text
+.global	_start
+_start:
+.LFB6:
+	xor	esi, esi
+	xor	eax, eax
+	lea	rdi, .LC0[rip]
+	sub	rsp, 40
+    mov eax, SYS_open
+    syscall
+	test eax, eax
+	js	.L16
+	lea	r12, 16[rsp]
+	mov	edx, 2
+	mov	edi, eax
+	mov	ebp, eax
+	mov	rsi, r12
+    mov eax, SYS_read
+    syscall
+	mov	r13, rax
+	mov	ebx, eax
+	test	eax, eax
+	je	.L17
+.L4:
+	cmp	BYTE PTR 17[rsp], 10
+	je	.L18
+.L5:
+	movsx	rax, ebx
+	mov	edx, 8259
+	mov	edi, ebp
+	add	ebx, 2
+	mov	WORD PTR [r12+rax], dx
+    mov eax, SYS_close
+    syscall
+.L3:
+	xor	esi, esi
+	lea	rdi, .LC1[rip]
+	xor	eax, eax
+    mov eax, SYS_open
+    syscall
+	mov	ebp, eax
+	test eax, eax
+	js	.L19
+	lea	rsi, 15[rsp]
+	mov	edx, 1
+	mov	edi, eax
+    mov eax, SYS_read
+    syscall
+	test	eax, eax
+	je	.L20
+	cmp	BYTE PTR 15[rsp], 49
+	jne	.L9
+	movsx	rax, ebx
+	add	ebx, 1
+	mov	BYTE PTR 16[rsp+rax], 43
+.L9:
+	mov	edi, ebp
+    mov eax, SYS_close
+    syscall
+.L7:
+	xor	esi, esi
+	lea	rdi, .LC2[rip]
+	xor	eax, eax
+	movsx	r15, ebx
+    mov eax, SYS_open
+    syscall
+	add	r15, r12
+	mov	r14d, eax
+	test eax, eax
+	js	.L21
+	mov	edx, 3
+	mov	rsi, r15
+	mov	edi, eax
+    mov eax, SYS_read
+    syscall
+	mov	r13, rax
+	mov	ebp, eax
+	test	eax, eax
+	je	.L22
+.L12:
+	lea	eax, -1[rbx+r13]
+	cdqe
+	cmp	BYTE PTR 16[rsp+rax], 10
+	jne	.L13
+	lea	ebp, -1[r13]
+.L13:
+	lea	eax, 0[rbp+rbx]
+	mov	edi, r14d
+	lea	ebx, 1[rax]
+	cdqe
+	mov	BYTE PTR 16[rsp+rax], 37
+    mov eax, SYS_close
+    syscall
+.L11:
+	movsx	rdx, ebx
+	mov	rsi, r12
+	mov	edi, 1
+    mov eax, SYS_write
+    syscall
+    xor edi, edi
+    mov eax, SYS_exit
+    syscall
+.L19:
+	movsx	rax, ebx
+	add	ebx, 1
+	mov	BYTE PTR 16[rsp+rax], 63
+	jmp	.L7
+.L21:
+	mov	WORD PTR [r15], 16191
+	add	ebx, 3
+	mov	BYTE PTR 2[r15], 37
+	jmp	.L11
+.L16:
+	mov	DWORD PTR 16[rsp], 541274413
+	mov	ebx, 4
+	lea	r12, 16[rsp]
+	jmp	.L3
+.L18:
+	lea	ebx, -1[r13]
+	jmp	.L5
+.L20:
+	lea	r13d, 1[rbx]
+	mov	edi, ebp
+	movsx	rbx, ebx
+	mov	BYTE PTR 16[rsp+rbx], 120
+	mov	ebx, r13d
+    mov eax, SYS_close
+    syscall
+	jmp	.L7
+.L22:
+	mov	WORD PTR [r15], 30840
+	mov	edi, r14d
+	add	ebx, 3
+	mov	BYTE PTR 2[r15], 37
+    mov eax, SYS_close
+    syscall
+	jmp	.L11
+.L17:
+	mov	edi, ebp
+	mov	DWORD PTR 16[rsp], 541278015
+    mov ebx, 4
+    mov eax, SYS_close
+    syscall
+	jmp	.L3
+.LFE6:
+	.ident	"GCC: (GNU) 14.2.1 20240805"
+	.section	.note.GNU-stack,"",@progbits
+```
+
+调试的时候也是成功使得程序运行时没有发生任何jmp
+
+## 回顾
+
+当我写完程序后，回过头来看花了过多的时间，因为汇编实在是晦涩难懂，
+本来我还想着把逻辑梳理一遍，最后只把call转换成syscall就草草了事。而且，
+花这么多时间来“优化”真的值得吗？本来程序运行就花不了多少毫秒，又是把程序转成汇编，
+又是加各种优化的，并不能快多少。但是不优化的话，又让我感觉自己没有尽力，
+这就是完美主义者的困扰吧。
+
+最近又看到了关于cpu分支判断的文章，原先我以为分支判断错误惩罚是遇到了需要跳转的情况，
+可事实上cpu会智能判断是否需要跳转，由此加速程序运行。考虑到优化到这种程序以后，
+程序的瓶颈已经到syscall上了，这样的优化看起来就更没必要了。
+
+就像网上说的，优化并不是以自己的范畴优化所有代码，而是重点优化影响系统运行的，
+耗时的操作，将你的时间，用在更加重要的事上吧。

source/_posts/trueblog/over-optimize.md

@@ -5,7 +5,7 @@ updated: 2024/7/30 10:53:00
 tags:
     - tricks
     - not-ctf
-thumbnail: /images/patchelfFix.png
+thumbnail: /assets/trueblog/patchelfFix.png
 ---
 
 <!--excerpt-->

source/_posts/trueblog/patchelfForZsh.md

@@ -0,0 +1,153 @@
+---
+title: Ptrace syscall 初学者常见困惑解答
+date: 2024/10/21 03:27:00
+updated: 2024/10/21 03:27:00
+tags:
+    - tricks
+    - ptrace
+---
+<!-- excerpt -->
+
+在羊城杯2024的 **Hard Sandbox** 中，有`RET_TRACE`的沙箱，因此如何构造rce并绕过限制的问题，
+就来到了如何使用ptrace上。ptrace作为Linux的syscall，已经存在很久了，相关的文档也很完善，
+具体细则可以通过`man ptrace`查看，这篇博客主要讲讲一些值得注意的点。
+
+## PTRACE_ATTACH or PTRACE_TRACEME ?
+
+attach是tracer主动发送请求到tracee，通知tracee停下来（SIGSTOP），
+使其进入能被调试的状态，而traceme则是tracee通知tracer，使tracer能够调试tracee。
+不同于attach，tracee在做traceme并不会停止，因此tracer无法进行调试，
+需要tracee做点什么，停下来，例如`raise(SIGTRAP)`。
+
+```c
+int child = fork();
+int status;
+#ifdef USE_ATTACH
+if (child) {
+    ptrace(PTRACE_ATTACH, child, 0, 0);
+    wait(&status);
+    ...
+} else {
+    while (1)
+        dosomething(); // stops immediately
+}
+#else
+if (child) {
+    wait(&status);
+    ...
+} else {
+    ptrace(PTRACE_TRACEME, 0, 0, 0);
+    raise(SIGTRAP); // without this, tracee won't stop!
+    while (1)
+        dosomething();
+}
+#endif
+```
+
+## PTRACE_ATTACH or PTRACE_SEIZE ?
+
+相比起attach，seize虽然也是主动使tracee进入被调试的状态，但是tracee不会停止，
+也就是说，tracee同样需要自行停止，tracer才能介入。seize一般用于动态监测进程操作，
+如strace，不用于调试程序，在ctf中应用相对较少。
+
+## gpt给我的答复在使用traceme时没有raise信号啊？
+
+询问gpt traceme的使用案例后，往往在tracee执行traceme后，立刻执行`exec*`系列函数，
+这是因为当发生`execve`系统调用时，在进程空间刚刚开始替换时，tracee会收到SIGTRAP，
+然后tracer就可以进行调试，在程序加载完毕前做点什么。
+
+## 如果父进程不希望调试tracee，但是tracee发出了traceme的请求并停止了会如何？
+
+例如有如下代码，运行后终端会如何响应呢
+
+```c
+#include <signal.h>
+#include <sys/ptrace.h>
+#include <stdio.h>
+
+int main(void) {
+    puts("start");
+    ptrace(PTRACE_TRACEME, 0, 0, 0);
+    raise(SIGHUP);
+    puts("end");
+}
+```
+
+随便使用一个信号使tracee停止，随后可见tracer能继续操作了，但是若使用`fg`继续运行程序，
+则程序无法继续运行，且按`Ctrl-C`无效，只能`kill -9`，
+且从`ps -aux`中可以看到tracee的状态是`t`(stopped by debugger during the tracing)
+
+相比起在终端中按`Ctrl-Z`显示"suspended"不同，suspend操作是由shell发送的，
+并且ps结果中进程状态是`T`(stopped by job control signal)，而shell并不会恢复tracee的状态。
+
+![tracerZsh](/assets/trueblog/tracerZsh.png)
+
+{% note purple fa-circle-arrow-right %}
+没有ptraceme的话，由于没有注册SIGHUP信号的处理函数，因此程序会被直接退出
+{% endnote %}
+
+## `<defunct>`是什么？
+
+当子进程结束后，父进程没有`wait`，则子进程会陷入僵尸进程的状态，会持续占用资源，
+且无法被kill，只有父进程`wait`或退出，子进程的资源才能被释放。
+
+## PTRACE的唯一性
+
+当程序已经成为tracee，且tracer还在调试时，其他进程不得附加到tracee上，
+亦即tracee和tracer是一一对应的，这也会导致子进程难以调试。具体来说，
+如果使用gdb调试，默认会自动附加到子进程上，此时trace的关系已经建立，
+子进程的traceme就会失败(EPERM)；或者gdb仍然附加在父进程上，然后tracee执行traceme后，
+gdb再attach到子进程上，那gdb就会attach失败(EPERM)。
+
+## gdb无法使用attach调试到特定的pid？
+
+这是由于权限设置问题，默认情况下，如果tracer没有CAP_SYS_PTRACE且和tracee没有任何pid上的继承关系，
+则无法attach，这时候需要通过`echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`的方式解除限制，
+当然，这么做并不安全！可能会导致恶意程序attach到系统关键进程上并读取数据等。
+
+## 题目的总体思路
+
+以下大致是参考文章中题解汇编的C代码实现
+
+```c
+#include <signal.h>
+#include <sys/ptrace.h>
+#include <sys/wait.h>
+#include <unistd.h>
+
+int main(void) {
+    int child = fork();
+    if (child) {
+        // parent
+        int status;
+        wait(&status);
+        ptrace(PTRACE_SETOPTIONS, child, 0, PTRACE_O_TRACESECCOMP);
+        do {
+            ptrace(PTRACE_CONT, child, 0, 0);
+            wait(&status);
+        } while (!WIFEXITED(status));
+        return 0;
+    } else {
+        // child
+        ptrace(PTRACE_TRACEME, 0, 0, 0);
+        raise(SIGSTOP);
+        execve("/bin/sh", NULL, NULL);
+        return 0;
+    }
+}
+```
+
+{% note yellow fa-exclamation %}
+`raise(SIGSTOP)`不可省略！虽然上文提到`execve`会使tracee收到SIGTRAP，但是在这之前，
+由于沙箱的限制，子进程会在父进程能够设置ptrace选项前退出，因此父进程不再能调试子进程。
+因此通过显式发出信号，可以让父进程有接管子进程的时间
+
+一开始我以为`fork`会使子进程从`main`函数重新开始，实际上不是的，`fork`后，
+父子进程的rip都在`fork`后的下一句话
+{% endnote %}
+
+## 参考
+
+1. [羊城杯 2024 pwn writeup#sandbox(after competition)](https://qanux.github.io/2024/08/28/%E7%BE%8A%E5%9F%8E%E6%9D%AF%202024%20pwn%20writeup/index.html#sandbox-after-competition)
+2. [Linux沙箱之ptrace](https://blog-archive.betamao.me/2019/02/02/Linux%E6%B2%99%E7%AE%B1%E4%B9%8Bptrace/)
+3. [linux下僵尸进程(Defunct进程)的产生与避免](https://zhuanlan.zhihu.com/p/356414911)