Update on Overleaf.

Chapters/Background.tex

@@ -449,5 +449,49 @@ Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session ke
 
 After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address. The \gls{lpa} forwards this notification to the \gls{smdpp}, and upon receiving a success response, the \gls{euicc} removes the notification, completing the provisioning cycle.
 
+\section{Fuzzing}
+
+% fuzzing is a well-known technique for uncovering bugs and security vulnerabilities in software
+% has lead to the discovery of thousands of security vulnerabilities (cite oss-fuzz that lead to thousands of vulnerabilities)
+% sends valid, invalid, random data as input an monitors for unexpected behaviour (optimally semi-valid input i.e valid enough to pass but trigger unexpected behaviour) -> try to trigger edge cases
+% typically fuzzers try to cover a large portion of code (code coverage)  
+% three main different types of fuzzers
+
+% black box fuzzer
+% has no idea about the internal structure of the program i.e treats it as a black box
+
+% white box fuzzer
+% has full access to knowledge about internal structure
+% uses porgram analysis to increase code coverage
+% can be very effective in uncovering bugs deep inside the code
+
+% grey box fuzzer
+% uses instrumentation to increase code coverage
+
+% fuzzer needs to differentiate between expected normal behaviour or unexpectet behaviour -> bug
+% one option: use sanatizer to -> inject assertions to crash program if bug is detected
+% other option: use differential testing -> compare output of two programs that should behave the same when giving the same input
+% we cant inject assertions -> opted for option 2 i.e differntial testing
+
+Fuzzing is a well-established technique for uncovering software bugs and security vulnerabilities through the automated generation of test inputs. It has contributed to the discovery of thousands of critical security issues~\cite{arya_oss-fuzz_2025} across various domains. The fundamental principle behind fuzzing is to provide a target system with a large number of automatically generated inputs, ranging from completely random to well-structured, and monitor the system's behavior for anomalies such as crashes, unexpected outputs, or assertion failures.
+
+Traditionally, fuzzers attempt to explore edge cases and increase code coverage, aiming to execute as many distinct code paths as possible. Depending on the level of insight into the internal structure of the system under test, fuzzers are commonly classified into three categories \cite{chen_systematic_2018}:
+
+\begin{itemize}
+    \item \textbf{Black-box fuzzers} operate without any knowledge of the internal workings of the target. They treat the system as an opaque entity and rely solely on observable output or system responses to guide the fuzzing process.
+    
+    \item \textbf{White-box fuzzers} have full access to the source code and utilize program analysis such as symbolic execution to systematically generate inputs that exercise complex execution paths.
+    
+    \item \textbf{Grey-box fuzzers} operate between the two extremes by leveraging lightweight instrumentation such as coverage feedback, to guide input generation, without requiring complete source code access.
+\end{itemize}
+
+A critical aspect of effective fuzzing is the ability to differentiate between expected and unexpected behavior. In traditional fuzzing scenarios, this is often accomplished using sanitizers and runtime assertions, which cause the target program to fail explicitly when a bug is detected. However, such instrumentation is typically infeasible in closed-source or hardware-backed environments such as commercial \gls{esim} implementations~\cite{zaddach_avatar_2014}.
+
+Given these constraints, this thesis adopts a \textit{differential testing} approach to fuzzing. Instead of relying on internal instrumentation or assertions, the framework can compare the responses of multiple independent implementations of the same specification to identical fuzzed inputs. Any divergence in the observed behavior may indicate a potential bug, inconsistency in interpretation of the specification, or a security-relevant anomaly.
+
+This methodology is particularly well-suited for black-box systems like eSIM-on-SIM cards, where internal state and logic are inaccessible.
+
+
+