分类: LINUX
2008-08-19 00:02:45
In Part I of this article [LJ, November 2002], we saw how ptrace can be used to trace system calls and change system call arguments. In this article, we investigate advanced techniques like setting breakpoints and injecting code into running programs. Debuggers use these methods to set up breakpoints and execute debugging handlers. As with Part I, all code in this article is i386 architecture-specific.
In Part I, we ran the process to be traced as a child after calling ptrace(PTRACE_TRACEME, ..). If you simply wanted to see how the process is making system calls and trace the program, this would be sufficient. If you want to trace or debug a process already running, then ptrace(PTRACE_ATTACH, ..) should be used.
When a ptrace(PTRACE_ATTACH, ..) is called with the pid to be traced, it is roughly equivalent to the process calling ptrace(PTRACE_TRACEME, ..) and becoming a child of the tracing process. The traced process is sent a SIGSTOP, so we can examine and modify the process as usual. After we are done with modifications or tracing, we can let the traced process continue on its own by calling ptrace(PTRACE_DETACH, ..).
The following is the code for a small example tracing program:
|
Save the program as dummy2.c. Compile and run it:
gcc -o dummy2 dummy2.c ./dummy2 &
Now, we can attach to dummy2 by using the code below:
|
The above program simply attaches to a process, waits for it to stop, examines its eip (instruction pointer) and detaches.
To inject code use ptrace(PTRACE_POKETEXT, ..) and ptrace(PTRACE_POKEDATA, ..) after the traced process has stopped.
How do debuggers set breakpoints? Generally, they replace the instruction to be executed with a trap instruction, so that when the traced program stops, the tracing program, the debugger, can examine it. It will replace the original instruction once the tracing program continues the traced process. Here's an example:
|
Here we replace the three bytes with the code for a trap instruction, and when the process stops, we replace the original instructions and reset the eip to original location. Figures 1-4 clarify how the instruction stream looks when above program is executed.
Now that we have a clear idea of how breakpoints are set, let's inject some code bytes into a running program. These code bytes will print “hello world”.
The following program is a simple “hello world” program with modifications to fit our needs. Compile the following program with:
gcc -o hello hello.c
|
The jumping backward and forward here is required to find the address of the “hello world” string.
We can get the machine code for the above assembly from GDB. Fire up GDB and disassemble the program:
(gdb) disassemble main Dump of assembler code for function main: 0x80483e0: push %ebp 0x80483e1 : mov %esp,%ebp 0x80483e3 : jmp 0x80483fa End of assembler dump. (gdb) disassemble forward Dump of assembler code for function forward: 0x80483fa : call 0x80483e5 0x80483ff : dec %eax 0x8048400 : gs 0x8048401 : insb (%dx),%es:(%edi) 0x8048402 : insb (%dx),%es:(%edi) 0x8048403 : outsl %ds:(%esi),(%dx) 0x8048404 : and %dl,0x6f(%edi) 0x8048407 : jb 0x8048475 0x8048409 : or %fs:(%eax),%al 0x804840c : mov %ebp,%esp 0x804840e : pop %ebp 0x804840f : ret End of assembler dump. (gdb) disassemble backward Dump of assembler code for function backward: 0x80483e5 : pop %esi 0x80483e6 : mov $0x4,%eax 0x80483eb : mov $0x2,%ebx 0x80483f0 : mov %esi,%ecx 0x80483f2 : mov $0xc,%edx 0x80483f7 : int $0x80 0x80483f9 : int3 End of assembler dump.
We need to take the machine code bytes from main+3 to backward+20, which is a total of 41 bytes. The machine code can be seen with the x command in GDB:
(gdb) x/40bx main+3: eb 15 5e b8 04 00 00 00 : bb 02 00 00 00 89 f1 ba : 0c 00 00 00 cd 80 cc : e6 ff ff ff 48 65 6c 6c : 6f 20 57 6f 72 6c 64 0a
Now we have the instruction bytes to be executed. Why wait? We can inject them using the same method as in the previous example. The following is the source code; only the main function is given here:
|
In the previous example we injected the code directly into the executing instruction stream. However, debuggers can get confused with this kind of behaviour, so let's find the free space in the process and inject the code there. We can find free space by examining the /proc/pid/maps file of the traced process. The following function will find the starting address of this map:
|
Each line in /proc/pid/maps represents a mapped region of the process. An entry in /proc/pid/maps looks like this:
map start-mapend protection offset device inode process file 08048000-0804d000 r-xp 00000000 03:08 66111 /opt/kde2/bin/kdeinitThe following program injects code into free space. It's similar to the previous injection program except the free space address is used for keeping our new code. Here is the source code for the main function:
|
So what happens within the kernel now? How is ptrace implemented? This section could be an article on its own; however, here's a brief description of what happens.
When a process calls ptrace with PTRACE_TRACEME, the kernel sets up the process flags to reflect that it is being traced:
Source: arch/i386/kernel/ptrace.c
|
When a system call entry is done, the kernel checks this flag and calls the trace system call if the process is being traced. The gory assembly details can be found in arch/i386/kernel/entry.S.
Now, we are in the sys_trace() function as defined in arch/i386/kernel/ptrace.c. It stops the child and sends a signal to the parent notifying that the child is stopped. This wakes up the waiting parent, and it does the ptrace magic. Once the parent is done, and it calls ptrace(PTRACE_CONT, ..) or ptrace(PTRACE_SYSCALL, ..), it wakes up the child by calling the scheduler function wake_up_process(). Some other architectures can implement this by sending a SIGCHLD to child.
ptrace may appear to be magic to some people, because it can examine and modify a running program. It is generally used by debuggers and system call tracing programs, such as ptrace. It opens up interesting possibilities for doing user-mode extensions as well. There have been a lot of attempts to extend the operating system on the user level. See Resources to read about UFO, a user-level extension to filesystems. ptrace also is used to employ security mechanisms.
All example code from this article and from Part I is available as a tar archive on the Linux Journal FTP site [].