1
0

thesis: Apply proofreading suggestions

This commit is contained in:
2025-08-19 12:35:54 +02:00
parent 30121e4543
commit 8712bdc461
7 changed files with 32 additions and 33 deletions

View File

@@ -19,7 +19,7 @@ This excludes techniques already discussed in Section~\ref{sec:methods-for-inter
like \texttt{ptrace} (Subsection~\ref{subsec:ptrace}), and \texttt{strace} (Subsection~\ref{subsec:strace}).
Almost all following methods use binary rewriting to replace system calls with other instructions (except SUD, Subsection~\ref{subsec:syscall-user-dispatch}).
This is one of the reasons why they were not mentioned in Section~\ref{sec:methods-for-intercepting}.
Another one is that the focus of this work is function call interception, and not system call interception.
Another reason is that this work focuses on function call interception rather than system call interception.
\subsection{\texttt{int3} Signaling}\label{subsec:int3-signaling}
@@ -27,7 +27,7 @@ Another one is that the focus of this work is function call interception, and no
\texttt{int3} is a one-byte instruction (\texttt{0xcc}) that invokes a software interrupt.
On Linux, the kernel handles it and raises \texttt{SIGTRAP} to the user-space process that executed \texttt{int3}.
The \texttt{int3} signaling technique exploits this behavior to hook system calls; it replaces \texttt{syscall}/\texttt{sysenter} with \texttt{int3} and employs the signal handler for \texttt{SIGTRAP} as the hook function.
Since \texttt{int3} is one byte, it can replace an arbitrary instruction without breaking the neighbor instructions.
Since \texttt{int3} is one byte, it can replace an arbitrary instruction without breaking neighboring instructions.
This technique is traditionally used in debuggers to implement breakpoints.
However, signal handling incurs a large overhead because it involves context manipulation by the kernel.
\cite{zpoline}