Update on Overleaf.

Acronyms.tex

@@ -168,3 +168,8 @@
 \newacronym{stk}{STK}{SIM Application Toolkit}
 \newacronym{usat}{USAT}{USIM Application Toolkit}
 \newacronym{rlpa}{RLPA}{Remote Local Profile Assistant}
+\newacronym{pcsc}{PC/SC}{Personal Computer/Smart Card}
+\newacronym{sw}{SW}{Status Word}
+
+\newacronym{gsmtap}{GSMTAP}{GSM Test Access Point}
+\newacronym{gsm}{GSM}{Global System for Mobile Communications}

AdditionalPackages.tex

@@ -76,3 +76,6 @@
 % Lengths for matlab2tikz
 \newlength\figureheight
 \newlength\figurewidth 
+
+% SVGs
+\usepackage{svg}

Bibliography.bib

@@ -49,7 +49,7 @@
 }
 
 @misc{etsi_ts_2023,
-	title = {{TS} 102 221 {V4}.10.0 {UICC}-{Terminal} interface},
+	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}},
@@ -69,7 +69,7 @@
 }
 
 @misc{etsi_ts_2022,
-	title = {{TS} 102 226 {V17}.0.0  {Remote} {APDU} structure for {UICC} based applications},
+	title = {{TS} 102 226  {Remote} {APDU} structure for {UICC} based applications},
 	language = {en},
 	author = {{ETSI}},
 	month = oct,
@@ -521,6 +521,52 @@ C compilers is available on the web.},
 	urldate = {2025-05-18},
 	author = {{ETSI}},
 	month = sep,
-	year = {2024},
+	year = {2014},
 	file = {PDF:/Users/privat/Zotero/storage/2AETCTSV/ts_102223v120100p.pdf:application/pdf},
-}
+}
+
+@misc{etsi_ts_2005,
+	title = {{TS} 151 011 {SIM}-{ME} interface},
+	url = {https://www.etsi.org/deliver/etsi_ts/151000_151099/151011/04.15.00_60/ts_151011v041500p.pdf},
+	urldate = {2025-05-20},
+	author = {{ETSI}},
+	month = jun,
+	year = {2005},
+	file = {PDF:/Users/privat/Zotero/storage/BY2ZCG4E/ts_151011v041500p.pdf:application/pdf},
+}
+
+@misc{etsi_ts_2023-1,
+	title = {{TS} 102 241 {UICC} {API}},
+	language = {en},
+	author = {{ETSI}},
+	month = aug,
+	year = {2023},
+	file = {PDF:/Users/privat/Zotero/storage/3CTHDWNK/TS 102 241 - V17.5.0 - Smart Cards\; UICC Application Programming Interface (UICC API) for Java Card™.pdf:application/pdf},
+}
+
+@misc{maciver_hypothesis_2019,
+	title = {Hypothesis: {A} new approach to property-based testing},
+	shorttitle = {Hypothesis},
+	url = {https://github.com/HypothesisWorks/hypothesis},
+	abstract = {The property-based testing library for Python},
+	urldate = {2025-05-20},
+	author = {MacIver, David R. and Hatfield-Dodds, Zac and {many other contributors}},
+	month = nov,
+	year = {2019},
+	doi = {10.21105/joss.01891},
+	note = {original-date: 2013-03-10T13:51:19Z},
+	file = {Full Text:/Users/privat/Zotero/storage/M3TAPWCL/MacIver et al. - 2019 - Hypothesis A new approach to property-based testing.pdf:application/pdf},
+}
+
+@misc{rousseau_pyscard_2025,
+	title = {pyscard},
+	copyright = {LGPL-2.1},
+	url = {https://github.com/LudovicRousseau/pyscard},
+	abstract = {pyscard smartcard library for python},
+	urldate = {2025-05-20},
+	author = {Rousseau, Ludovic},
+	month = may,
+	year = {2025},
+	note = {original-date: 2015-06-16T18:25:06Z},
+	keywords = {apdu, pcsc, pyscard, python, python3, smartcard, smartcard-library, travis-ci},
+}

Chapters/Background.tex

@@ -29,7 +29,7 @@ Java Card applets are applications written in a restricted subset of the Java pr
 
 The operation and functionality of \gls{sim} and \gls{esim} cards are defined and governed by three major standardization bodies: \gls{etsi}, \gls{3gpp}, and the \gls{gsma}. Each of these organizations contributes distinct specifications that together form the foundation of the \gls{sim} ecosystem.
 
-The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the ETSI standard TS 131 221 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi-ts-131-221}.
+The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the ETSI standard TS 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
 
 The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. This includes the specification of \gls{sim} functionalities required for network access in technologies such as \gls{lte}, \gls{5g}, and legacy systems. These standards ensure interoperability between SIMs and network infrastructure across vendors and operators.
 
@@ -192,7 +192,7 @@ This architecture introduces a secure, remote provisioning mechanism and signifi
 
 \begin{figure}[h!]
     \includegraphics[width=\textwidth]{Graphics/euicc_architecture.png}
-    \caption{eUICC architecture~\cite{gsma_sgp22_2024}.}
+    \caption{\gls{euicc} architecture~\cite{gsma_sgp22_2024}.}
     \label{img:euicc_architecture}
 \end{figure}
 
@@ -227,11 +227,11 @@ Together, these components establish the trust and management architecture neces
 % - estk.me also implemented rlpa (remote lpa or as they call it cloud enhance) -> allows the user to provision profiles via the stk / usat menu (cite cloud rlpa-server)
 % other options to provision profiles require an lpa client on the ue / terminal
 
-In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the eSIM operating system, which is supplied by the eUICC manufacturer—they can also be packaged as “physical eSIMs” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical eSIMs in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
+In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the \gls{esim} operating system, which is supplied by the eUICC manufacturer—they can also be packaged as “physical eSIMs” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical \glspl{esim} in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
 
 \paragraph{Application Toolkit}
 
-The SIM/USIM Application Toolkit — collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in ETSI TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for UICC/USIM environments. CAT unifies STK and USAT under a single umbrella for all UICC-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating 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 CAT menus without a separate LPA client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated LPA application on the device.
+The \gls{stk}/\gls{usat} — collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in 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.
 
 
 
@@ -279,9 +279,9 @@ The SIM/USIM Application Toolkit — collectively referred to as the \gls{cat} i
 % - when success response: notification is deleted from euicc
 % - profile provisioning is finished
 
-One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the GSMA in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the RSP ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
+One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the \gls{gsma} in specification \gls{sgp22}~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
 
-The \gls{lpa} is a user-facing application on the 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 eUICC manufacturer, MNO, or third party—that securely hosts eSIM profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach but is less common in consumer scenarios.
+The \gls{lpa} is a user-facing application 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 but is less common in consumer scenarios.
 
 \begin{figure}[h!]
     \includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
@@ -291,32 +291,32 @@ The \gls{lpa} is a user-facing application on the UE that interacts with the \gl
 \footnotetext{The components referred to as the \gls{lpad} in this thesis — namely the \gls{ldsd}, \gls{lpdd}, and \gls{luid} — are collectively simplified and referred to as \gls{lpa} for readability.}
 
 
-SGP.22 defines three RSP initiation methods:
+\gls{sgp22} defines three \gls{rsp} initiation methods:
 \begin{enumerate}
-  \item \textbf{Default Server}: The SM-DP+ address is pre-configured on the eUICC at manufacture time. The user triggers provisioning via the default server.
-  \item \textbf{Authentication Code}: The user is provided with an activation code (containing the SM-DP+ address and optional confirmation code) when purchasing service. The LPA contacts the SM-DP+ and, after mutual authentication, may require entry of the confirmation code.
-  \item \textbf{SM-DS Assisted}: The LPA polls the SM-DS for an event matching the EID of the eUICC. If a download event exists, the SM-DS supplies the SM-DP+ address to the LPA for profile download.
+  \item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time. The user triggers provisioning via the default server.
+  \item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
+  \item \textbf{\gls{smds} Assisted}: The \gls{lpa} polls the \gls{smds} for an event matching the \gls{eid} of the \gls{euicc}. If a download event exists, the \gls{smds} supplies the \gls{smdpp} address to the \gls{lpa} for profile download.
 \end{enumerate}
 
-In this work, we focus on the Authentication Code method due to its prevalence in commercial eSIM deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see Section~\ref{sec:fuzzing})
+In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
 
 \textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
 
 \paragraph{Mutual Authentication}
 
-The RSP process begins with mutual authentication between the eUICC and SM-DP+ over a TLS tunnel established via the LPA. The eUICC generates a random challenge and sends it, along with its CI Root public key certificate, to the SM-DP+. The SM-DP+ responds with a signed version of the challenge, its own certificate subject, a transaction identifier, and a server challenge. The eUICC verifies the signature and certificate chain, signs the activation code’s profile identifier (and other protocol elements), the transaction identifier, the server challenge, and relevant addresses, then returns this to the SM-DP+. Based on the profile identifier, the SM-DP+ selects the appropriate profile for download.
+The \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge and sends it, along with its \gls{ci} Root public key certificate, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge, its own certificate subject, a transaction identifier, and a server challenge. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier (and other protocol elements), the transaction identifier, the server challenge, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
 
 \paragraph{Profile Binding}
 
-Upon successful authentication, the SM-DP+ checks for profile availability and then sends the signed transaction identifier plus the profile-binding key to the eUICC. The eUICC validates the signature against the GSMA CI Root and ensures the certificate is authorized.
+Upon successful authentication, the \gls{smdpp} checks for profile availability and then sends the signed transaction identifier plus the profile-binding key to the \gls{euicc}. The \gls{euicc} validates the signature against the \gls{gsma} \gls{ci} Root and ensures the certificate is authorized.
 
 \paragraph{Profile Download}
 
-Next, the eUICC and SM-DP+ perform an \gls{ecka} to derive session keys. The SM-DP+ encrypts the profile using the session key and transmits it to the eUICC. The eUICC configures the new ISD-P, decrypts the profile, and installs it. The profile is then ready for use.
+Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session keys. The \gls{smdpp} encrypts the profile using the session key and transmits it to the \gls{euicc}. The \gls{euicc} configures the new \gls{isdp}, decrypts the profile, and installs it. The profile is then ready for use.
 
 \paragraph{Notification}
 
-After installation, session keys are erased and the eUICC generates a signed installation notification containing a sequence number and server address. The LPA forwards this notification to the SM-DP+, and upon receiving a success response, the eUICC removes the notification, completing the provisioning cycle.
+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.
 
 
 

Chapters/Implementation.tex

@@ -7,7 +7,7 @@
 
 % - Goal of this thesis is security analysis using differential testing
 % - first idea (naive implementation): use simtrace2 to capture traffic between the LPA (ue) and euicc
-% - simtrace2 sends apdus to socket via udp packet -> read data from socket -> analyse apdu command for instruction type
+% - simtrace2 sends \glspl{apdu} to socket via udp packet -> read data from socket -> analyse apdu command for instruction type
 % - save recored traffic to file 
 % - insert other euicc into pcsc card reader -> replay each apdu to euicc
 % - check for differences in the responses
@@ -16,13 +16,59 @@
 % - use the lpa to produce traffic for the euicc in the pcsc card reader, but mutate it before sending
 % - record the returned status codes and check if different euicc behaves the same (crashes at the same point or returns the same status word)
 % - on the slower side -> rsp is stateful and we rely on the sm-dp+ from the profile vendor
-% - small problem: we basically just fuzz the asn1 parser of the euicc sometimes
+% - small problem with apdu mutation: we basically just fuzz the asn1 parser of the euicc sometimes
 % - alternative: fuzz valid input data
 % - oss-fuzz proposes python hypothesis as a framework for fuzzing via python
 % - python hypothesis: property based testing library -> we define input structure and hypothesis produces data that is valid for the given structure
 % - 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.
+
+\paragraph{Initial Naive Approach}
+
+The first implementation was based on a straightforward 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 this socket, the \gls{apdu} data can be read, parsed, and analyzed.
+
+The proposed method was to:
+\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 \gls{pcsc}-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, this method proved infeasible in practice due to the nature of the \gls{rsp} protocol: many operations are cryptographically bound to the specific session using signed nonces, meaning that replaying recorded traffic is not possible.
+
+\paragraph{Controlled LPA Implementation}
+
+To overcome the limitations of passive traffic replay, a new strategy was developed. Rather than relying on the proprietary \gls{lpa} applications often provided by \gls{esim} vendors, we implemented our own minimal \gls{lpa}. The motivation behind this was twofold:
+
+\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 \gls{pcsc} card reader. Before sending, \glspl{apdu} can be programmatically mutated to evaluate robustness of the implementation against malformed or unexpected inputs. The \gls{lpa} records returned status words and checks for behavioral consistency across different \glspl{euicc}.
+
+While this 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}
+
+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.
+
+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.
+
+This strategy enables testing of:
+\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, the technical details of each implementation component, including the \gls{lpa} logic, mutation framework, and fuzzing harness, are presented.
+
+
+
 \section{Tracing}
 \label{sec:tracing}
 
@@ -31,16 +77,117 @@
 % - replay: replay the previously recorded traffic to euicc in pcsc reader, check for differences in responses
 % parts:
 % - pcsc_link: wrapper for the python smartcard library, handles session establishment to reader, and apdu/tpdu transmission, automatically handles requesting of available data i.e. status word 61XX
-% - card: represents card in the pcsc card reader, identifies card type (i.e sgp22, sgp.22 test, normal sim, etc) and which applications are installed (ISDR, ECASD, etc), used to send apdus to pcsc card through pcsc link
+% - card: represents card in the pcsc card reader, identifies card type (i.e sgp22, sgp.22 test, normal sim, etc) and which applications are installed (ISDR, ECASD, etc), used to send \glspl{apdu} to pcsc card through pcsc link
 % - tracer: dummy implementation of card for instruction interpretation and apdu parsing, uses pysim gsmtap as apdu source
-% - recorder: handles tracer thread and recording of apdus, starts tracer main thread (continously listens for new apdus from gsmtap until timeout is reached or canceld by user) and records apdu to recording, has target isd-r as argument
-% - recording: represents a list of recorded apdus, 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 apdus 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
+% - recorder: handles tracer thread and recording of \glspl{apdu}, starts tracer main thread (continously listens for new \glspl{apdu} from gsmtap until timeout is reached or canceld by user) and records apdu to recording, has target isd-r as argument
+% - 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.
+
+The tracing functionality comprises two main operations:
+
+\begin{itemize}
+    \item \textbf{Tracing and recording:} Captures \glspl{apdu} traffic from a physical interface using \texttt{simtrace2}~\cite{osmocom_simtrace_nodate} and associates it with functional interpretations (e.g., profile enablement, deletion). The \glspl{apdu} are parsed and stored along with contextual information such as sender and receiver addresses.
+    \item \textbf{Replaying:} Replays previously recorded \glspl{apdu} sequences to an \gls{euicc} in a \gls{pcsc} card reader. It replaces context-specific identifiers and checks for discrepancies in response behavior.
+\end{itemize}
+
+\begin{figure}[h!]
+    \includesvg[width=\textwidth]{Graphics/trace_setup.svg}
+    \caption{Tracing lab setup}
+    \label{img:trace_setup}
+\end{figure}
+
+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 \gls{pcsc}-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 \gls{pcsc} 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{Tracer}] A dummy implementation of the \texttt{Card} interface used during passive tracing. It parses incoming \glspl{apdu} from the \gls{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 \gls{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{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.
+\end{description}
+
+This modular structure allows for easy integration into both automated test pipelines and manual inspection tools, and lays the groundwork for both mutation-based and structure-aware fuzzing techniques described in subsequent sections.
+
 
 \section{LPA}
 \label{sec:lpa}
 
-% 
+% due to the limitations of the tracer to replay rsp correctly -> need for lpa to execute interaction with euicc with valid input
+% lpa handles communication over different interfaces as defined in sgp22
+% we are using sgp v3.1 -> newest version at the date of writing this thesis
+% lpa implementation consists of different parts
+
+% card
+% represents euicc that is currently inserted into the pcsc card reader
+% once created: starts scanning for supported applications on the card
+% checks which application responds for which class, instruction code, and adf
+% adf is important: esim on sim applications of deviate from the common adf that is proposed in the sgp22, application implementations contain multiple known adfs -> card selects the one that is used by the euicc
+% handles application selection and keeps track of the currently selected application to prevent reselection or unnecessary traffic
+
+% pcsc link
+% uses the pySim LinkBaseTpdu class as base
+% once initialised it uses given pcsc card reader to establish an exclusive connection to the card reader
+% esclusive connection: euicc have a state -> we would loose state if other cards could perform file sections etc in between -> no shared connection with other programs
+% during the connection process a few steps happen:
+% - check which protocol is supported T=0 or T=1
+% - establish connection via given protocol and check for errors
+% link can be established via a python context manager -> automatically close connection once context is exited
+% handles apdu transmission and tpsu transmission
+% apdu transmission also handles some return codes
+% - 9FXX, 61XX, 62XX, 63XX: automatically request availble response bytes -> reponse bytes are autmatically attached to orignal r-apdu -> to the caller it appears as one apdu even though in the background multiple \glspl{apdu} were send
+% before sending \glspl{apdu} it may also perform mutation by calling the optional mutation engine (ref mutation engine section in  apdu fuzzing)
+% as well as records the \glspl{apdu} (ref apdu fuzzing section)
+
+% application
+% represents euicc application like isd-r, ecasd etc and implements application specific functionality, also handles apdu communication with pcsc link for application related traffic i.e store_data command
+% has main/common adf address and multiple aliases which are used by different vendors for esim implementations
+% ADFs for eSIM on SIM applications that we had access to
+% using simtrace2 and vendor lpa traffic to find out which adf was used for the isd-r
+% Common isd-r adf: A0000005591010FFFFFFFF8900000100
+% 5Ber.esim: A0000005591010FFFFFFFF8900050500
+% Xesim: A0000005591010FFFFFFFF8900000177
+% esim.me: A0000005591010000000008900000300
+% current implementations consist of isd-r/isd-p, estk_fwupd
+
+% applications communicate to card via pcsc link
+% application functions trigger store_data command -> internally uses asn1tools to encode and decode data
+% once data is decoded: application functions use response data specific data classes to parse and validate data
+% these data classes use pydantic for serialization and deserialization as well as decoding and encoding of data -> easier to handle base64 encoded data which often is returned by the smdp+ as well as decode special data such as bitstrings, hex strings as well as version types
+% implemented using custom decoders and encoders -> makes it easier to read data
+% bit strings: chain of bits where each bit represents a function or piece of data that is given or not given -> pydantic serializer mixin makes it easier to represent this information in code and also makes it easier to use this information (i.e when used as library) to check whether a bit is set or not
+% order: data dict -> store_data -> use asn1tools to encode -> build apdu -> send apdu -> decode return data -> parse and decode with data class
+
+%isd-r implementation handles all rsp related functions 
+% estk_fwupd: implements the propriatary estk update mechanism
+% this was reverse engineered and is further explained in the findings section (ref findings section)
+% can return currently installed firmware version, unlock the euicc to accept and new firmare,  install new binary
+% footnote: unlocking the euicc differs from the card unlocking functionality (cite global platform specs which define unlocking) which allows the use of gp commands to for example install new java card applets
+
+%note: maybe explain store_data command in more detail i.e apdu splitting -> indicate that more data follows
+
+% exception handling
+% sgp22 defines a possible errors for interactions
+% euicc returns error code -> user has to know which kind of error was triggered
+% for us its rather important to exactly know which errors were triggered not only to know which of those errors are expected but also to know what went wrong
+% exception handling triggers exact exception based on error code (insert code listing which defines errors and raises them based on the exception)
+
+% smdp client
+% lpa not only handles communication to euicc but also to the smdp+ server -> client side implementation is necessary -> defined as es9+ interface in sgp22
+% uses httpx as base for http communication
+% sgp22 defines that the header should indicate the supported rsp version
+% { "Content-Type": "application/json", "User-Agent": "gsma-rsp-lpad", "X-Admin-Protocol": "gsma/rsp/v3.1.0" }
+% server only accepts json data in body (cite sgp22 definition) -> each value of the key/value pair is base64 encoded 
+% pydantic is used for deserialization of response data
+% 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
 
 \section{Fuzzing}
 \label{sec:fuzzing}

Chapters/RelatedWork.tex

@@ -27,9 +27,9 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
 
 The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \texttt{pySim-read}, \texttt{pySim-prog}, \texttt{pySim-trace}, and \texttt{pySim-smdpp}. Among these, \texttt{pySim-shell} is the core component, offering an interactive shell interface to navigate the \gls{sim} card file system and issue application-specific commands. It supersedes the legacy \texttt{pySim-read} script, which only supports a limited subset of shell commands and is primarily used to extract commonly accessed data fields from \gls{sim} cards.
 
-The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for SIM card-related communication. It integrates with \texttt{simtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording; it does not support active injection or modification of messages.
+The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{simtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording; it does not support active injection or modification of messages.
 
-The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the SGP.22 \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full SGP.22 protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its SGP.22 functionality is restricted to the server role only.
+The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the \gls{sgp22} \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full \gls{sgp22} protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its \gls{sgp22} functionality is restricted to the server role only.
 
 While \texttt{pySim} provides useful standalone utilities, its usability as a general-purpose library is limited. The internal architecture is not optimized for external scripting, requiring substantial effort to perform even basic tasks programmatically. As such, \texttt{pySim} is best suited for interactive use via its provided command-line tools rather than as a cleanly structured library for automation or integration.