Update on Overleaf.

Chapters/Implementation.tex

@@ -189,6 +189,53 @@ 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 \gls{sgp22} v3.1 specification, which was the latest version available at the time of writing.
+
+The \gls{lpa} is composed of multiple components:
+
+\paragraph{Card}
+Represents the \gls{euicc} currently inserted into the \gls{pcsc} card reader. Upon initialization, it scans the card for supported applications, identifying the applicable \gls{adf} through probing. This is necessary as eSIM-on-SIM implementations often use proprietary \glspl{adf}, diverging from the \glspl{adf} specified in the \gls{sgp22} standard. The card object keeps track of the selected application to reduce unnecessary reselection and traffic.
+
+\paragraph{PC/SC Link}
+This component is based on \texttt{pySim}'s \texttt{LinkBaseTpdu}. It establishes an exclusive connection to the \gls{pcsc} reader to maintain session state consistency, which is required due to the stateful nature of \gls{euicc} interactions. During initialization:
+\begin{itemize}
+  \item The supported transmission protocol (T=0 or T=1) is detected.
+  \item A connection is established and validated.
+\end{itemize}
+It handles both \gls{apdu} and \gls{tpdu} transmission, automatically requesting additional data when status words such as \texttt{9FXX}, \texttt{61XX}, \texttt{62XX}, or \texttt{63XX} are encountered. When enabled, it invokes an optional mutation engine before sending \glspl{apdu} (see \cref{subsec:apdu_fuzzing}) and also records all traffic for later analysis.
+
+\paragraph{Application}
+Each euicc application (e.g., \gls{isdr}, \gls{ecasd}, ESTK firmware update) is implemented with application-specific logic and communicates with the card via the \texttt{pcsc\_link}. The application layer abstracts encoding/decoding and command sending. For instance, the \texttt{store\_data} command is handled internally using \texttt{asn1tools} for encoding and decoding.
+
+Known \glspl{adf} for \gls{isdr} observed during analysis:
+\begin{itemize}
+  \item Common: \texttt{A0000005591010FFFFFFFF8900000100}
+  \item 5Ber.esim: \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. These 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 \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}.
+
+\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:
+\begin{lstlisting}[language=json,caption={ES9+ Request Headers}]
+{
+  "Content-Type": "application/json",
+  "User-Agent": "gsma-rsp-lpad",
+  "X-Admin-Protocol": "gsma/rsp/v3.1.0"
+}
+\end{lstlisting}
+
+Payload values are Base64-encoded as required by the specification. Response data is deserialized using \texttt{pydantic}. Error responses from the server trigger the appropriate exception, as explained previously.
+
+The \gls{smdpp} client is primarily used by the \gls{isdr} application to execute \gls{rsp}-related functionality.
+
 \section{Fuzzing}
 \label{sec:fuzzing}