Update on Overleaf.

Chapters/Design.tex

@@ -65,6 +65,7 @@ This section introduces the core design of our differential testing framework \s
     \item Mutating protocol-level inputs to explore edge cases and verify robustness,
     \item Comparing card responses under similar inputs to identify differences.
 \end{itemize}
+\marginpar{\sysname is the differential testing framwork for eSIM analysis}
 
 To achieve these goals, we propose a modular three-layered architecture:
 
@@ -80,6 +81,7 @@ To achieve these goals, we propose a modular three-layered architecture:
 The first design focuses on capturing and replaying real interaction sequences between an \gls{lpa} and a target \gls{euicc}. This allows deterministic replay of recorded \gls{apdu} sequences on different cards for side-by-side comparison.
 
 \paragraph{Design Rationale.} Real-world traces provide insights into how \glspl{euicc} are used in practice, including undocumented behavior not covered by specifications. Replaying identical \gls{apdu} sequences across cards enables direct differential testing. To ensure realistic conditions, the setup is designed to remain as close as possible to the original communication path between \gls{lpa} and \gls{euicc}.
+\marginpar{Design 1 replays real LPA–eUICC interactions for side-by-side card comparison.}
 
 \paragraph{Key Components.}
 \begin{itemize}
@@ -96,6 +98,7 @@ The first design focuses on capturing and replaying real interaction sequences b
 The second design focuses on exploring the input space of the \gls{euicc} \gls{rsp} protocol stack by mutating valid \glspl{apdu}. The aim is to test robustness against malformed, unexpected, or edge-case inputs and to expose implementation-level inconsistencies.
 
 \paragraph{Design Rationale.} While real traces offer insight into typical usage, they often fail to reveal vulnerabilities related to invalid inputs. \gls{apdu} fuzzing is essential for testing the correctness of error handling and boundary enforcement.
+\marginpar{Design 2 mutates valid APDUs to test eUICC robustness and correctness by comparing recorded behavior.}
 
 \paragraph{Key Components.}
 \begin{itemize}
@@ -103,7 +106,7 @@ The second design focuses on exploring the input space of the \gls{euicc} \gls{r
     \item \textbf{Mutation Engine:} Valid \glspl{apdu} are mutated using deterministic and randomized strategies, including bit-flipping, truncation, data zeroing, byte replacement, and block shuffling.
     \item \textbf{Mutation Tree Representation:} The fuzzer constructs a hierarchical tree representing each function call, input mutation, and observed result, supporting exhaustive and resumable test runs.
     \item \textbf{Exception-Aware Runner:} Each test is isolated, and card resets are used to restore a clean state, preventing a single failure from corrupting the session.
-    \item \textbf{Comparison Engine:} Results from multiple \glspl{euicc} are compared node-by-node. Deviations in status words, exceptions or data are reported and visualized to highlight divergent execution paths.
+    \item \textbf{Comparison:} Results from multiple \glspl{euicc} are compared node-by-node. Deviations in status words, exceptions or data are reported and visualized to highlight divergent execution paths.
 \end{itemize}
 
 \paragraph{Motivation.} \gls{apdu} fuzzing allows systematic probing of error-handling logic, \gls{asn1} decoding boundaries, and specification ambiguities. The use of deterministic strategies supports reproducibility and enables direct comparison across different cards.
@@ -114,6 +117,7 @@ The second design focuses on exploring the input space of the \gls{euicc} \gls{r
 The third design targets application-level logic using structurally valid inputs. It leverages property-based testing to exercise schema-conformant payloads and detect semantic inconsistencies or robustness issues.
 
 \paragraph{Design Rationale.} Data fuzzing explores the validity boundaries of specific protocol fields. Unlike raw \gls{apdu} mutation, it focuses on high-level, syntactically valid but semantically unusual inputs to stress the logic of the \gls{lpa}-\gls{euicc} interaction.
+\marginpar{Design 3 targets semantic correctness using schema-conformant, high-level input fuzzing.}
 
 \paragraph{Key Components.}
 \begin{itemize}
@@ -155,6 +159,7 @@ Each of the three design strategies presented in this chapter targets a differen
 \textbf{Tracing and Replay} focuses on the deterministic reproduction of real-world \gls{lpa}-\gls{euicc} sessions. By replaying fully valid \gls{apdu} sequences captured from live devices, this strategy ensures strict behavioral equivalence and reproducibility. However, it is limited in its ability to explore malformed or edge-case inputs.
 
 \textbf{APDU-Level Fuzzing} extends this foundation by introducing structured mutations into valid \glspl{apdu}. It strikes a balance between input validity and exploratory depth, allowing the framework to probe robustness, error-handling routines, and implementation-specific divergences while still supporting comparative analysis across multiple \glspl{euicc}.
+\marginpar{Each design targets a distinct dimension of eUICC differential testing and by combination yields a broad, modular fuzzing and testing framework.}
 
 \textbf{Structured Data Fuzzing}, finally, operates at the semantic layer by generating well-formed but edge-case-rich inputs for application-level interfaces. This approach excels at uncovering logic flaws and inconsistencies in the parsing and interpretation of complex data structures, particularly those encoded in \gls{asn1}.