lorenz.stechauner/BSc-Thesis
1
0
Fork 0
Code Activity

thesis: Last adjustments

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-09-04 01:49:17 +02:00
parent 7fe22fdc62
commit 2d29267454
3 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
thesis/intercept_v2.0.pdf Normal file
View File

Binary file not shown.

14
thesis/src/02.related-work.tex
View File

@@ -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}

4
thesis/src/05.evaluation.tex
View File

@@ -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.