Update on Overleaf.

Appendices/SomeProof.tex

@@ -20,7 +20,7 @@
 % 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 SGP.22 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:
+Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The SGP.22 specification defines a comprehensive set of error codes, many of which are reused across different functions.\marginpar{Exceptions are categorized by function context and specific error type.} 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).
@@ -30,7 +30,7 @@ Robust exception handling is critical in the context of \gls{euicc} interactions
 All exceptions inherit from a common \texttt{EuiccException} base class, ensuring they can be captured uniformly when needed.
 
 \subsection*{Exception Hierarchy}
-
+\marginpar{Hierarchy enables both broad and precise exception handling.}
 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}
@@ -86,6 +86,7 @@ class IccidOrAidNotFound(EuiccException):
 \subsection*{Benefits}
 
 This exception model provides the following advantages:
+\marginpar{Clean exception abstraction improves introspection during fuzzing and test execution.}
 \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}).
@@ -100,11 +101,11 @@ This exception system enables detailed introspection during fuzzing and testing
 \label{sec:cli_structure}
 The CLI is organized around three core commands:
 \begin{itemize}
-    \item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.
+    \item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.\marginpar{CLI provides tracing, lpa, and fuzzing commands for core system interaction.}
     \item \textbf{lpa} — Exposes \gls{euicc} communication features such as profile management, notification handling, and remote procedure execution via the \gls{cli}.
     \item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in JSON format.
 \end{itemize}
-
+\marginpar{Each CLI command resides in a dedicated subfolder.}
 Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in \cref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
 
 \begin{figure}[h]
@@ -186,7 +187,7 @@ Each subcommand module (e.g., \texttt{fuzz/data\_fuzz.py}) provides its own pars
 \section{APDU Status Word Codes}
 \label{sec:sw_codes}
 
-In the context of \gls{apdu} communication with \glspl{euicc}, each Response-APDU (R-APDU) from the card ends with a two-byte Status Word (SW), which indicates the outcome of the command execution. The SW is encoded as a 16-bit hexadecimal value and follows the ISO/IEC 7816-4 specification \cite{isoiec_isoiec_2006}.
+In the context of \gls{apdu} communication with \glspl{euicc}, each Response-APDU (R-APDU) from the card ends with a two-byte Status Word (SW), which indicates the outcome of the command execution.\marginpar{Each R-APDU ends with a 16-bit Status Word indicating command execution outcome.} The SW is encoded as a 16-bit hexadecimal value and follows the ISO/IEC 7816-4 specification \cite{isoiec_isoiec_2006}.
 
 Some SW codes contain fixed values, whereas others use placeholders (represented as \texttt{??} or \texttt{XX}) to indicate that specific bits may vary, often encoding additional information such as a retry count or the number of bytes remaining. \cref{tab:sw_codes} provides an overview of some of the most frequently observed status words.
 
@@ -194,7 +195,7 @@ Some SW codes contain fixed values, whereas others use placeholders (represented
 \centering
 \begin{tabular}{|c|p{10cm}|}
 \hline
-\textbf{SW Code} & \textbf{Meaning} \\
+\textbf{SW Code} & \textbf{Description} \\
 \hline
 \texttt{9000} & Normal ending of the command. This indicates that the command was executed successfully and no further action is required. \\
 \texttt{61XX} & Command executed successfully; \texttt{XX} bytes of data are available for retrieval using a subsequent \texttt{GET RESPONSE} command. \\