信号是用户态进程与内核进行通信的一种方式，它是陷阱（软中断）的一种。如果想要查看所有的信号类型可以查询Linux手册。

信号抵达进行需要经过两个步骤，一是发送信号，而是接收信号。

在Linux中进程的待处理的信号由task_struct结构体中的signal成员和pending成员进行记录,signal成员和pending成员的区别在于，signal成员中存放的待处理信号对整个进程组都是生效的，而pending成员只对指定的线程有效。

signal成员由signal_struct结构体定义，该结构体中的shared_pending成员是管理共享信号的主要成员，它由由sigpending结构体定义，task_struct结构体中的pending成员也由sigpending结构体定义。

sigpending结构体中的list成员指向了待处理信号队列，从下面的定义中可以看到info记录了关键的信号信息。

sigpending结构体中还可以看到一个list成员的身影，既然sigpending结构体中的list成员已经可以管理待处理信号队列了，那么sigpending结构体中的list成员又有什么用呢？

要知道，在Linux中信号分成常规信号和实时信号，这里我们需要先了解一下它们的区别。

Linux中1号 - 31号是常规信号，32号+是实时信号。它们的区别在于，同进程下同类型的常规信号只能存在一个，当常规信号被响应后，下一个同类型的常规信号才可以进入队列。

对于实时信号来讲则不是这样，同进程下可以存在多个同类型的实时信号，系统会根据实时信号在队列中的数量进行多次响应。

因此sigpending结构体中的list成员管理着不同类型的信号，此链表中的信号类型是不能重复的，sigpending结构体中的list成员管理着同类型的信号，如果有需要且信号是实时信号，那么待处理信号就会被插入sigpending结构体中的list成员对应的队列中。

通过内核驱动（见附件）指定函数和进程ID，可以将进程尚未处理的信号信息打印出来，从下面可以看到，进程收到了信号SIGTERM，SIGTERM信号的序号是15，该信号是对整个进程组生效的。

信号发送的原因可以分成三种，一是内核检测到错误发送（比如段错误，但并不是所有的错误都会导致信号产生）进而向进程组发送信号，二是主动发送信号（比如调用kill函数、alarm函数或者使用kill程序），三是外部事件触发的信号（如I/O设备、其他进程）。

通过Shell运行的进程，通过键盘输入CTRL + C或CTRL + Z可以向进程发送SIGINT或SIGTSTP信号。

进程接收到信号后，会根据信号的类型执行默认的行为（终止进程、终止进程并转储、挂起、忽略信号）。

在C语言中允许程序通过sigaction函数（更加强大，signal函数是sigaction函数的子集）设置指定信号的处理方法，而不是按照默认行为处理。

C语言提供的信号处理函数并不是所有的信号都可以处理的，比如信号SIGKILL和SIGSTOP，它们就必须执行默认行为。

有时候程序接收到信号后，我们会想要知道信号发出方的信息，因此下面给出了一种自定义信号处理函数获取发出方信息的办法。

下方直接给出了自定义信号处理操作的示例代码，代码由信号处理、全局跳转、退出处理三个部分组成。

自定义的信号处理函数会打印信号信息以及发送信息方的信息，发送方的信息被存储在my_signal_handle中的siginfo变量内。

运行程序后向程序发送SIGTERM信号后，程序出现如下的打印，从打印中可以看到程序收到信号15（对应SIGTERM），si_code为0对应着SI_USER，代表信号由用户发出，si_uid给出了该用户的用户ID，si_pid给出了发出信号的进程ID。

通过echo $$可以将kill程序运行的进程ID打印出来，该进程ID是和si_pid一致的。

当然这种方法仍然是不能处理某些信号的（如SIGKILL、SIGSTOP等等）。

此处以kill程序为例，我们通过strace工具追踪该程序产生的系统调用。

在打印的内容中可以看到，kill程序通过kill函数向内核发出__NR_kill系统调用。

内核会通过SYSCALL_DEFINE2(kill, pid_t, pid, int, sig)对__NR_kill系统调用进行接收，其中的kill_something_info函数是实际处理的信号的地方。

从kill_something_info函数中不难看出，函数由三个部分组成，它们分别是pid > 0、pid = -1、pid < 0。，当pid > 0时，发送信号给指定的进程，当pid = -1时，发送信号给自身外的其余进程，当pid < 0时，发送信号给自身作者的进程组。

这里我们重点关注pid > 0的情况。

kill_proc_info函数最终会调用__send_signal_locked函数对信号进行处理。

在__send_signal_locked函数的内部，首先会根据type变量判断是添加到给进程组还是线程（是PIDTYPE_PID时添加到线程队列），再通过__sigqueue_alloc分配一个sigqueue，然后sigqueue通过list_add_tail接口添加到task_strut中pending成员的链表内，作为待处理信号，最后将信号信息和发送方信息添加到sigqueue内。

complete_signal函数会决定由信号由谁接收。首先判断的条件是wants_signal函数，在当前任务应该接收信号时，会将接收权限交给当前进程，之后如果发现信号是发送给指定线程或单线程进程的话，就会直接返回，最后会从多线程中找到一个可用的线程。

接下来如果发现发现信号是致命的，就会通过signal_wake_up接口给每一个线程都添加上TIF_SIGPENDING标志，反之则只给指定的线程添加TIF_SIGPENDING标志。

TIF_SIGPENDING标志代表存在待处理的信号。

不管出于哪种原因发送信号，它们第一个需要的抵达的目标地点都是相同的，这个目标地点就是内核，那么内核又是如何进一步处理信号的呢？

对于内核而言，它会通过do_signal函数（它是架构指定的，具体名字可能不同）处理信号，下面通过kprobe机制中的pre_handler在arch_do_signal_or_restart函数之前打印出栈回溯（详情可见驱动代码）。

从栈回溯中可以看到，此时用户空间触发系统调用进入内核空间，当do_syscall_64函数执行完系统调用后，会调用syscall_exit_to_user_mode函数从内核空间退回到用户空间，使用arch_do_signal_or_restart函数处理信号的操作也发生在这一阶段。

exit_to_user_mode_loop函数会接收ti_work参数，该参数调用read_thread_flags接口，该接口会从thread_info结构体内读出flags成员，接收ti_work参数后，会检查TIF_SIGPENDING标志位（上面说过，待处理信号会添加该标志位），如果发现TIF_SIGPENDING标志位存在，就说明存在待处理信号此时就会调用arch_do_signal_or_restart函数。

arch_do_signal_or_restart函数响应的操作分成两部分，一是通过get_signal函数获取信号信息，二是通过handle_signal函数处理信号。

handle_signal函数首先会通过test_thread_flag函数检查TIF_SINGLESTEP标志位，该标志位用于标记程序是否被中断下来，如果标志位存在，那就会通过user_disable_single_step函数将TIF_SINGLESTEP标志位清除掉，并通知调试器。

当调试器挂载到程序后，再触发信号时，会发现调试器会先收到通知，之后才是信号处理函数，原因就在这里。

setup_rt_frame函数是一个关键操作，第一步通过get_sigframe获取一个新的栈帧。

新的栈帧通过rt_sigframe结构体描述，其中pretcode代表着信号处理完成后下一步的返回地址，uc记录了上下文信息，info记录了信号信息。

通过user_access_end结束之前的操作，可以将原始的上下文信息保存在用户态程序的栈上。

完成栈上数据的设置操作后，会继续更新用户态程序的寄存器信息，其中当前程序指针寄存器被放置了信号处理函数的地址。

我们在my_signal_handle函数进行处理时将程序中断下来观察栈回溯。

1号栈帧被内核放置了信号处理结束后的操作__restore_rt函数，这个函数非常简单，它会将系统调用号放入rax寄存器内，然后执行系统调用，系统调用号15对应着__NR_rt_sigreturn。

当__restore_rt函数触发系统调用时就会再次陷入内核当中，内核根据系统调用__NR_rt_sigreturn会触发__do_sys_rt_sigreturn函数。

该函数操作并不复杂，主要就是还原之前保存在栈上的上下文信息。

此时再次回到用户态程序后，程序就会接着执行处理信号前的内容。

在整个信号处理的过程中，内核会将上下文信息保存在用户态程序的栈上，后续再通过sigreturn系统调用发出恢复信号，因为用户态栈是可读可写的，这非常方便我们进行控制，当我么规划好sigreturn所需要的栈数据并触发sigreturn系统调用时，就会让程序跳入我们的控制之内。

那么栈上的上下文信息应该如何构造呢？

被压入栈的上下文信息通过ucontext_t结构体进行描述，ucontext_t结构体中的uc_mcontext成员内的gregs记录着信号处理函数执行前的寄存器信息。

gregs中共包含23个寄存器，下面列出了元素0到元素22对应的寄存器名。

显然当我们控制rip寄存器及传递形参的rdi等寄存器中数值时，就可以借助sigreturn的返回操作跳转到我们期望中的位置，除此之外rsp寄存器也位于栈上，当通过pop rip（如ret）操作获取下一条程序指针时，我们就可以通过控制rsp组成利用链。

程序的源代码和编译命令在下方给出了。

程序并不复杂，为了基于信号返回机制完成ROP，我们这里第一步需要构造sigreturn需要的栈，在pwntool中的SigreturnFrame接口可以直接创造一个假的栈，然后再对里面的数据进行修改。

当我们想要通过execive创建进程时，首先需要考虑的就是参数问题，由于我们需要给寄存器明确指示参数的所在位置，因此我们需要知道一个栈上的地址，并利用它作为基地址填充数据。

这个程序非常简单，因此原始的栈上只包含argc、argv、环境变量以及auxv，从argv开始任意的地址都是栈上的地址，程序读取0x400，如果我们可以越过首条指令，让rax为1，那么就可以泄露rsp+0x0到rsp+0x400范围内的数据，并轻松的得到一个栈上的地址。

rax寄存器非常好控制，它有一个特殊用途，就是保存返回值，如果我们只读取一个字节，并让程序在结束后从mov $0x400,%edx继续运行，就可以控制rax寄存器，新发送的一个字节会覆盖rsp+0x0数据的最低位字节，当rsp+0x0处原本就存储着一个程序地址，我们再发送mov $0x400,%edx对应的最低字节数据，就可以跳过xor指令。

经过上面的分析后，构造出下面的exploit。

运行exploit后成功获取Shell。

在运行调试脚本的时候发现只有打开pwntool的调试开关后，才可以正常的完成PWN，否则就会失败。

失败之前会先进入交互模式，此时不管你输入什么都会立即失败，比如这里我们直接输入了回车键，然后直接收到了SIGSEGV的崩溃错误。

观察rsp上的数据可以发现回车键对应的ASCII码0x0a被送进了缓冲区当中。

程序仍然在读取信息，这与我们进入交互模式时是与Shell进行交互的初衷有所背离。

显然有部分的信息没有发送给程序。

要知道这是一段极其简单的汇编代码，并且直接通过syscall调用的read接口，并没有给stdout等文件处理缓冲区，由于脚本发送数据的速度过快，同时又没有缓冲区进行临时的存在，导致了数据的丢失，因为开启调试模式后，调试信息的输出需要占用一定的时间，所以send会间隔一段时间后再发送，就不会产生数据丢失的情况。

我们在send之后添加sleep函数，也可也缓解这一问题。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)