mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-08 05:27:59 +00:00
Update on Overleaf.
This commit is contained in:
nb72soza Bittner
@@ -45,68 +45,6 @@ In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based
|
||||
|
||||
The \textbf{9esim V2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
|
||||
|
||||
|
||||
% data fuzzing
|
||||
% data fuzzing was performed on all esim except the estk.me esim since this card does not offer an isd-r
|
||||
% each fuzzing test was performed on all esims one after one
|
||||
|
||||
% findings data fuzzing
|
||||
% data fuzzing succeeded for most cards
|
||||
% ProfileInfoList failed for 9esim, 9esim v2 and EIOTCLUB
|
||||
% Reported failure input was get_profiles(use_iccid=False, profile_class=None, tags=b'') with failure CardConnectionException from the smartcard library
|
||||
% noticable was that the transaction LED on the CardReader continued to blink (suggesting APDUs were still being sent) eventough no traffic was generated by our code
|
||||
% traffic LED continued to blink even when esim was removed
|
||||
% only stopped blinking when completly disconnected from PC
|
||||
% suggests possible bug in smartcard library
|
||||
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
Data fuzzing, as described in \cref{sec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim V2
|
||||
\item EIOTCLUB
|
||||
\end{itemize}
|
||||
|
||||
In all three cases, the fuzzing input
|
||||
|
||||
\begin{lstlisting}[language=Python]
|
||||
get_profiles(use_iccid=False, profile_class=None, tags=b'')
|
||||
\end{lstlisting}
|
||||
|
||||
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
|
||||
|
||||
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
|
||||
|
||||
The LED activity ceased only when the card reader was fully disconnected from the host machine. This behavior strongly indicates that the failure triggered an inconsistent or undefined state within the underlying \texttt{smartcard} library or \texttt{libpcsc}.
|
||||
|
||||
% Although this failure was not directly traceable to a specific eSIM firmware implementation (due to the exception occurring before a meaningful response could be recorded), its repeatability across multiple cards and hardware sessions suggests it warrants further investigation—potentially outside the scope of this work but relevant for tooling robustness in future studies.
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Data fuzzing results for each function per \gls{esim}}
|
||||
\label{tab:data_fuzzing_result}
|
||||
\begin{tabular}{lcccccc}
|
||||
\toprule
|
||||
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{9esim} & \textbf{9esim v2} & \textbf{EIOTCLUB} & \textbf{Xesim} \\
|
||||
\midrule
|
||||
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
|
||||
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
% general findings
|
||||
|
||||
% estk.me fwupd
|
||||
@@ -179,8 +117,8 @@ The LED activity ceased only when the card reader was fully disconnected from th
|
||||
% high shannon entropy of (TODO: check shannon entrpoy of all firmware versions)
|
||||
% analysing the firmware files with ghidra also just showed just binary data without any structure
|
||||
|
||||
\section{General Findings}
|
||||
\label{sec:general_findings}
|
||||
\section{estk.me Firmware}
|
||||
\label{sec:estk_me_firmware}
|
||||
|
||||
Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicly available firmware update utility, which is offered via their official website. This binary executable provides both the latest firmware images and the means to apply updates directly from a host machine, making it a unique case in comparison to other \gls{esim} vendors, none of whom publicly expose firmware updates or custom flashing endpoints.
|
||||
|
||||
@@ -202,7 +140,7 @@ The update mechanism exposes two primary functions via a custom \gls{aid} endpoi
|
||||
|
||||
The \gls{aid} used to access the update utility differs based on firmware generation. For example, the test card (generation T001) uses the \gls{aid} :
|
||||
\begin{quote}
|
||||
\texttt{A06573746B6D65FFFFFFFF6677757064}
|
||||
\texttt{A06573746B6D65FFFFFFFF6677757064} \\
|
||||
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
|
||||
\end{quote}
|
||||
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded. Firmware updates are incremental and strictly one-way, the tool automatically selects the next version based on the currently installed one, and downgrade paths are not supported.
|
||||
@@ -223,7 +161,7 @@ The update process proceeds as follows:
|
||||
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
|
||||
\end{enumerate}
|
||||
|
||||
The update tool fails gracefully only under specific conditions. For malformed or incorrect \glspl{apdu}, the \gls{euicc} abruptly terminates the connection, leading to a \texttt{CardConnectionException} raised by the PC/SC stack. This maps to the \texttt{SCARD\_E\_NOT\_TRANSACTED (0x80100016)} error, which occurs when the host attempts to communicate over a closed or non-existent connection~\cite{pcsclite_errors}.
|
||||
The update tool fails gracefully only under specific conditions. For malformed or incorrect \glspl{apdu}, the \gls{euicc} abruptly terminates the connection, leading to a \texttt{CardConnectionException} raised by the PC/SC stack. This maps to the \texttt{SCARD\_E\_NOT\_TRANSACTED (0x80100016)} error, which occurs when the host attempts to communicate over a closed or non-existent connection~\cite{corcoran_pcsc-lite_2025}.
|
||||
|
||||
\subsubsection*{Reverse Engineering and Mutation Testing}
|
||||
|
||||
@@ -286,6 +224,67 @@ This variation in \gls{aid} usage may be driven by internal vendor policy, brand
|
||||
|
||||
While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
|
||||
|
||||
% data fuzzing
|
||||
% data fuzzing was performed on all esim except the estk.me esim since this card does not offer an isd-r
|
||||
% each fuzzing test was performed on all esims one after one
|
||||
|
||||
% findings data fuzzing
|
||||
% data fuzzing succeeded for most cards
|
||||
% ProfileInfoList failed for 9esim, 9esim v2 and EIOTCLUB
|
||||
% Reported failure input was get_profiles(use_iccid=False, profile_class=None, tags=b'') with failure CardConnectionException from the smartcard library
|
||||
% noticable was that the transaction LED on the CardReader continued to blink (suggesting APDUs were still being sent) eventough no traffic was generated by our code
|
||||
% traffic LED continued to blink even when esim was removed
|
||||
% only stopped blinking when completly disconnected from PC
|
||||
% suggests possible bug in smartcard library
|
||||
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
Data fuzzing, as described in \cref{subsec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim V2
|
||||
\item EIOTCLUB
|
||||
\end{itemize}
|
||||
|
||||
In all three cases, the fuzzing input
|
||||
|
||||
\begin{lstlisting}[language=Python]
|
||||
get_profiles(use_iccid=False, profile_class=None, tags=b'')
|
||||
\end{lstlisting}
|
||||
|
||||
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
|
||||
|
||||
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
|
||||
|
||||
The LED activity ceased only when the card reader was fully disconnected from the host machine. This behavior strongly indicates that the failure triggered an inconsistent or undefined state within the underlying \texttt{smartcard} library or \texttt{libpcsc}.
|
||||
|
||||
% Although this failure was not directly traceable to a specific eSIM firmware implementation (due to the exception occurring before a meaningful response could be recorded), its repeatability across multiple cards and hardware sessions suggests it warrants further investigation—potentially outside the scope of this work but relevant for tooling robustness in future studies.
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Data fuzzing results for each function per \gls{esim}}
|
||||
\label{tab:data_fuzzing_result}
|
||||
\begin{tabular}{lcccccc}
|
||||
\toprule
|
||||
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{9esim} & \textbf{9esim v2} & \textbf{EIOTCLUB} & \textbf{Xesim} \\
|
||||
\midrule
|
||||
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
|
||||
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
% apdu fuzzing
|
||||
|
||||
% optimizing for coverage
|
||||
|
||||
Reference in New Issue
Block a user