Update on Overleaf.

Chapters/Evaluation.tex

@@ -240,7 +240,7 @@ To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to
 
 During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application:
 
-\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.]
+\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.}]
 INFO     Captured MANAGE CHANNEL  Apdu(00 70 00 00 01  01 9000)
 INFO     Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
 INFO     Captured MANAGE CHANNEL  Apdu(00 70 00 00 01  01 9000)
@@ -284,7 +284,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
 \todo{Introduce different setups to make it more obvious when conducting seperate experiments} 
 
 
-\begin{table}[h!]
+\begin{table}[h]
     \centering
     \caption{Data fuzzing results for 5ber, eSIM.me, and EIOTCLUB}
     \label{tab:data_fuzzing_result_part1}
@@ -305,7 +305,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
     \end{tabular}
 \end{table}
 
-\begin{table}[h!]
+\begin{table}[h]
     \centering
     \caption{Data fuzzing results for 9esim, 9esim v2, and Xesim}
     \label{tab:data_fuzzing_result_part2}
@@ -324,6 +324,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
         BoundProfilePackage        & \cmark & \cmark & \cmark \\
         \bottomrule
     \end{tabular}
+    \todo{Merge tables and explain check mark and cross}
 \end{table}
 
 We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case is executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
@@ -417,6 +418,7 @@ Initial fuzzing experiments revealed that applying aggressive mutations across a
 
 \subsection*{Experimental Setup}
 All tests were conducted using a HID OMNIKEY 3121 USB smart card reader.\glspl{esim} were inserted into a Sysmocom 2FF-to-full-size adapter to ensure compatibility with the reader. For consumer-grade \glspl{esim}, the following profile was used:
+\todo{Reference where the profiles are comming from}
 \begin{center}
 \texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7}
 \end{center}
@@ -431,6 +433,7 @@ The execution time of fuzzed \gls{apdu} sequences varied depending on chip proce
 \subsection*{Observed Errors}
 The following classes of errors were consistently encountered during mutation campaigns:
 
+\todo{Put errors into a table with example mutations and explain in text}
 \begin{itemize}
     \item \textbf{SCP03TSecurityError}: Occurred during the \texttt{\justify LoadBoundProfilePackage} step, particularly when transmitting \texttt{sequenceOf86}, \texttt{sequenceOf88}, or the initial \texttt{sequenceOf87}. This indicates failure during Secure Channel Protocol 03 (terminal-side variant) session establishment.
     
@@ -591,7 +594,7 @@ The following classes of errors were consistently encountered during mutation ca
 \subsection{Analysis of Successful Mutations}
 \label{subsec:successful_mutations}
 
-To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
+To further understand the behavior of different \glspl{euicc} \todo{Which euiccs?} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
 
 \subsubsection*{Mutation Examples}
 
@@ -604,6 +607,8 @@ A single-bit mutation changed a byte from \texttt{0xA0} to \texttt{0xA1}. Despit
 \paragraph{AUTHENTICATE\_SERVER Truncation}
 In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServerRequest} \gls{apdu}—removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators; however, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
 
+\todo{Try to find some more fuzzing statistics i.e runs, mutations per second, explored paths}
+
 \subsection{Certificate Validation Bypass}
 \label{subsec:certificate_bypass}
 
@@ -639,7 +644,7 @@ By combining a series of failed and mutated authentication requests, it was poss
 A deeper analysis of mutated \gls{apdu} payloads of the initial \texttt{AuthenticateServerRequest}, particularly in cases using different \gls{smdpp} servers, shows the following:
 
 \begin{itemize}
-    \item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{BF38} tag is flipped to an invalid \texttt{BE38}. Correcting this tag lets us decode the remaining data.
+    \item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{BF38} tag is flipped to an invalid \texttt{BE38}. Correcting this tag provides a valid \gls{asn1} structure and makes the remaining data decodable.
     
     \item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPki\-ToBeUsed}, \texttt{server\-Certificate.\-serial\-Number}, \texttt{server\-Signature1}, and both the \texttt{euicc\-Challenge} and \texttt{server\-Challenge} components of \texttt{server\-Signed1}. This attempt will not be able to pass the bug.
     
@@ -656,7 +661,7 @@ Further experiments showed that this vulnerability persists across sessions and
     
     \item If different profiles from the same \gls{smdpp} are used (e.g., activation codes \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the bypass remains possible.
     
-    \item However, if different \gls{smdpp} servers are used (e.g., \texttt{rsp.truphone.com} vs \texttt{rsp-eu.redteamobile.com}), the attack fails, and the \gls{euicc} returns an \texttt{UndefinedError}. This is supports the idea that the euicc reuses the public key from the previously sent but failed \texttt{AuthenticateServerRequest}.
+    \item However, if different \gls{smdpp} servers are used (e.g., \texttt{rsp.truphone.com} vs \texttt{rsp-eu.redteamobile.com}), the attack fails, and the \gls{euicc} returns an \texttt{UndefinedError}. This supports the idea that the \gls{euicc} reuses the public key from the previously sent but failed \texttt{AuthenticateServerRequest}.
 \end{itemize}
 
 To further probe the caching mechanism, additional tests were conducted in which the public key of the second \texttt{AuthenticateServerRequest} was substituted into the first request. Based on previous observations, it was hypothesized that this would allow a successful installation by aligning the reused state with the new request.