Update on Overleaf.

Chapters/Implementation.tex

@@ -220,10 +220,10 @@ The decoded response data is further processed using \texttt{pydantic} data clas
 The \texttt{estk\_fwupd} application implements a proprietary firmware update interface, which was reverse-engineered (see \cref{sec:findings}). It supports reading the current firmware version, unlocking the \gls{euicc} for updates, and installing new binaries.\footnote{This unlocking is distinct from \gls{gp}-defined unlocking, which allows the execution of generic \gls{gp} commands. See \gls{gp} Card Specification.}
 
 \paragraph{Exception Handling}
-The SGP.22 standard defines a variety of response codes and error conditions. The \gls{lpa} library maps these response codes to custom exception classes for precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
+The \gls{sgp22} standard defines a variety of response codes and error conditions. The \gls{lpa} library maps these response codes to custom exception classes for precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
 
 \paragraph{SM-DP+ Client}
-In addition to eUICC communication, the \gls{lpa} must interact with the \gls{smdpp} server via the ES9+ interface. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by SGP.22:
+In addition to \gls{euicc} communication, the \gls{lpa} must interact with the \gls{smdpp} server via the ES9+ interface. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by \gls{sgp22}:
 \begin{lstlisting}[language=json,caption={ES9+ Request Headers}]
 {
   "Content-Type": "application/json",
@@ -239,11 +239,38 @@ The \gls{smdpp} client is primarily used by the \gls{isdr} application to execut
 \section{Fuzzing}
 \label{sec:fuzzing}
 
-\subsection{Data Fuzzing}
-\label{subsec:data_fuzzing}
-
 \subsection{APDU Fuzzing}
 \label{subsec:apdu_fuzzing}
 
+% idea: use custom lpa implementation to construct valid data and mutate it before sending -> check how the responses differentiate between euicc implementations
+% idea construct scenarios (pieces of code that make use of the lpa and its functions) and run them against euicc implementations
+% in comparison to the tracing and compare approach: the data is generated newly for each execution with valid data i.e no exact replay
+% since the generated data is valid we need to mutate it to trigger some errors and see differences -> mutation engine: handles mutation of apdus
+% each function that the lpa executes is recorded before and after its mutation including the response codes
+% the recordings are structured in a tree where each node repesents a function executed on the euicc with one mutation i.e each level represents one function and each node on that level a mutation
+
+
+% mutation engine
+% deterministic and random mutation engine
+% both implement the same kind of mutations: bitflip, random byte, zero block, shuffle block, truncate
+% deteministic always modifies the same data to have conistency between function execution for different euiccs
+% random engine applies the mutation to randome pieces of data
+% bitflip: flips a number of bits -> number is determined based on mutation_rate and length of data $max(1, len(data) * mutation_rate)$
+% random byte: switches the positions of bytes in data -> number of switches is determined in the same way as for bitflip
+% zero block: set the value of all bits in a block with some length to zero
+% shuffle block: data is cut into 16 bit pieces -> pieces are sorted by $sum(block) % 256$ and concatenated
+% truncate: removes tail of data
+
+% scenarios
+% represents a row of functions that are executed on each euicc (insert listing for example scenario)
+% is executed by scenario runner
+% scenario runner controls scenario execution, handles errors and records data to the operation recorder
+% operation recorder handles tree structure and determines which mutation is applied next
+% problem: if error occurs we need to restart scenario due to statefulness of euicc and its protocols -> high overhead just for restoring state of euicc
+% 
+
+\subsection{Data Fuzzing}
+\label{subsec:data_fuzzing}
+
 \section{CLI}
 \label{sec:cli}