Update on Overleaf.

Chapters/Design.tex

@@ -0,0 +1,161 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Design}\label{ch:design}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+% section introduces core design of our differential testing framework
+% supports systematic analysis of mutliple commercial and test eUICC cards
+% needs: reproduce and replay real-world interaction between euicc and lpa, mutate protocol-level inputs to explore edge cases and test for proper error handling, compare card responses under similar inputs to detect differences
+% we propose a three layered design:
+% 1. tracing and replay
+% 2. APDU fuzzing and comparison
+% 3. Data fuzzing
+
+% Design 1: tracing and replay
+% objective: capture real interaction sequences between an LPA and a target euicc -> enable deterministic replay of these recorded APDU sequences on different cards
+% Design
+% real world traces show how euiccs are used in practice -> also includes potential undocumented behaviour
+% replaying the same APDU sequences accross multiple cards -> direct differential comparison
+% setup must remain as close as possible to the actual communication path to path
+% key design elements
+% passive tracing: tracing component that intercepts APDUs exchange over a pysical interface using simtrace2; APDUs are associated with functional operations i.e select isd-r through partial classification
+% structured recording: each recorded session includes metadata such as command classification, src and target aids
+% replay engine: injects recorded APDUs into a session between an LPA running on an smartphone and the euicc; adjusts session specific fields i.e aids; diverging behaviour in responses or error codes are flagged
+% why?
+% tracing and replay -> provide rrealistic baseline for comparison and reproducibility without assuming full protocol compliance or specification access
+
+% Design 2: APDU fuzzing
+% objective: explore input space of the euicc rsp protocol stack by mutating valid APDUs and observing how cards respond to unexpected, malformed or corner-case inputs
+% desgin rational
+% valid traces may not expose edge-case behaviour or robustness against invalid input
+% fuzzing tests implementations ability to reject malformed inputs and recover from protocol violations
+% structured scenario runner allows controlled variation over function sequences
+% recording of input and output allows for direct differential comparison
+% design
+% scenario-based execution: define sequences of euicc operations into scenarios -> anchor fuzzing process; scenario is built from high-level commands
+% mutation-engine: APDU data is mutated using deterministic or randomized strategies similar to other industry standard fuzzers which inlcude mutations including bit-flips, zeroing data blocks, random byte replacement, block shuffling, truncation
+% mutation tree representation: execution state and mutations are recorded in hierachical tree -> each node represents function call, input mutation, and oberved result -> enables exhaustive and resumable fuzzing runs
+% exception aware runner: failures are isolated and retried with proper reset handling (reset card to original state) -> one invalid input does not compromise subsequent fuzzing steps
+% comparison engine: responses different euiccs can be compared node-by-node; deviations are reported and visualized as a tree; deviating paths from normal behavior during the scenario run are visulaized
+% why
+% apdu fuzzing allows us to probe error-handling paths, specification and asn1 parser boundaries -> uncover differences that would remain hidden during standard execution
+% deterministic strategies ensures reproducibility and side-by-side comparision with runs on other euiccs
+
+% Design 3: data fuzzing
+% fuzz with structurally valid inputs using property-based testing
+% design rational
+% explore the validity boundaries of specific protocol fields
+% valid input parsin and robustness of euicc interfaces under syntactically valid but semantically unusual inputs
+% automate test generation for application-layer API endpoints
+% design
+% type-aware input generation: generate complient payloads that respect expected schemas
+% property-based fuzzing: test LPA application-level interfaces by producing wide range of structurally valid inputs
+% no oracle required: focuses on detecting crashes, exception, or malformed responses instead of behavioral divergence between cards
+% replayable tests: tests can be performed on mutliple cards and results compared
+% why
+% design enables in-depth testing of fromat correctness and schema adherence for specific interfaces
+% complements other two strategies by focusing on structured input space exploration
+
+This section introduces the core design of our differential testing framework \sysname, which supports systematic analysis of multiple commercial and test \glspl{euicc}. The goal is to provide a flexible and extensible platform capable of:
+
+\begin{itemize}
+    \item Reproducing and replaying real-world interactions between \glspl{euicc} and \glspl{lpa},
+    \item Mutating protocol-level inputs to explore edge cases and verify robustness,
+    \item Comparing card responses under similar inputs to identify differences.
+\end{itemize}
+
+To achieve these goals, we propose a modular three-layered architecture:
+
+\begin{enumerate}
+    \item \textbf{Tracing and Replay}
+    \item \textbf{APDU Fuzzing}
+    \item \textbf{Data Fuzzing}
+\end{enumerate}
+
+\section{Design 1: Tracing and Replay}
+\label{subsec:design_1}
+
+The first design focuses on capturing and replaying real interaction sequences between an \gls{lpa} and a target \gls{euicc}. This allows deterministic replay of recorded \gls{apdu} sequences on different cards for side-by-side comparison.
+
+\paragraph{Design Rationale.} Real-world traces provide insights into how \glspl{euicc} are used in practice, including undocumented behavior not covered by specifications. Replaying identical \gls{apdu} sequences across cards enables direct differential testing. To ensure realistic conditions, the setup is designed to remain as close as possible to the original communication path between \gls{lpa} and \gls{euicc}.
+
+\paragraph{Key Components.}
+\begin{itemize}
+    \item \textbf{Passive Tracing:} A tracing module passively intercepts \gls{apdu} exchanges over a physical interface using \texttt{simtrace2}. Commands are partially classified and tagged with functional metadata, such as the selection of \gls{isdr}.
+    \item \textbf{Structured Recording:} Each session is recorded along with metadata, including command classifications, source and target \glspl{aid}, and session context.
+    \item \textbf{Replay Engine:} Captured traces are injected into a session between an \gls{lpa} and an \gls{euicc}. The engine adjusts session-specific fields (\eg, \glspl{aid}) and flags diverging behavior in the response status words or payloads.
+\end{itemize}
+
+\paragraph{Motivation.} This design provides a realistic baseline for comparison and reproducibility without requiring full specification access or assuming protocol compliance. It enables empirical analysis of protocol behavior under operational conditions.
+
+\section{Design 2: APDU Fuzzing}
+\label{subsec:design_2}
+
+The second design focuses on exploring the input space of the \gls{euicc} \gls{rdp} protocol stack by mutating valid \glspl{apdu}. The aim is to test robustness against malformed, unexpected, or edge-case inputs and to expose implementation-level inconsistencies.
+
+\paragraph{Design Rationale.} While real traces offer insight into typical usage, they often fail to reveal vulnerabilities related to invalid inputs. \gls{apdu} fuzzing is essential for testing the correctness of error handling and boundary enforcement.
+
+\paragraph{Key Components.}
+\begin{itemize}
+    \item \textbf{Scenario-Based Execution:} Scenarios are high-level sequences of \gls{euicc} operations (e.g., profile download) that anchor the fuzzing process.
+    \item \textbf{Mutation Engine:} Valid \glspl{apdu} are mutated using deterministic and randomized strategies, including bit-flipping, truncation, data zeroing, byte replacement, and block shuffling.
+    \item \textbf{Mutation Tree Representation:} The fuzzer constructs a hierarchical tree representing each function call, input mutation, and observed result, supporting exhaustive and resumable test runs.
+    \item \textbf{Exception-Aware Runner:} Each test is isolated, and card resets are used to restore a clean state, preventing a single failure from corrupting the session.
+    \item \textbf{Comparison Engine:} Results from multiple \glspl{euicc} are compared node-by-node. Deviations in status words, exceptions or data are reported and visualized to highlight divergent execution paths.
+\end{itemize}
+
+\paragraph{Motivation.} \gls{apdu} fuzzing allows systematic probing of error-handling logic, \gls{asn1} decoding boundaries, and specification ambiguities. The use of deterministic strategies supports reproducibility and enables direct comparison across different cards.
+
+\section{Design 3: Data Fuzzing}
+\label{subsec:design_3}
+
+The third design targets application-level logic using structurally valid inputs. It leverages property-based testing to exercise schema-conformant payloads and detect semantic inconsistencies or robustness issues.
+
+\paragraph{Design Rationale.} Data fuzzing explores the validity boundaries of specific protocol fields. Unlike raw \gls{apdu} mutation, it focuses on high-level, syntactically valid but semantically unusual inputs to stress the logic of the \gls{lpa}-\gls{euicc} interaction.
+
+\paragraph{Key Components.}
+\begin{itemize}
+    \item \textbf{Type-Aware Input Generation:} Payloads are generated according to type definitions and field constraints, ensuring compliance with expected formats.
+    \item \textbf{Property-Based Fuzzing:} A variety of structurally valid inputs are generated to test \gls{lpa} application-layer endpoints systematically.
+    \item \textbf{No Oracle Required:} Rather than expecting specific output, the tests flag crashes, exceptions, or malformed responses as anomalies.
+    \item \textbf{Replayable Tests:} Fuzzing inputs are recorded and replayable across multiple cards, enabling differential analysis and regression testing.
+\end{itemize}
+
+\paragraph{Motivation.} This design complements trace and \gls{apdu}-level fuzzing by shifting focus to semantic and structural correctness. It enables in-depth testing of parser robustness and adherence to data schemas within application-level interfaces.
+
+\section{Design Comparison}
+
+% all three design strategies present distinct approaches and tradeoffs as shown in \cref{tab:design-strategies}
+% tracing and replay: focuses on precise behavioral comparison by replaying fully valid sessions -> ensures valid input but limits the exploration of unexpected inputs or edge cases
+% APDU-level fuzzing: intruduces controlled mutations to valid APDUs -> expading coverage by probing implementaion-specific error handling and robustness; balances between generting diverse test-cases and preserving meaningful comparison across different euiccs
+% structured data fuzzing: generates structurally valid inputs -> excels at identifying semantic inconsistencies and deeper behavioral differences
+% together they provide a diverse and capable fuzzing framwork 
+
+\begin{table}[t]
+    \centering
+    \caption{Comparison of Design Strategies}
+    \label{tab:design-strategies}
+    \begin{tabular}{|l p{.25\textwidth} p{.25\textwidth} p{.25\textwidth}|}
+    \hline
+    \textbf{Design} & \textbf{Goal} & \textbf{Mutation Type} & \textbf{Input Validity} \\
+    \hline
+    Design 1 & Behavioral Comparison & None (Replay only) & Fully valid \\
+    \hline
+    Desing 2 & Protocol Robustness Testing & Byte-level mutations & Valid base, mutated \\
+    \hline
+    Design 3 & Semantic Boundary Exploration & Schema-level & Structurally valid \\
+    \hline
+    \end{tabular}
+\end{table}
+
+Each of the three design strategies presented in this chapter targets a different dimension of the fuzzing and differential testing problem, offering complementary strengths and tradeoffs, as summarized in \cref{tab:design-strategies}.
+
+\textbf{Tracing and Replay} focuses on the deterministic reproduction of real-world \gls{lpa}-\gls{euicc} sessions. By replaying fully valid \gls{apdu} sequences captured from live devices, this strategy ensures strict behavioral equivalence and reproducibility. However, it is limited in its ability to explore malformed or edge-case inputs.
+
+\textbf{APDU-Level Fuzzing} extends this foundation by introducing structured mutations into valid \glspl{apdu}. It strikes a balance between input validity and exploratory depth, allowing the framework to probe robustness, error-handling routines, and implementation-specific divergences while still supporting comparative analysis across multiple \glspl{euicc}.
+
+\textbf{Structured Data Fuzzing}, finally, operates at the semantic layer by generating well-formed but edge-case-rich inputs for application-level interfaces. This approach excels at uncovering logic flaws and inconsistencies in the parsing and interpretation of complex data structures, particularly those encoded in \gls{asn1}.
+
+Combined, these desings form a comprehensive and modular fuzzing framework capable of both functional and robustness testing of commercial \gls{esim} and eSIM-on-SIM implementations. Their integration enables a wide coverage of the input space, from valid production-level traffic to syntactically and semantically malformed payloads, thereby supporting rigorous security and conformance evaluations.

Chapters/Evaluation.tex

@@ -17,13 +17,12 @@
 The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
 To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
 
-% experiments were conduct on a host machine running arch linux
+% experiments were conduct on a host machine running arch linux (6.15.5-zen)
-% 32 GB of RAM, and and Ryzen 7 (find out actual version)
+% 32 GB of RAM, and and Ryzen 7 5800x
-% smart card reader is the HID OMNIKEY 3121 USB
+% smart card reader is the HID OMNIKEY 3121 USB in combination with sysmocom smart card adapter v1
+% smartcard middleware library: pcsclite 2.3.3-1
 
-All experiments were performed on a host machine running Arch Linux, equipped with 32\,GB of RAM and an AMD Ryzen 7 5800X processor. For physical communication with the \gls{esim} cards, an HID OMNIKEY 3121 USB smart card reader was used.
+All experiments were conducted on a host machine running Arch Linux (kernel version \texttt{6.15.5-zen}), equipped with an AMD Ryzen 7 5800X CPU and 32\,GB of RAM. For smart card interfacing, we used the HID OMNIKEY 3121 USB smart card reader in combination with the sysmocom Smart Card Adapter v1. The middleware stack was based on \texttt{pcsclite} version \texttt{2.3.3-1}, providing the PC/SC interface for APDU-level communication with the inserted \glspl{euicc}.
-
-\todo{List Hardware specs}
 
 \begin{table}[ht]
     \centering

Chapters/Implementation.tex

@@ -27,55 +27,7 @@ The primary goal of this thesis is to conduct a security analysis of commercial
 
 To perform differential testing, we designed a structured fuzzing methodology that employs both valid and mutated \gls{apdu} sequences. By observing and comparing how multiple \glspl{euicc} respond to the same inputs, we aim to uncover deviations that may indicate security flaws or implementation weaknesses.
 
-\section{Design}
+\section{Tracing and Replay}
-
-This section presents the step-by-step refinement of the testing strategy. The initial approach relied on recording and replaying \gls{apdu} traces as a basic method for interacting with \glspl{esim}. As the design progressed, it incorporated communication via the \gls{lpa}, and was eventually extended to include fuzzing capabilities at \gls{apdu} level. This evolution enabled more comprehensive and fine-grained differential testing across multiple \gls{euicc} implementations. 
-
-\paragraph{Initial Naive Approach}
-
-We first implemented a simple observation setup using the \texttt{simtrace2} tool. \texttt{simtrace2}~\cite{osmocom_simtrace_nodate} allows monitoring of communication between a physical device (typically a smartphone acting as the \gls{lpa}) and a \gls{sim} card. The tool captures \glspl{apdu} and forwards them via \gls{udp} packets to a local socket. From there, we parsed and analyzed the \gls{apdu} data.
-
-Our proposed methodology involved the following steps:
-\begin{enumerate}
-    \item Record the \gls{apdu} traffic between the \gls{lpa} and the \gls{euicc} during an \gls{rsp} session.
-    \item Store this traffic in a structured format.
-    \item Replace the original \gls{euicc} with another one inserted into a PC/SC-compatible card reader.
-    \item Replay each recorded \gls{apdu} and monitor the response.
-\end{enumerate}
-
-The goal was to detect behavioral differences, such as differing \glspl{sw} or execution failures. However, we discovered that this method was impractical in real-world scenarios. Due to the nature of the \gls{rsp} protocol, many operations involve cryptographic bindings using session-specific nonces, rendering traffic replay infeasible.
-
-\paragraph{Controlled LPA Implementation}
-
-To address the limitations of passive traffic replay, we developed our own minimal and controllable \gls{lpa}. Instead of relying on proprietary \gls{lpa} applications supplied by \gls{esim} vendors, we opted to implement a custom solution for two key reasons:
-
-\begin{itemize}
-    \item Vendor \glspl{lpa} often introduce extraneous or undocumented traffic unrelated to the provisioning process, which complicates analysis.
-    \item A custom \gls{lpa} allows for controlled mutation and injection of \gls{apdu} sequences.
-\end{itemize}
-
-The implemented \gls{lpa} performs a target operation (e.g., profile download or enablement) by issuing the appropriate command sequence to the \gls{euicc} in the PC/SC card reader. Prior to transmission, we programmatically mutate \glspl{apdu} to test the implementation’s robustness against malformed or unexpected input. We then record the resulting status words and assess behavioral consistency across different \gls{euicc} devices.
-
-While our approach allows for a more precise control, it has some drawbacks. \gls{rsp} is a stateful protocol, and provisioning actions rely on interaction with the profile vendor's \gls{smdpp} server. Consequently, execution speed is constrained by network latency and backend responsiveness as well as restoring the \gls{euicc} state after a reset.
-
-\paragraph{Fuzzing Strategy}
-
-When applying mutations to \gls{apdu} messages, we encountered a common issue: random mutations frequently produce invalid \gls{asn1} structures. This narrows the testing focus to the \gls{asn1} decoder, which represents only a small part of the total \gls{euicc} logic. Still, fuzzing at the decoding layer can still yield valuable results, as parsing flaws in \gls{asn1}-based decoders have historically led to critical vulnerabilities~\cite{mitre_cve_2003, nist_nvd_2024, nist_nvd_2025}.
-
-To improve the depth and scope of our fuzzing efforts, we adapted our implementation to generate and mutate structurally valid input instead. By preserving the syntactic and semantic correctness of \gls{asn1} structures, we enabled the fuzzer to exercise deeper layers of application logic. This allowed us to test state transitions, logical constraints, and error handling mechanisms that would otherwise remain untriggered by malformed data.
-
-To support this structured fuzzing approach, we integrated the Python-based \texttt{hypothesis} library, which provides property-based testing capabilities~\cite{maciver_hypothesis_2019}. Using \texttt{hypothesis}, we defined input schemas mirroring the \gls{asn1} structures employed in the SGP.22 specification~\cite{gsma_sgp22_2025}. The framework then automatically generates valid input covering a wide range of edge cases.
-
-With this setup, we were able to test:
-\begin{itemize}
-    \item Field boundary conditions (e.g., maximum tag lengths).
-    \item Rare but valid combinations of optional elements.
-    \item Complex nesting of \gls{tlv} structures.
-\end{itemize}
-
-In the following sections, we present the technical implementation details of our \gls{lpa} logic, input mutation framework, and fuzzing harness.
-
-\section{Tracing}
 \label{sec:tracing}
 
 % functions: 
@@ -89,7 +41,7 @@ In the following sections, we present the technical implementation details of ou
 % - recording: represents a list of recorded \glspl{apdu}, handles source and target isd-r addresses, file saving and loding as well as checking if the file is replayable
 % - replay: establishes connection to pcsc via pcsc link, loads recorded \glspl{apdu} and sends them over the link to the connected euicc, switches out source isd-r and target isd-r during replay, compares response status word to recorded status word on prints an error if there is a difference
 
-We built the tracing component to capture and interpret \glspl{apdu} exchanged between an \gls{lpa} (or other source) and the \gls{euicc}, and to replay them by inserting the recorded \glspl{apdu} into the communication between the \gls{lpa} and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
+We built the tracing component based on Design 1 in \cref{subsec:design_1} to capture and interpret \glspl{apdu} exchanged between an \gls{lpa} (or other source) and the \gls{euicc}, and to replay them by inserting the recorded \glspl{apdu} into the communication between the \gls{lpa} and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
 
 Our tracing functionality comprises two main operations:
 
@@ -112,15 +64,15 @@ The implementation consists of several key components:
 \begin{description}
     \item[\texttt{PcscLink}] A thin wrapper over the Python \texttt{pyscard} library~\cite{rousseau_pyscard_2025}, which abstracts away low-level communication with PC/SC-compatible card readers. It handles session establishment, \glspl{apdu}/\gls{tpdu} transmission, and automatic processing of status words such as \texttt{61XX} (i.e., triggering \texttt{GET RESPONSE} when necessary).
 
-    \item[\texttt{Card}] Represents a connected card in a PC/SC reader. It queries the card to determine its type (e.g., standard \gls{sim}, test \gls{euicc}, or commercial \gls{euicc}), and identifies installed applications such as \texttt{\gls{isdr}} or \texttt{\gls{ecasd}}. The class serves as the interface for sending \glspl{apdu} to the card through the \texttt{pcsc\_link}.
+    \item[\texttt{Card}] Represents a connected card in a PC/SC reader. It queries the card to determine its type (e.g., standard \gls{sim}, test \gls{euicc}, or commercial \gls{euicc}), and identifies installed applications such as \gls{isdr} or \gls{ecasd}. The class serves as the interface for sending \glspl{apdu} to the card through the \texttt{pcsc\_link}.
 
     \item[\texttt{Tracer}] A dummy implementation of the \texttt{Card} interface used during passive tracing. It parses incoming \glspl{apdu} from the GSMTAP interface using \texttt{pysim} and attempts to classify them based on instruction type. This allows mapping observed \glspl{apdu} to functional operations.
 
-    \item[\texttt{Recorder}] Coordinates tracing and recording. It spawns a separate tracer thread that listens for \glspl{apdu} from GSMTAP in a loop until a timeout occurs or a stop signal is issued. \glspl{apdu} are recorded alongside the designated target \texttt{\gls{isdr}} for later analysis.
+    \item[\texttt{Recorder}] Coordinates tracing and recording. It spawns a separate tracer thread that listens for \glspl{apdu} from GSMTAP in a loop until a timeout occurs or a stop signal is issued. \glspl{apdu} are recorded alongside the designated target \gls{isdr} for later analysis.
 
     \item[\texttt{recording}] An abstraction for a recorded session. It stores the list of \glspl{apdu}, associated source and target \texttt{\gls{isdr}} addresses, and metadata. It provides serialization functions for saving to and loading from disk, as well as validity checks to determine whether a recording is replayable.
 
-    \item[\texttt{replay}] Loads a saved \texttt{recording}, connects to the target \gls{euicc} via \texttt{PcscLink}, and replays each \glspl{apdu}. During replay, the source and target \texttt{\gls{isdr}} values are automatically substituted. The response status words from the target \gls{euicc} are compared against those from the original trace. Any mismatch is reported to highlight divergent behavior.
+    \item[\texttt{replay}] Loads a saved \texttt{recording}, connects to the target \gls{euicc} via \texttt{PcscLink}, and replays each \glspl{apdu}. During replay, the source and target \gls{isdr} values are automatically substituted. The response status words from the target \gls{euicc} are compared against those from the original trace. Any mismatch is reported to highlight divergent behavior.
 \end{description}
 
 This modular structure allows for easy integration into both automated test pipelines and manual inspection tools, and lays the groundwork for both our mutation-based and structure-aware fuzzing techniques described in subsequent sections.
@@ -327,7 +279,7 @@ The \gls{smdpp} client is primarily used by our \gls{isdr} application to execut
 % differences in the tree strcuture are also handled i.e failed mutations and therefor no child nodes
 % - nodes are considered different if the response code is different or it has a different failure reason i.e EuiccException or AssertionError (Problems occurd outside of euicc)
 
-To uncover behavioral differences between \gls{euicc} implementations, we implemented a fuzzing framework that mutates valid \glspl{apdu} generated via our custom \gls{lpa} implementation. Unlike the tracing-and-compare approach described earlier, the fuzzing strategy dynamically constructs valid request data and intentionally mutates it prior to transmission, allowing for meaningful analysis of error-handling behavior across cards.
+To uncover behavioral differences between \gls{euicc} implementations, we implemented a fuzzing framework that mutates valid \glspl{apdu} generated via our custom \gls{lpa} implementation based on Design 2 in \cref{subsec:design_2}. Unlike the tracing-and-compare approach described earlier, the fuzzing strategy dynamically constructs valid request data and intentionally mutates it prior to transmission, allowing for meaningful analysis of error-handling behavior across cards.
 
 \subsubsection*{Fuzzing Scenarios and Execution}
 
@@ -516,9 +468,9 @@ This differential testing method highlights edge-case inconsistencies across \gl
 % on the other hand an undefined error is still handled be the euicc but could not be properly handled -> could mean that there is a potential bug in the implementation and we need to do some further investigation into to this particular function call
 % -> euicc exceptions are ignored unless they are an UndefinedError
 
-While APDU-level fuzzing (see \cref{subsec:apdu_fuzzing}) is useful for evaluating command behavior across different \textit{euicc} implementations, it suffers from the drawback that random mutations—particularly at the bit or byte level—often invalidate the structured \gls{asn1} encoding. As a result, many \gls{apdu} mutations are immediately rejected as malformed, limiting the coverage and effectiveness of the test campaign.
+While APDU-level fuzzing (see \cref{subsec:apdu_fuzzing}) is useful for evaluating command behavior across different \textit{euicc} implementations, it suffers from the drawback that random mutations, particularly at the bit or byte level, often invalidate the structured \gls{asn1} encoding. As a result, many \gls{apdu} mutations are immediately rejected as malformed, limiting the coverage and effectiveness of the test campaign.
 
-To address this limitation, we introduce a complementary \textit{data fuzzing} approach that operates at the semantic level by fuzzing the input arguments of high-level \gls{lpa} function calls. This enables us to maintain structural validity while still exercising a wide variety of edge cases in the data provided to the \gls{euicc}. Our implementation builds on property-based testing frameworks designed for Python, in particular the \texttt{hypothesis} library~\cite{maciver_hypothesis_2019}.
+To address this limitation, we introduce a complementary \textit{data fuzzing} approach based on Design 3 in \cref{subsec:design_3}, that operates at the semantic level by fuzzing the input arguments of high-level \gls{lpa} function calls. This enables us to maintain structural validity while still exercising a wide variety of edge cases in the data provided to the \gls{euicc}. Our implementation builds on property-based testing frameworks designed for Python, in particular the \texttt{hypothesis} library~\cite{maciver_hypothesis_2019}.
 
 \paragraph{Fuzzing with Hypothesis}
 Hypothesis is a property-based testing framework, which allows developers to define \textit{strategies} for input data. The framework then generates test cases based on these strategies and attempts to explore edge cases through randomized sampling and shrinking. Unlike traditional random fuzzing, Hypothesis ensures that generated inputs conform to the structural invariants defined by the strategy, thereby increasing the likelihood of discovering subtle logic errors in protocol handling.

Thesis.tex

@@ -186,6 +186,7 @@
 	\ctparttext{The contribution starts with a design chapter, where we mathematically describe the design of the physical layer security system, as well as the adaptive filter of the attacker. After the design follows the implementation on WARP nodes. Here we give an insight into the challenges of implementing the designed MIMO communication system. The last chapter concentrates on evaluating the performance of our proposed attack in simulation and practice.}
 	\partExtra{Contribution}
 }{}
+\include{Chapters/Design}
 \include{Chapters/Implementation}
 \include{Chapters/Evaluation}
 \iftoggle{parts}{