Update on Overleaf.

AdditionalPackages.tex

@@ -159,3 +159,7 @@
   }%
   \glsadd{#1}%
 }
+
+% plots
+\usepackage{pgfplots}
+\pgfplotsset{compat=1.18}

Appendices/SomeProof.tex

@@ -93,3 +93,5 @@ This exception model provides the following advantages:
 \end{itemize}
 
 This exception system enables detailed introspection during fuzzing and testing while maintaining a clean abstraction between components.
+
+\todo{add section about inital testing of nonce randomness}

Bibliography.bib

@@ -285,13 +285,13 @@ C compilers is available on the web.},
 	file = {PDF:/home/niklas/Zotero/storage/PMG9FK4I/eUICC Profile Package Interoperable Format Technical Specification v3.0.pdf:application/pdf},
 }
 
-@misc{etsi_ts_2023,
+@misc{etsi_ts_2003,
 	title = {{TS} 102 22 {UICC}-{Terminal} interface},
 	url = {https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/04.10.00_60/ts_102221v041000p.pdf},
 	urldate = {2025-02-03},
 	author = {{ETSI}},
 	month = jun,
-	year = {2023},
+	year = {2003},
 	file = {PDF:/home/niklas/Zotero/storage/DAXFX2XH/ETSI TS 102 221 V4.10.0.pdf:application/pdf},
 }
 
@@ -552,7 +552,7 @@ C compilers is available on the web.},
 	file = {Full Text:/home/niklas/Zotero/storage/M3TAPWCL/MacIver et al. - 2019 - Hypothesis A new approach to property-based testing.pdf:application/pdf},
 }
 
-@misc{etsi_ts_2023-1,
+@misc{etsi_ts_2023,
 	title = {{TS} 102 241 {UICC} {API}},
 	language = {en},
 	author = {{ETSI}},
@@ -724,3 +724,23 @@ C compilers is available on the web.},
 	year = {2023},
 	file = {PDF:/home/niklas/Zotero/storage/KSQP8T2D/SGP.21-V3.1.pdf:application/pdf},
 }
+
+@misc{iebb_nekokolpa_nodate,
+	title = {{NekokoLPA}},
+	url = {https://github.com/iebb/NekokoLPA},
+	urldate = {2025-07-02},
+	author = {{iebb}},
+	file = {iebb/NekokoLPA\: NekokoLPA:/home/niklas/Zotero/storage/S8SXVMEV/NekokoLPA.html:text/html},
+}
+
+@misc{colvin_pydantic_2025,
+	title = {Pydantic},
+	copyright = {MIT},
+	url = {https://github.com/pydantic/pydantic},
+	abstract = {Data validation using Python type hints},
+	urldate = {2025-07-03},
+	author = {Colvin, Samuel and Jolibois, Eric and Ramezani, Hasan and Garcia Badaracco, Adrian and Dorsey, Terrence and Montague, David and Matveenko, Serge and Trylesinski, Marcelo and Runkle, Sydney and Hewitt, David and Hall, Alex and Plot, Victorien},
+	month = jun,
+	year = {2025},
+	note = {original-date: 2017-05-03T21:23:58Z},
+}

Chapters/Background.tex

@@ -14,7 +14,7 @@
 % - The os on the card can also run java card applets to provide additional functionality
 % - java card applets enable the use of the java language to be used on smart cards, use the Java Card Runtime Environment which runs inside the Java Card VM
 
-The \gls{sim} card is a specialized type of smart card, a form factor also employed in applications such as banking (\eg, EMV cards) and access control (\eg, MIFARE cards). As a smart card, a \gls{sim} contains essential computing components: a CPU, ROM, and RAM, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{smartcard-standard}.
+The \gls{sim} card is a specialized type of smart card, a form factor also employed in applications such as banking (\eg, EMV cards) and access control (\eg, MIFARE cards). As a smart card, a \gls{sim} contains essential computing components: a CPU, ROM, and RAM, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{etsi_ts_2003}.
 
 Interaction with the \gls{sim} is governed by an embedded operating system, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
 
@@ -273,7 +273,7 @@ This architecture introduces a remote provisioning mechanism and significantly e
 
 To manage, store, and control \gls{esim} profiles, the \gls{euicc} hosts several critical applications and system components. These include the \gls{isdr}, \gls{isdp}, \gls{ecasd}, optionally the embedded \gls{lpa}, \gls{aram}, and various \gls{lpa} service interfaces as shown in \cref{img:euicc_architecture}.
 
-The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the eUICC Identifier (\texttt{EID}), the \gls{euicc} Manufacturer (\gls{eum}) certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.
+The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the eUICC Identifier (\texttt{EID}), the \gls{euicc} Manufacturer (\gls{eum}) certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
 
 The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
 
@@ -307,7 +307,16 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
 
 \paragraph{Local Profile Assistant}
 
-The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
+\begin{figure}[h!]
+    \centering
+    \includegraphics[width=.32\textwidth]{Graphics/lpa_easyeuicc.jpg}
+    \includegraphics[width=.32\textwidth]{Graphics/lpa_9esim.jpg}
+    \includegraphics[width=.32\textwidth]{Graphics/lpa_5ber.jpg}
+    \caption{\gls{lpa} interface of the open-source EasyEUICC App~\cite{petercxy_openeuicc_nodate}, 9esim v2 (rebranded version of the open-source NekokoLPA~\cite{iebb_nekokolpa_nodate}, and 5ber.}
+    \label{img:lpa_interfaces}
+\end{figure}
+
+The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
 
 \begin{figure}[h!]
     \includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
@@ -321,7 +330,16 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
 
 \paragraph{Application Toolkit}
 
-The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device.
+The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as SIM Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
+The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device.
+
+\begin{figure}[h!]
+    \centering
+    \includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_cardinfo.jpg}
+    \includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_profile_info.jpg}
+    \caption{\gls{cat} interfaces of the 9esim v2 card showing the card and profile info.}
+    \label{img:cat_interface}
+\end{figure}
 
 
 

Chapters/Evaluation.tex

@@ -126,7 +126,45 @@ Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicl
 
 The firmware image accompanying the update utility appears to be encrypted or obfuscated. An entropy analysis conducted using the Shannon entropy metric indicates a consistently high entropy across all tested firmware files, suggesting the presence of encryption or compression. For instance, the entropy of the T001V06 firmware image was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
 
-\todo{Entropy graph, shannon entropy for all firmwares}
+\begin{figure}[htbp]
+\centering
+\begin{tikzpicture}
+  \begin{axis}[
+    title={Shannon Entropy},
+    xlabel={Block},
+    ylabel={Entropy},
+    legend pos=south west,
+    width=12cm,
+    height=6cm,
+    enlargelimits=true,
+    mark size=2pt,
+    xmin=0,
+    ymin=0,
+    grid,
+  ]
+
+    \addplot[
+      color=blue,
+      mark=*,
+    ] table [x expr=\coordindex, y index=0] {Graphics/data/shannon_entropy_estk_me_t000v06_3_4_3.dat};
+    \addlegendentry{T000V06}
+
+    \addplot[
+      color=red,
+      mark=square*,
+    ] table [x expr=\coordindex, y index=0] {Graphics/data/shannon_entropy_estk_me_t001v06_3_4_3.dat};
+    \addlegendentry{T001V06}
+
+    \addplot[
+      color=green!60!black,
+      mark=triangle*,
+    ] table [x expr=\coordindex, y index=0] {Graphics/data/shannon_entropy_estk_me_t002v06_3_4_3.dat};
+    \addlegendentry{T002V06}
+
+  \end{axis}
+\end{tikzpicture}
+\caption{Shannon entropy values across blocks for three different firmware versions.}
+\end{figure}
 
 A deeper static analysis using Ghidra did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk\footnote{https://github.com/ReFirmLabs/binwalk} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
 
@@ -220,7 +258,7 @@ We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple
     \item \textbf{standard}: \texttt{a0000005591010ffffffff8900000100}
 \end{itemize}
 
-This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations. \todo{Check which applications are allowed by the ara-m}
+This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations.
 
 While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
 

Chapters/Implementation.tex

@@ -23,7 +23,13 @@
 % - tests for edge cases
 % - in the following sections i will go into details on how each implementation work
 
-The primary goal of this thesis is to conduct a security analysis of commercial \gls{esim} implementations using differential testing. The underlying idea of this approach is to systematically compare the behavior of different \gls{euicc} implementations under the same inputs to detect inconsistencies or vulnerabilities.
+The primary goal of this thesis is to conduct a security analysis of commercial \gls{esim} implementations using differential testing. The underlying idea of this approach is to systematically compare the behavior of different \gls{euicc} implementations under the same inputs to detect inconsistencies or vulnerabilities. The focus lies particularly on components and behaviors that differentiate traditional \gls{sim} cards from \glspl{esim}, such as profile download and profile mangement capabilites.
+
+Differential testing is applied through structured fuzzing, using both valid and mutated \gls{apdu} sequences. By observing how different \glspl{euicc} respond to identical input, the approach aims to uncover deviations that may indicate security flaws or implementation weaknesses.
+
+\section{Design}
+
+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}
 
@@ -54,7 +60,11 @@ While this approach allows for a more precise control, it has some drawbacks. \g
 
 \paragraph{Fuzzing Strategy}
 
-A challenge in mutating \gls{apdu} messages is that random mutations often lead to invalid \gls{asn1} structures. This effectively reduces the testing strategy to fuzzing the \gls{asn1} decoder, which is only a small part of the \gls{euicc} logic. To increase test effectiveness, the implementation shifted toward fuzzing \textit{valid structured input} rather than arbitrary byte sequences.
+A challenge in mutating \gls{apdu} messages is that random mutations often lead to invalid \gls{asn1} structures. This effectively reduces the testing strategy to fuzzing the \gls{asn1} decoder, which constitutes only a small component of the overall \gls{euicc} logic. While this approach can reveal vulnerabilities in the \gls{asn1} parser, especially given that parsing vulnerabilities in \gls{asn1}-based decoders have historically led to critical security issues \cite{mitre_cve_2003, nist_nvd_2024, nist_nvd_2025}, it tends to produce limited coverage of the higher-level application logic implemented in the card.
+
+Nonetheless, the effectiveness of fuzzing the \gls{asn1} parser layer should not be underestimated. Invalid or malformed inputs may still expose critical flaws, such as memory corruption or improper bounds checking within parser implementations. Consequently, early-stage fuzzing using random or deterministic byte-level mutations can serve as a useful baseline for robustness testing at the decoding boundary.
+
+To broaden the scope and increase the effectiveness of the fuzzing strategy, the implementation was adapted to focus on generating and mutating \textit{structurally valid input} instead. By preserving the syntactic and semantic integrity of the underlying \gls{asn1} structures, the fuzzer is able to explore deeper application logic paths beyond the decoder. This allows for a more comprehensive evaluation of the \gls{euicc} system, including internal state transitions, logical constraints, and error handling routines that are only triggered in the presence of valid but semantically diverse \glspl{apdu}.
 
 To support structured data fuzzing, this thesis uses the Python-based \texttt{hypothesis} library, which implements property-based testing~\cite{maciver_hypothesis_2019}. \texttt{hypothesis} allows definition of input schemas that mirror \gls{asn1} structures used in \gls{esim} protocols. From these schemas, it automatically generates valid input data covering a wide range of edge cases.
 
@@ -83,7 +93,7 @@ In the following sections, the technical details of each implementation componen
 % - 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
 
-The tracing component is responsible for capturing, interpreting, and replaying \glspl{apdu} communication between an \gls{lpa} (or other source) 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 to capture, interpret, and replay \glspl{apdu} communication between an \gls{lpa} (or other source) 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.
 
 The tracing functionality comprises two main operations:
 
@@ -189,7 +199,7 @@ This modular structure allows for easy integration into both automated test pipe
 % before returning the data to the caller -> client checks for error on server and eventually raises the corresponding exception -> as explained in the exception handling part
 % smdp+ client is mostly used by the isd-r
 
-Due to the limitations of the \texttt{tracer} implementation in correctly replaying \gls{rsp} interactions, a dedicated \gls{lpa} implementation was developed to initiate valid interactions with the \gls{euicc}. This enables the controlled generation and mutation of valid traffic which we will further explain in \cref{sec:fuzzing}. Our implementation targets the SGP.22 v3.1 specification, which was the latest version available at the time of writing \cite{gsma_sgp22_2025}.
+Due to the limitations of the \texttt{tracer} implementation in correctly replaying \gls{rsp} interactions, we developed a dedicated \gls{lpa} implementation to initiate valid interactions with the \gls{euicc}. This enables the controlled generation and mutation of valid traffic which we will further explain in \cref{sec:fuzzing}. Our implementation targets the SGP.22 v3.1 specification, which was the latest version available at the time of writing \cite{gsma_sgp22_2025}.
 
 The \gls{lpa} is composed of multiple components:
 
@@ -210,20 +220,20 @@ Each euicc application (e.g., \gls{isdr}, \gls{ecasd}, ESTK firmware update) is
 Known \glspl{adf} for \gls{isdr} observed during analysis:
 \begin{itemize}
   \item Common: \texttt{A0000005591010FFFFFFFF8900000100}
-  \item 5Ber.esim: \texttt{A0000005591010FFFFFFFF8900050500}
+  \item 5Ber: \texttt{A0000005591010FFFFFFFF8900050500}
   \item Xesim: \texttt{A0000005591010FFFFFFFF8900000177}
   \item esim.me: \texttt{A0000005591010000000008900000300}
 \end{itemize}
 
-The decoded response data is further processed using \texttt{pydantic} data classes. \texttt{pydantic} is a python library that enable structured parsing of values including Base64-encoded strings, bitfields, version types, and more. Custom encoders/decoders are used to simplify readability and downstream data processing. For bit fields, a mixin is used to allow checking for specific feature flags via simple accessors.
+The decoded response data is further processed we use \texttt{pydantic} data classes. \texttt{pydantic}~\cite{colvin_pydantic_2025} is a python library that enable structured parsing of values including Base64-encoded strings, bitfields, version types, and more. We implemented custom encoders/decoders to simplify readability and downstream data processing. For bit fields, a mixin is used to allow checking for specific feature flags via simple accessors.
 
-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\footnote{This unlocking is distinct from \gls{gp}-defined unlocking, which allows the execution of generic \gls{gp} commands. See \gls{gp} Card Specification.} the \gls{euicc} for updates, and installing new binaries.
+The \texttt{estk\_fwupd} application implements a proprietary firmware update interface, which we reverse-engineered (see \cref{sec:eval_tracing}). It supports reading the current firmware version, unlocking\footnote{This unlocking is distinct from \gls{gp}-defined unlocking, which allows the execution of generic \gls{gp} commands. See \gls{gp} Card Specification.} the \gls{euicc} for updates, and installing new binaries.
 
 \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 SGP.22 standard defines a variety of response codes and error conditions. We map these response codes to custom exception classes in the \gls{lpa} implementation to enable 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 \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 SGP.22:
+In addition to \gls{euicc} communication, the \gls{lpa} implementation 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:
 \begin{lstlisting}[language=json,caption={ES9+ Request Headers}]
 {
   "Content-Type": "application/json",
@@ -322,39 +332,42 @@ To uncover behavioral differences between \gls{euicc} implementations, we implem
 
 \subsubsection*{Fuzzing Scenarios and Execution}
 
-Fuzzing is conducted through predefined \emph{scenarios}—sequences of function calls that operate on the \gls{euicc}. Each function in a scenario interacts with the \gls{euicc} through the \gls{lpa} and is subject to mutation. The scenario runner initiates a fresh PC/SC link, resets the card into a clean state (processing all notifications and performing a full memory reset) using our \gls{lpa} implementation, and executes each function with multiple mutations.
+Fuzzing is conducted through predefined \emph{scenarios}—sequences of function calls that operate on the \gls{euicc}. Each function in a scenario interacts with the \gls{euicc} through the \gls{lpa} and is subject to mutation. The scenario runner initiates a fresh PC/SC link, resets the card into a clean state (processing all notifications and performing a full memory reset) by calling the \texttt{eUICCMemoryReset} function using our \gls{lpa} implementation, and executes each function with multiple mutations.
 
 This process is guided by an \textbf{operation recorder} that tracks each function call, applied mutations, and resulting responses in a structured \emph{mutation tree}. Each tree node represents a specific function call executed with one type of mutation. A tree level corresponds to a function in the scenario and sibling nodes represent different mutations of that function.
 
 \subsubsection*{Mutation Engine}
 \label{subsubsec:mutation_engine}
 
-The mutation engine supports both \textit{deterministic} and \textit{random} mutation modes, and implements the following strategies:
-
-\todo{Go into more detail on how the muations are performed}
+We designed the mutation engine to support both \textit{deterministic} and \textit{random} mutation modes. It implements the following strategies for data transformation:
 
 \begin{itemize}
-  \item \textbf{Bit flip:} Flips a fixed number of bits based on mutation rate and payload length.
-  \item \textbf{Random byte:} Swaps random byte positions.
-  \item \textbf{Zero block:} Replaces a sequence of bytes with zeros.
-  \item \textbf{Shuffle block:} Chunks data into 16-bit segments and sorts them by their checksum.
-  \item \textbf{Truncate:} Removes the tail of the \gls{apdu}.
+\item \textbf{Bit Flip:} In this strategy, individual bits within the payload are flipped to introduce low-level perturbations. The number of bits to flip is determined by the mutation rate $M$ in proportion to the length $L$ of the payload: $max(1, L \cdot M)$. In deterministic mode, the bit positions are computed using a fixed formula: the byte index $B_I$ is calculated as $(i \cdot 31) \mod L$ and the specific bit to flip within that byte is $(i \cdot 7) \mod 8$ with $i$ indicating the index of the current flip. This approach ensures consistent mutation offsets across runs, thereby facilitating reproducibility.
+
+\item \textbf{Random Byte:} This mutation strategy replaces specific bytes with deterministic pseudo-random values. Similar to the bit flip strategy, the number of mutations is derived from the mutation rate $M$ and length $L$ of the payload. The byte index is computed using $(i \cdot 29) \mod L$, and the replacement value is calculated as $(i \cdot 13) \mod 256$ where is the index of the current mutation. Although the name suggests randomness, in deterministic mode these substitutions are reproducible due to the deterministic index-value derivation.
+
+\item \textbf{Zero Block:} A contiguous sequence of bytes is replaced with zeroes to simulate data loss or corruption. The mutation engine deterministically selects the starting index as $\lfloor \frac{L}{4} \rfloor \mod \max(1, L - 20)$ and replaces the next ten bytes (up to the end of the data). This method introduces a predictable null block, which is especially useful for observing system behavior under conditions of zeroed memory regions.
+
+\item \textbf{Shuffle Block:} To alter the structure of the payload while preserving local data, the input is first partitioned into fixed-size blocks (16 bytes each). These blocks are then reordered deterministically based on a checksum-like function, specifically by sorting according to the sum of bytes in each block modulo 256.
+
+\item \textbf{Truncation:} The mutation engine simulates incomplete transmissions or premature message termination by truncating the payload at a fixed ratio. Specifically, the payload is cut at 75\% of its original length. This type of mutation is particularly relevant in fuzzing protocols or parsers that may not handle end-of-stream conditions robustly.
 \end{itemize}
 
-Deterministic mode ensures reproducibility by always mutating the same offset, while the random mode selects targets dynamically. This allows us to explore both fixed and variable fuzzing behavior. Both modes behave similar to the deterministic and non-deterministic mutation modes used in AFLPlusPlus~\cite{fioraldi_afl_2020}.
+Deterministic mode ensures reproducibility by applying mutations at fixed, formula-derived offsets, whereas the random mode selects mutation targets probabilistically at runtime. Both modes behave similar to the deterministic and non-deterministic mutation modes used in AFLPlusPlus~\cite{fioraldi_afl_2020}.
+
 
 \subsubsection*{Fuzzing Workflow}
 
-The \gls{apdu} fuzzing workflow is illustrated in \cref{fig:scenario_flow} and proceeds in four main steps:
+Figure \cref{fig:scenario_flow} illustrates the \gls{apdu} fuzzing workflow, which we structured into four main steps:
 
 \begin{enumerate}
   \item \textbf{Mutation selection:} The operation recorder decides the next mutation to apply based on a depth-first traversal of the mutation tree. If all mutations for the current function are exhausted, the runner searches for unexplored child nodes.
-  \item \textbf{\gls{apdu} mutation:} The selected mutation is applied to the original \gls{apdu} using the mutation engine.
-  \item \textbf{\gls{apdu} transmission:} The mutated \gls{apdu} is sent to the card. Success or failure is recorded in the current node.
-  \item \textbf{Recording:} The response (or exception) is saved to the mutation tree node for further analysis.
+  \item \textbf{\gls{apdu} mutation:} We apply the selected mutation to the original \gls{apdu} using the mutation engine.
+  \item \textbf{\gls{apdu} transmission:} The mutated \gls{apdu} is sent to the \gls{euicc}. We record success or failure in the current mutation tree node.
+  \item \textbf{Recording:} We save the response or exception in the corresponding mutation tree node for further analysis.
 \end{enumerate}
 
-This process repeats for all functions defined in the scenario, resulting in a complete mutation tree (see \cref{fig:tree_structure}) that captures all inputs, outputs, and error states.
+We repeat this process for all functions defined in the scenario, producing a complete mutation tree (see \cref{fig:tree_structure}) that captures all inputs, outputs, and error states.
 
 \begin{figure}
 	\centering
@@ -549,7 +562,7 @@ def test_get_profiles(self, use_iccid, profile_class, tags):
 This approach preserves the semantics and structure of the expected \gls{asn1} types while still allowing a wide variety of edge cases to be exercised.
 
 \paragraph{Implementation Scope}
-Due to reliance on external infrastructure, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Fuzzing requests directed at the \gls{smdpp} may lead to excessive traffic and could be misinterpreted as \gls{dos} attempts. Therefore, our tests are restricted to those functions in the ES10a, ES10b, and ES10c interfaces which accept structured input arguments and interact directly with the \gls{euicc}.
+Due to reliance on external infrastructure, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Fuzzing requests directed at the \gls{smdpp} would lead to excessive traffic and could be misinterpreted as \gls{dos} attempts. Therefore, our tests are restricted to those functions in the ES10a, ES10b, and ES10c SGP.22 interfaces which accept structured input arguments and interact directly with the \gls{euicc}.
 
 Specifically, we implemented fuzzing tests for the following functions:
 \begin{itemize}
@@ -559,7 +572,7 @@ Specifically, we implemented fuzzing tests for the following functions:
 \end{itemize}
 
 \paragraph{Fuzzing Lifecycle}
-Each fuzzing test class is executed under a shared fixture. During the \texttt{setUpClass} phase, a PC/SC link is initialized, and the \gls{euicc} is prepared (e.g., by installing a test profile) to ensure the preconditions for each function are met. After executing the class's test suite, the \texttt{eUICCMemoryReset} function is called with all reset options enabled to restore a clean state. All leftover notifications are processed to leave the card in a consistent state for subsequent tests.
+During the \texttt{setUpClass} phase, a PC/SC link is initialized, and the \gls{euicc} is prepared (\eg, by installing a test profile) to ensure the preconditions for each function are met. After executing the class's test suite, the \texttt{eUICCMemoryReset} function is called with all reset options enabled to restore a clean state. All leftover notifications are processed to leave the card in a consistent state for subsequent tests.
 
 \paragraph{Error Classification}
 According to the SGP.22 specification, many functions may return a generic \texttt{UndefinedError} in response to unexpected or malformed input. In our implementation, exceptions raised by the \gls{euicc} that map to well-defined error codes (i.e., subclasses of \texttt{EuiccException}) are not treated as test failures. These represent handled errors indicating that the input was invalid but the card responded appropriately.
@@ -567,7 +580,7 @@ According to the SGP.22 specification, many functions may return a generic \text
 By contrast, when an \texttt{UndefinedError} is returned, we treat this as a potential indicator of an unhandled internal error or inconsistent implementation behavior. These cases are flagged for further investigation. Additionally, exceptions occurring outside the \gls{euicc}, such as Python \texttt{AssertionError}s or test harness failures, are treated as bugs in the testing infrastructure and are logged separately.
 
 \paragraph{Conclusion}
-By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{subsec:differential_testing}.
+By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{sec:data_fuzzing_evaluation}.
 
 
 \section{CLI}

Chapters/Introduction.tex

@@ -59,7 +59,7 @@ These implementation-specific deviations pose significant security risks. \glspl
 
 Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015~\cite{gsma_sgp21_2015} and the latest version (v3.1) being released in 2025~\cite{gsma_sgp22_2025}, the technology is still evolving. Different vendors may interpret and implement the specifications in slightly different ways, leading to inconsistencies and potentially exploitable gaps.
 
-Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach: it systematically compares how different implementations behave when subjected to identical or similar inputs. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
+Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach: it systematically compares how different implementations behave when subjected to identical or similar inputs \cite{mckeeman_differential_1998}. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
 
 This thesis aims to close the gap in independent, systematic analysis of commercial eSIM-on-SIM implementations. It proposes and demonstrates a differential testing framework that facilitates the black-box evaluation of these implementations in terms of correctness and security.
 

Graphics/data/shannon_entropy_estk_me_t000v06_3_4_3.dat

@@ -0,0 +1,202 @@
+7.156588269538145
+7.058692199270098
+7.161552894720955
+7.178601832129551
+7.183855652316841
+7.160808251809458
+7.135946814400863
+7.165772876992269
+7.168230652316841
+7.232154589725436
+7.168620751809458
+7.204344373011516
+7.083564355282828
+7.1575702774996515
+7.197565710927493
+7.080225476484885
+7.176043152316841
+7.266353369030762
+7.264438427641414
+7.169654589725436
+7.160808251809458
+7.08890836135412
+7.210241931622168
+7.227290869030762
+7.159927148336088
+7.181296972504132
+7.134522876992269
+7.128134314400863
+7.094579273518899
+7.238933251809458
+7.190396949350855
+7.119541615415629
+7.100223193198806
+7.188075634588154
+7.137861755790212
+7.152605652316841
+7.171569531114784
+7.14414941389348
+7.140810535095537
+7.169501855282828
+7.198056714908246
+7.27608081042011
+7.171569531114784
+7.154910693198806
+7.124304431622167
+7.180906873011516
+7.037723193198806
+7.226257031114784
+7.271217089725436
+7.20051449023282
+7.160418152316841
+7.143205761861503
+7.186804431622167
+7.282859472504132
+7.177467089725436
+7.218054431622167
+7.195007031114784
+7.094969373011515
+7.13953933212955
+7.195007031114784
+7.206802148336088
+7.203853369030762
+7.241882031114784
+7.155791796672176
+7.149013134588154
+7.241882031114784
+7.090596656297595
+7.160909156297594
+7.19883691389348
+7.154029589725436
+7.218444531114784
+7.180906873011516
+7.15977441389348
+7.248423328148798
+7.141353369030762
+7.104696814400864
+7.153639490232819
+7.20292043560292
+7.134912976484886
+7.298247107454124
+7.20832699023282
+7.065244214908246
+7.178601832129551
+7.122880494213573
+7.166162976484886
+7.170145593706189
+7.195007031114784
+7.180906873011515
+7.277114648336088
+7.104696814400863
+7.167840552824225
+7.175162048843471
+7.210632031114784
+7.113933251809458
+7.173484472504132
+7.146217089725436
+7.210241931622168
+7.230239648336088
+7.207683251809458
+7.207293152316842
+7.177076990232819
+7.21446191389348
+7.194464197179559
+7.204835376992268
+7.112119214908247
+7.169501855282828
+7.179873035095537
+7.181940710927493
+7.14823293560292
+7.193092089725436
+7.148132031114784
+7.224442994213572
+7.214071814400863
+7.134912976484885
+7.198937818381616
+7.198937818381616
+7.173094373011516
+7.181940710927494
+7.110984472504132
+7.104306714908247
+7.130540259770965
+7.202429431622167
+7.172060535095538
+7.201785693198806
+7.192549255790211
+7.238933251809458
+7.140810535095537
+7.273132031114784
+7.228171972504132
+7.144403052824225
+7.195650769538145
+7.150046972504132
+7.140319531114784
+7.178991931622167
+7.264438427641414
+7.183855652316841
+7.173484472504132
+7.153876855282828
+7.203700634588154
+7.207683251809458
+7.173094373011516
+7.172603369030762
+7.131083093706189
+7.164084582048793
+7.19270199023282
+7.189109472504132
+7.154520593706189
+7.161842089725436
+7.257507031114784
+7.170535693198806
+7.127100476484885
+7.157859472504132
+7.138895593706189
+7.084699097686943
+7.140319531114784
+7.26045581042011
+7.191278052824225
+7.155944531114784
+7.130049255790211
+7.218291796672176
+7.135065710927493
+7.170145593706189
+7.139929431622168
+7.180263134588154
+7.181940710927493
+7.184245751809458
+7.094426539076291
+7.090986755790212
+7.120321814400864
+7.101257031114784
+7.185279589725436
+7.117373035095537
+7.187685535095537
+7.244440710927494
+7.121999390740202
+7.095359472504132
+7.207683251809458
+7.053058998194325
+7.201395593706189
+7.222918152316842
+7.192701990232819
+7.233188427641414
+7.116729296672176
+7.097918152316841
+7.114814355282828
+7.0697178361103035
+7.2084278947209555
+7.106120751809458
+7.098308251809458
+7.098308251809458
+7.119440710927494
+7.102138134588154
+7.09202059370619
+7.138895593706189
+7.084445458756198
+7.164638134588154
+7.04602669717956
+7.173975476484885
+7.120965552824224
+7.114260802743468
+7.160418152316841
+5.698891666829028

Graphics/data/shannon_entropy_estk_me_t001v06_3_4_3.dat

@@ -0,0 +1,202 @@
+7.149656873011515
+7.152442199270098
+7.169264490232819
+7.18321191389348
+7.169654589725436
+7.07880153907629
+7.279673328148798
+7.103035511942259
+7.280944531114784
+7.116339197179559
+7.167033361354119
+7.144403052824225
+7.19795581042011
+7.099442994213573
+7.129168152316841
+7.123270593706189
+7.134421972504132
+7.146708093706189
+7.189600476484886
+7.146217089725436
+7.042196814400863
+7.292349548843472
+7.103272876992269
+7.223308251809458
+7.074971656297595
+7.254558251809458
+7.115067994213573
+7.22139331042011
+7.064600476484885
+7.22832470694674
+7.074971656297595
+7.155554431622168
+7.143759314400863
+7.20576831042011
+7.14414941389348
+7.180415869030762
+7.252744214908247
+7.16297683212955
+7.107645593706188
+7.195007031114784
+7.198446814400863
+7.18641433212955
+7.176924255790212
+7.171179431622168
+7.156435535095537
+7.021555359263581
+7.170535693198806
+7.180025769538146
+7.209208093706189
+7.141353369030762
+7.136980652316841
+7.221884314400864
+7.19014331042011
+7.119931714908246
+7.148775769538146
+7.194226832129551
+7.180025769538146
+7.165671972504132
+7.092020593706189
+7.1126102188889995
+7.171569531114784
+7.146064355282828
+7.11983081042011
+7.109560535095537
+7.143115575977502
+7.144793152316841
+7.13545581042011
+7.219579273518898
+7.209750927641414
+7.067549255790211
+7.19014331042011
+7.187685535095538
+7.183465552824225
+7.190634314400863
+7.157305919964772
+7.274165869030762
+7.062396340091057
+7.164248035095536
+7.096240575977502
+7.157960376992268
+7.06858309370619
+7.249304431622167
+7.072022876992268
+7.217410693198806
+7.218054431622168
+7.164248035095538
+7.13020199023282
+7.192058251809458
+7.18641433212955
+7.209750927641414
+7.111238111434876
+7.329497107454123
+7.228815710927493
+7.208717089725436
+7.169654589725436
+7.251609472504132
+7.191668152316841
+7.177567994213572
+7.15977441389348
+7.137370751809457
+7.198989648336088
+7.192159156297594
+7.158994214908247
+7.027995751809458
+7.120321814400863
+7.146369824168044
+7.089816457312359
+7.211513134588154
+7.133641773518899
+7.09202059370619
+7.068092089725436
+7.272250927641414
+7.152995751809458
+7.128134314400863
+7.142234472504132
+7.212156873011516
+7.131625927641414
+7.096884314400864
+7.176433251809458
+7.149656873011515
+7.106611755790211
+7.267878210927494
+7.064363111434877
+7.194616931622167
+7.263404589725436
+7.25176220694674
+7.189210376992269
+7.134421972504132
+7.077276697179559
+7.078310535095537
+7.177567994213572
+7.149013134588154
+7.204344373011516
+7.177467089725436
+7.144793152316841
+7.0697178361103035
+7.120321814400863
+7.202429431622168
+7.193583093706189
+7.160808251809458
+7.142234472504132
+7.178348193198806
+7.152114648336088
+7.140810535095538
+7.210241931622168
+7.17451831042011
+7.189109472504132
+7.139929431622167
+7.22920581042011
+7.228815710927493
+7.188329273518899
+7.168230652316841
+7.174128210927493
+7.235594373011516
+7.124694531114784
+7.139929431622167
+7.147098193198806
+7.151571814400863
+7.215495751809458
+7.147741931622168
+7.162333093706189
+7.225866931622168
+7.148132031114784
+7.217410693198806
+7.152605652316841
+7.169755494213573
+7.258540869030762
+7.152114648336088
+7.087546972504132
+7.173484472504132
+7.141555178007033
+7.17860183212955
+7.113543152316841
+7.0941891740262815
+7.202429431622167
+7.119931714908247
+7.283503210927493
+7.238052148336088
+7.19422683212955
+7.117763134588154
+7.169365394720955
+7.18488949023282
+7.236238111434876
+7.265472265557392
+7.169111755790211
+7.185279589725436
+7.233188427641414
+7.189600476484885
+7.191668152316842
+7.171670435602921
+7.160909156297595
+7.173585376992269
+7.193583093706189
+7.124304431622167
+7.178348193198806
+7.124694531114784
+7.165281873011515
+7.161842089725436
+7.155554431622167
+7.109560535095538
+7.157960376992269
+5.796788587150238

Graphics/data/shannon_entropy_estk_me_t002v06_3_4_3.dat

@@ -0,0 +1,202 @@
+7.134031873011516
+7.195888134588154
+7.151571814400863
+7.310279589725436
+7.274165869030762
+7.196531873011516
+7.202819531114784
+7.1009678361103035
+7.04258691389348
+7.170145593706189
+7.164638134588154
+7.140963269538145
+7.171179431622167
+7.160808251809458
+7.219478369030762
+7.164891773518898
+7.176043152316842
+7.109950634588154
+7.136980652316841
+7.219969373011516
+7.185279589725436
+7.191668152316841
+7.146708093706189
+7.231120751809458
+7.18233081042011
+7.185923328148797
+7.125829273518899
+7.230340552824225
+7.096884314400863
+7.29170581042011
+7.10764559370619
+7.17014559370619
+7.165281873011515
+7.208717089725436
+7.15205209977748
+7.219969373011515
+7.208174255790212
+7.17795809370619
+7.038214197179559
+7.227290869030762
+7.223308251809458
+7.219325634588154
+7.219088269538145
+7.140963269538145
+7.168620751809458
+7.223951990232819
+7.06858309370619
+7.187295435602921
+7.186160693198806
+7.196040869030762
+7.195007031114784
+7.247779589725436
+7.15977441389348
+7.146317994213572
+7.130049255790212
+7.149266773518899
+7.188228369030762
+7.186414332129551
+7.109560535095537
+7.13545581042011
+7.209851832129551
+7.122626855282828
+7.216139490232819
+7.319125927641414
+7.066515417874233
+7.192058251809458
+7.143369214908247
+7.279910693198806
+7.283503210927493
+7.16670581042011
+7.219478369030762
+7.163203478575423
+7.154520593706189
+7.173484472504132
+7.174619214908246
+7.161942994213573
+7.070107935602921
+7.211275769538145
+7.157859472504132
+7.211665869030762
+7.175653052824225
+7.174128210927493
+7.222918152316841
+7.115458093706189
+7.237662048843472
+7.286842089725436
+7.135556714908247
+7.175009314400863
+7.219969373011516
+7.185380494213572
+7.227290869030762
+7.208717089725436
+7.228815710927493
+7.139285693198806
+7.162875927641414
+7.208717089725436
+7.095714015923013
+7.171179431622167
+7.185380494213573
+7.139929431622167
+7.132507031114784
+7.143369214908247
+7.232154589725436
+7.269793152316842
+7.258540869030762
+7.192058251809458
+7.184736755790211
+7.102781873011516
+7.24483081042011
+7.03565551736685
+7.194616931622167
+7.117915869030762
+7.202920435602921
+7.139539332129551
+7.203853369030762
+7.152995751809458
+7.211766773518898
+7.214224548843471
+7.19014331042011
+7.198209449350854
+7.238543152316841
+7.216529589725436
+7.290434607454123
+7.228171972504132
+7.188719373011515
+7.169654589725436
+7.145183251809458
+7.155881982556177
+7.273132031114784
+7.131473193198806
+7.174128210927494
+7.218444531114784
+7.219088269538145
+7.22920581042011
+7.098308251809458
+7.188719373011516
+7.192939355282828
+7.1782117326369335
+7.15977441389348
+7.196921972504132
+7.295688427641414
+7.170535693198806
+7.070498035095537
+7.176924255790211
+7.146555359263581
+7.157469373011516
+7.125422900145546
+7.228815710927494
+7.205378210927493
+7.1000867326369335
+7.161842089725436
+7.201395593706189
+7.143759314400864
+7.233188427641414
+7.280063427641414
+7.215105652316841
+7.129558251809458
+7.126609472504132
+7.152995751809458
+7.087647876992268
+7.139929431622168
+7.129168152316842
+7.241882031114784
+7.129558251809458
+7.14503051736685
+7.195007031114784
+7.121745751809458
+7.194616931622167
+7.258641773518899
+7.247779589725436
+7.155944531114784
+7.1664166154156295
+7.180415869030762
+7.155944531114784
+7.248423328148797
+7.238052148336088
+7.158994214908246
+7.300552148336088
+7.147098193198806
+7.151571814400864
+7.178601832129551
+7.29170581042011
+7.165772876992269
+7.218444531114784
+7.172450634588154
+7.168230652316842
+7.147098193198806
+7.25264331042011
+7.208717089725436
+7.218444531114784
+7.187194531114784
+7.210632031114784
+7.212546972504132
+7.268912048843472
+7.214071814400863
+7.233188427641414
+7.231374390740203
+7.180415869030762
+7.138505494213573
+7.056787976484886
+7.139285693198806
+5.778743478485942