![]() ![]() Ptrace was first implemented in Version 6 Unix, and was present in both the SVr4 and 4.3BSD branches of Unix. Further, programs that inject executable code into the target process or (like gdb) allow the user to enter commands that are executed in the context of the target must generate and load that code themselves, generally without the help of the program loader. Programs using it must have intimate knowledge of the specifics of the OS and architecture, including stack layout, application binary interface, system call mechanism, name mangling, the format of any debug data, and are responsible for understanding and disassembling machine code themselves. Ptrace only provides the most basic interface necessary to support debuggers and similar tools. FreeBSD, on the other hand, extended ptrace to remove mentioned problems, and declared procfs obsolete due to its inherent design problems. Such systems use ioctls on the file descriptor of the opened /proc file to issue commands to the controlled process. Some, such as Solaris, have removed ptrace as a system call altogether, retaining it as a library call that reinterprets calls to ptrace in terms of the platform's procfs. For this reason the 8th edition of Unix introduced procfs, which allows permitted processes direct access to the memory of another process - 4.4BSD followed, and the use of /proc for debugger support was inherited by Solaris, BSD, and AIX, and mostly copied by Linux. In FreeBSD, it is limited by FreeBSD jails and Mandatory Access Control policies.Ĭommunications between the controller and target take place using repeated calls of ptrace, passing a small fixed-size block of memory between the two (necessitating two context switches per call) this is acutely inefficient when accessing large amounts of the target's memory, as this can only be done in word sized blocks (with a ptrace call for each word). In Linux systems that feature capabilities-based security, the ability to ptrace is further limited by the CAP_SYS_PTRACE capability or by the YAMA Linux Security Module. ![]() Īs the ability to inspect and alter another process is very powerful, ptrace can attach only to processes that the owner can send signals to (typically only their own processes) the superuser account can ptrace almost any process (except init on kernels before 2.6.26). The ability to write into the target's memory allows not only its data store to be changed, but also the application's own code segment, allowing the controller to install breakpoints and patch the running code of the target. It can single-step through the target's code, can observe and intercept system calls and their results, and can manipulate the target's signal handlers and both receive and send signals on its behalf. This includes manipulation of its file descriptors, memory, and registers. It can further be used as a sandbox and as a run-time environment simulator (like emulating root access for non-root software ).īy attaching to another process using the ptrace call, a tool has extensive control over the operation of its target. ptrace is also used by specialized programs to patch running programs, to avoid unfixed bugs or to overcome security features. Ptrace is used by debuggers (such as gdb and dbx), by tracing tools like strace and ltrace, and by code coverage tools. ptrace is used by debuggers and other code-analysis tools, mostly as aids to software development. By using ptrace (the name is an abbreviation of "process trace") one process can control another, enabling the controller to inspect and manipulate the internal state of its target. ![]() Ptrace is a system call found in Unix and several Unix-like operating systems. ![]()
0 Comments
Leave a Reply. |