Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how to use Ptrace to intercept and simulate Linux system calls". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Words written in the front

Ptrace (2), a system call, is generally related to debugging. It is not only the main mechanism of local debugger monitoring implementation in Unix-like systems, but also a common implementation method of strace system calls. The ptrace () system call function provides a way for one process (the "tracer") to monitor and control another process (the "tracee"). It can not only monitor system calls, but also check and change the data in the memory and registers of the "tracee" process, and even intercept system calls.

By "intercept" I mean that tracer can change system call parameters, change the return value of system calls, or even block specific system calls. This means that a tracer will be able to fully implement its own system calls, which is very interesting, that is, a tracer will be able to simulate a complete set of operating system mechanisms without any other help from the kernel.

But the problem is that a process can only bind one tracer at a time, so we cannot simulate an external operating system while debugging a process (GDB). Another problem is that simulating system calls will cost more resources.

In this article, I will focus on Linux Ptrace under the x86-64 architecture, and I will also use some specific Linux extensions. In addition, I may ignore error checking, but eventually the full source code released will solve these problems.

Strace

Before we begin, let's take a look at the implementation skeleton of strace. There has never been a corresponding standard for the use of Ptrace, but its interfaces are similar in different operating systems, especially its core functions, but there are some slight differences. The prototype of Ptrace (2) is similar to the following:

Long ptrace (int request, pid_t pid, void * addr, void * data)

Pid is the process ID of tracee. A tracee can only bind one tracer at a time, but a tracer can bind multiple tracee.

The request domain is responsible for selecting a specified Ptrace function, such as the ioctl (2) interface. For strace, only the following are necessary:

PTRACE_TRACEME: its parent process must track this process.

PTRACE_SYSCALL: continue to run, but will be suspended at the next system call entry.

PTRACE_GETREGS: get the register backup of tracee.

The other two data fields, addr and data, are responsible for providing parameters to the selected Ptrace function, which can generally be ignored. Here I choose to pass in 0.

The strace interface is essentially a prefix for other commands:

$strace [strace options] program [arguments]

My minimized configuration does not contain any parameters, so the first thing to do is to assume that it contains at least one parameter (fork (2)), passed through argv. Before loading the target program, the new process informs the kernel that its parent process will track and monitor it, and tracee will be suspended by the Ptrace system call:

Pid_tpid = fork (); switch (pid) {case-1: / * error * / FATAL ("% s", strerror (errno)); case 0: / * child * / ptrace (PTRACE_TRACEME, 0,0,0); execvp (argv [1], argv + 1); FATAL ("% s", strerror (errno));}

The parent process will use wait (2) to wait for the PTRACE_TRACEME of the child process, and when wait (2) returns a value, the child process will be suspended:

Wait pid (pid,0, 0)

Before allowing the child process to continue, we will tell the operating system that tracee should be terminated with its parent process. The implementation of strace in a real scenario needs to set other parameters, such as PTRACE_O_TRACEFORK:

Ptrace (PTRACE_SETOPTIONS,pid, 0, PTRACE_O_EXITKILL)

The loop steps for capturing system calls are as follows:

1. Wait for the process to proceed to the next system call.

two。 Print system call information.

3. Allow the system call to execute and wait for the result to be returned.

4. Prints the return value of the system call.

The PTRACE_SYSCALL request can complete the tasks of waiting for the next system call and waiting for the system call to finish, and as before, you need to use wait (2) to wait for the tracee to enter a specific state.

Ptrace (PTRACE_SYSCALL,pid, 0,0); waitpid (pid,0, 0)

When wait (2) returns, the system call number and corresponding parameters will be stored in the thread register. The next step is to collect system call information, which is implemented differently in different system architectures. In x86-64, the system call number is passed through rax, and the parameters (up to 6) are passed to rdi, rsi, rdx, R10, R8, and R9. Other Ptrace calls are needed to read the register, but wait (2) is not needed here, because tracee does not change the state.

Struct user_regs_struct regs;ptrace (PTRACE_GETREGS,pid, 0, & regs); longsyscall = regs.orig_rax; fprintf (stderr, "% ld (% ld,% ld)", syscall, (long) regs.rdi, (long) regs.rsi, (long) regs.rdx, (long) regs.r10, (long) regs.r8, (long) regs.r9)

Next comes another PTRACE_SYSCALL and wait (2), and then uses PTRACE_GETREGS to get the result, which is stored in rax:

Ptrace (PTRACE_GETREGS,pid, 0, & regs); fprintf (stderr, "=% ld\ n", (long) regs.rax)

The output of this sample program is relatively simple, it does not contain the symbolic name of the system call, and each parameter is printed digitally, but this is enough to lay the foundation for system call interception.

System call interception

Suppose we want to use Ptrace to implement something like OpenBSD's pledge (2). The basic idea is as follows: many programs generally have an initialization process, which involves a lot of system access, such as opening files and binding sockets. After initialization, they enter the main loop and process the input data, where only a small number of system calls are used.

Before entering the main loop, the process can limit itself to a small amount of action, and pledge can limit what the exploit code can do if there is a vulnerability in the program. Of course, we can not only tamper with the system call parameters, but also modify the system call number, convert it to a system call that does not exist, and then report an EPERM error message in errno:

For (;;) {/ * Enter next system call * / ptrace (PTRACE_SYSCALL, pid, 0,0); waitpid (pid, 0,0); struct user_regs_struct regs; ptrace (PTRACE_GETREGS, pid, 0, & regs); / * Is this system call permitted? * / int blocked = 0; if (is_syscall_blocked (regs.orig_rax)) {blocked = 1; regs.orig_rax =-1 / / set to invalidsyscall ptrace (PTRACE_SETREGS, pid, 0Gramme regs);} / * Run system call and stop on exit * / ptrace (PTRACE_SYSCALL, pid, 0,0); waitpid (pid, 0,0); if (blocked) {/ * errno = EPERM * / regs.rax =-EPERM; / / Operation notpermitted ptrace (PTRACE_SETREGS, pid, 0cogregs) }} create a custom system call

I call my newly created system call that mimics pledge as xpledge (), and the system call number I choose is 10000:

# define SYS_xpledge 10000

The following is the complete interface implementation of the system call for tracee:

# define_GNU_SOURCE # include # defineXPLEDGE_RDWR (1

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.