Update on Overleaf.

AdditionalPackages.tex

@@ -79,3 +79,36 @@
 
 % SVGs
 \usepackage{svg}
+
+% lstlistings
+\definecolor{eclipseStrings}{RGB}{42,0.0,255}
+\definecolor{eclipseKeywords}{RGB}{127,0,85}
+\colorlet{numb}{magenta!60!black}
+
+\lstdefinelanguage{json}{
+    basicstyle=\normalfont\ttfamily,
+    commentstyle=\color{eclipseStrings}, % style of comment
+    stringstyle=\color{eclipseKeywords}, % style of strings
+    numbers=left,
+    numberstyle=\scriptsize,
+    stepnumber=1,
+    numbersep=8pt,
+    showstringspaces=false,
+    breaklines=true,
+    frame=lines,
+    backgroundcolor=\color{gray}, %only if you like
+    string=[s]{"}{"},
+    comment=[l]{:\ "},
+    morecomment=[l]{:"},
+    literate=
+        *{0}{{{\color{numb}0}}}{1}
+         {1}{{{\color{numb}1}}}{1}
+         {2}{{{\color{numb}2}}}{1}
+         {3}{{{\color{numb}3}}}{1}
+         {4}{{{\color{numb}4}}}{1}
+         {5}{{{\color{numb}5}}}{1}
+         {6}{{{\color{numb}6}}}{1}
+         {7}{{{\color{numb}7}}}{1}
+         {8}{{{\color{numb}8}}}{1}
+         {9}{{{\color{numb}9}}}{1}
+}

Appendices/SomeProof.tex

@@ -9,4 +9,87 @@
 \chapter{Some Proof}\label{ch:SomeProof}
 \glsresetall % Resets all acronyms to not used
 
-\lipsum[8]
+\section{Exception Handling}
+\label{sec:exception-handling}
+
+% Idea: have exception class which inherits from EuiccException base class -> class has mapping from error code to exception
+% erorrs are reused by other functions -> have errors inherit from base class and function based errors raise these errors -> restructure inheritence before raising so that inheritence order is: ErrorException <- FunctionException <- common EuiccBaseException
+% ErrorException can be like IccidOrAidNotFound Exception and function exception can be something like ProfileInteractionException
+% Goal: Capture all exception that are possibly raised by a function but still have access to more granualar exception handling
+% lising1 shows CodeBaseException from which the functionexceptions inherit: restructures exception inheritance from error_map to have all mapped exception inherit from the functionexception instead of the common base exception
+% listing2 shows implemention of a function exception class with a fill error_map and some example error exception
+
+
+Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The \gls{sgp22} specification defines a comprehensive set of error codes, many of which are reused across different functions. To allow both coarse-grained and fine-grained error handling, the exception hierarchy in our implementation is explicitly structured around two core ideas:
+
+\begin{itemize}
+  \item \textbf{Function-based exceptions} encapsulate the context in which the error occurred (e.g., Profile Management, \gls{isdr} interactions).
+  \item \textbf{Error-based exceptions} represent the specific error raised (e.g., \gls{iccid} not found, \gls{aid} missing).
+\end{itemize}
+
+All exceptions inherit from a common \texttt{EuiccException} base class, ensuring they can be captured uniformly when needed.
+
+\subsection*{Exception Hierarchy}
+
+The exception hierarchy is structured such that all specific error exceptions (e.g., \texttt{IccidNotFound}) inherit from a relevant function exception (e.g., \texttt{ProfileInteractionException}), which itself inherits from \texttt{EuiccException}. This enables both precise and broad exception matching depending on the caller’s needs. For example:
+
+\begin{center}
+\texttt{EuiccException} $\rightarrow$ \texttt{ProfileInteractionException} $\rightarrow$ \texttt{IccidOrAidNotFound}
+\end{center}
+
+This structure is illustrated in \cref{lst:code-base-exception} and \cref{lst:function-exception}.
+
+\begin{lstlisting}[language=python,label={lst:code-base-exception},caption={Class to raise exception based on the error code and restructure the inheritance.}]
+class CodeBaseException(EuiccException):
+    """Base class for all exceptions raised by the result handling."""
+
+    message: str = "An unknown code error occurred"
+    error_map: dict[int, Type['EuiccException']]
+
+    def __init__(self, message: str | None = None):
+        if message:
+            self.message = message
+
+        super().__init__(self.message)
+
+    @classmethod
+    def raise_from_code(cls, code: int):
+        """Raises the appropriate exception subclass based on the error code."""
+        exception_class = cls.error_map.get(code, UndefinedError)
+        exception_class.__bases__ = (cls,)
+
+        raise exception_class()
+\end{lstlisting}
+
+\begin{lstlisting}[language=python,label={lst:function-exception},caption={Implementation of the \lstinline{CodeBaseException} Class.}]
+class ProfileInteractionException(CodeBaseException):
+    """Base class for all exceptions raised by the profile handling."""
+
+    message: str = "An unknown profile interaction error occurred"
+    error_map = {
+        1: IccidOrAidNotFound,
+        2: ProfileNotInEnabledState,
+        3: DisallowedByPolicy,
+        4: WrongProfileReenabling,
+        5: CatBusy,
+        6: DisallowedByEnterpriseRule,
+        7: CommandError,
+        8: DisallowedForRpm,
+        9: NoEsimPortAvailable,
+        127: UndefinedError,
+    }
+    
+class IccidOrAidNotFound(EuiccException):
+    message = "ICCID or AID not found"
+\end{lstlisting}
+
+\subsection*{Benefits}
+
+This exception model provides the following advantages:
+\begin{itemize}
+  \item \textbf{Modular extensibility:} New error types can be added per function with minimal changes.
+  \item \textbf{Granular diagnostics:} Developers can differentiate between general failure (\texttt{ProfileInteractionException}) and specific causes (\texttt{IccidNotFoundException}).
+  \item \textbf{Cleaner call sites:} Exceptions can be caught using either the general or specific class depending on context.
+\end{itemize}
+
+This exception system enables detailed introspection during fuzzing and testing while maintaining a clean abstraction between components.

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}