Update on Overleaf.

Chapters/Background.tex

@@ -151,7 +151,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
 % - Proposed AIDs by the GSMA/GP for Applications: ISD-R ("A0000005591010FFFFFFFF8900000100"), ARA-M ("'A00000015141434C00'")
 % - actual AID is up to the manufcacturer, especially ISD-R AID is often changed as explained in section (ref section here)
 
-The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the \gls{mf} (Master File), from which all other files—\glspl{df}, \glspl{ef}, and \glspl{adf}—originate.
+The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the \gls{mf} (Master File), from which \glspl{df}, \glspl{ef}, and \glspl{adf} originate.
 
 \glspl{df} serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
 
@@ -159,7 +159,14 @@ Each file is uniquely identified by a \gls{fid}, while applications are identifi
 
 To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, AID, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
 
-Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application~(\texttt{A0000005591010FFFFFFFF8900000100}) and the \gls{aram} application~(\texttt{A00000015141434C00}). However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in \cref{sec:findings}.
+Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
+
+\begin{itemize}
+    \item \gls{isdr} \texttt{A0000005591010FFFFFFFF8900000100}
+    \item \gls{aram} \texttt{A00000015141434C00}
+\end{itemize}
+
+However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in \cref{sec:findings}.
 
 \section{Embedded SIM}
 \label{sec:esim}
@@ -231,8 +238,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
 
 \paragraph{Application Toolkit}
 
-The \gls{stk}/\gls{usat} — collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in ETSI TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device.
+The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in ETSI TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device.
-
 
 
 \section{Remote SIM Provisioning}

Chapters/RelatedWork.tex

@@ -27,7 +27,7 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
 
 The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \texttt{pySim-read}, \texttt{pySim-prog}, \texttt{pySim-trace}, and \texttt{pySim-smdpp}. Among these, \texttt{pySim-shell} is the core component, offering an interactive shell interface to navigate the \gls{sim} card file system and issue application-specific commands. It supersedes the legacy \texttt{pySim-read} script, which only supports a limited subset of shell commands and is primarily used to extract commonly accessed data fields from \gls{sim} cards.
 
-The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{simtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording; it does not support active injection or modification of messages.
+The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{simtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording and does not support active injection or modification of messages.
 
 The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the \gls{sgp22} \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full \gls{sgp22} protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its \gls{sgp22} functionality is restricted to the server role only.
 
@@ -47,7 +47,7 @@ While \texttt{pySim} provides useful standalone utilities, its usability as a ge
 
 \texttt{SIMtrace2} is a system developed by the osmocom~\cite{osmocom_simtrace_nodate} project that combines hardware, firmware, and software components to enable the monitoring and emulation of communication between a \gls{sim} card and \gls{ue}, such as a mobile phone~\cite{osmocom_simtrace_nodate}.
 
-The primary use case of \texttt{SIMtrace2} is passive tracing of the communication between a \gls{sim} card and its host device. For this purpose, it supports multiple firmware variants, the most relevant being the \texttt{trace} and \texttt{emulate} firmware. The \texttt{trace} firmware allows passive sniffing of \gls{apdu}-level communication, operating without interfering with the ongoing exchange. It supports the \gls{t0} protocol and transmits the captured data as \gls{udp} packets to a specified socket. These packets can be analyzed using tools such as \texttt{Wireshark}—for which Osmocom provides a dedicated dissector~\cite{welte_wireshark_nodate}—or through \texttt{pySim-trace}~\cite{welte_pysim_2024}.
+The primary use case of \texttt{SIMtrace2} is passive tracing of the communication between a \gls{sim} card and its host device. For this purpose, it supports multiple firmware variants, the most relevant being the \texttt{trace} and \texttt{emulate} firmware. The \texttt{trace} firmware allows passive sniffing of \gls{apdu}-level communication, operating without interfering with the ongoing exchange. It supports the T0 protocol and transmits the captured data as \gls{udp} packets to a specified socket. These packets can be analyzed using tools such as \texttt{Wireshark}, for which Osmocom provides a dedicated dissector~\cite{welte_wireshark_nodate}, or through \texttt{pySim-trace}~\cite{welte_pysim_2024}.
 
 The \texttt{emulate} firmware, on the other hand, provides \gls{sim} card emulation capabilities. This mode is used to simulate a \gls{sim} card that is not physically present in the device, such as in scenarios involving remote \gls{sim} access or when using a smart card reader. Notably, this emulation capability has also been employed by projects such as \textit{Simurai} for malicious card emulation and fuzzing purposes~\cite{lisowski_simurai_2024}.