diff --git a/thesis/intercept_v2.0.pdf b/thesis/intercept_v2.0.pdf
new file mode 100644
index 0000000..0b78912
Binary files /dev/null and b/thesis/intercept_v2.0.pdf differ
diff --git a/thesis/src/02.related-work.tex b/thesis/src/02.related-work.tex
index 99317ec..4ae4ea5 100644
--- a/thesis/src/02.related-work.tex
+++ b/thesis/src/02.related-work.tex
@@ -32,10 +32,19 @@ The technique developed in this work would be classified as follows:
 Function, Static, Active+Passive, On-device, Exported Functions, OS Modification Not Required, target program may be Closed-source, Free.
 
 
+\subsection{Linux Systems}\label{subsec:linux-systems}
+
+Yasukata et al. \cite{zpoline} introduced zpoline, a system call hooking technique using binary rewriting.
+See Subsection~\ref{subsec:zpoline} for more details.
+Hong et al. \cite{datahook} developed DataHook, a system call hooking technique based on glibc.
+See Subsection~\ref{subsec:datahook} for more details.
+
+
 \subsection{Windows Systems}\label{subsec:windows-systems}
 
 Hunt and Brubacher \cite{detours} developed Detours, a library for instrumenting arbitrary Win32 functions on x86 machines.
 Detours intercepts Win32 functions by re-writing target function images.
+Based on this method, Sze and Sekar developed Spif \cite{spif} (see next subsection).
 
 
 \subsection{Security Applications}\label{subsec:security-applications}
@@ -56,18 +65,21 @@ They use Detours \cite{detours} to intercept low-level Windows API calls.
 Kern \cite{kern2023} discusses the use of \texttt{LD\_PRELOAD} in cloud environments for HTTP deception.
 This is done to analyze malware or other adversaries in real environments without their knowledge and without any risk of danger.
 Examples are to override the \texttt{send} and \texttt{recv} functions of libc.
+With some modifications, the technique presented in this work may also be used in this context to intercept and manipulate \texttt{send} and \texttt{recv} calls.
+
 
 \subsection{Software Distribution}\label{subsec:software-distribution}
 
 Guo and Engler \cite{guo2011cde} use system call hooking for creating portable software.
 They developed CDE, which logs all files a program accesses during execution, including shared libraries.
 All accessed files and the environment are bundled together and may now be executed on any other system having a compatible kernel without having to install any dependencies.
+This would also be possible with the use of logged function calls like in this work (e.g., see Section~\ref{sec:intercepting-example}).
 
 
 \subsection{Rapid Prototyping}\label{subsec:rapid-prototyping}
 
 Spillane et al. \cite{spillane2007} use \texttt{ptrace} to hook system calls of another process to simulate these calls using a user-space program.
-This is useful for rapid prototyping (e.g., file systems) because they may be developed as user-space program first, and only later on inside the kernel.
+This is useful for rapid prototyping (e.g., file systems) by developing a user-space program first, and then, using the gained insight, porting it into kernel-space.
 
 
 \section{Function Call Hooking}\label{sec:function-call-hooking}
diff --git a/thesis/src/05.evaluation.tex b/thesis/src/05.evaluation.tex
index f0e55bd..5a4fbbe 100644
--- a/thesis/src/05.evaluation.tex
+++ b/thesis/src/05.evaluation.tex
@@ -71,7 +71,7 @@ For some functions the modification of function arguments has been implemented.
 \section{Performance}\label{sec:performance}
 
 Although high performance was not a primary goal of this work, the performance degradation caused by interception and manipulation should not be excessive.
-The following two subsections test and discuss the performance degradation of \texttt{intercept.so} compared to running a program without any intercepting or hooking.
+The following two subsections test and discuss the performance degradation of \texttt{intercept.so} compared to running a program without any interception or hooking.
 
 
 \subsection{Performance when Intercepting}\label{subsec:performance-intercepting}
@@ -148,7 +148,7 @@ Most of the delay is caused by logging the recorded function calls.
 
 \subsection{Performance when Manipulating}\label{subsec:performance-manipulating}
 
-Measuring performance for function call manipulation makes no sense without knowing the exact socket server to be used.
+Meaningful performance evaluation of function call manipulation requires a specific server implementation, since the response speed of the server dominates overall performance.
 As seen in Subsection~\ref{subsec:performance-intercepting}, most delay comes not from intercepting itself, but from the further processing.
 This also applies to function call manipulation.
 The performance degradation heavily depends on the response speed of the used socket.