niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2025-12-08 05:27:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-04 23:19:24 +00:00
committed by node
parent e4419c403d
commit b6be91e4d9
7 changed files with 630 additions and 571 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
Chapters/Evaluation.tex
View File

@@ -166,7 +166,7 @@ The firmware image accompanying the update utility appears to be encrypted or ob
\caption{Shannon entropy values across blocks for three different firmware versions.}
\end{figure}
A deeper static analysis using Ghidra did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk\footnote{https://github.com/ReFirmLabs/binwalk} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
A deeper static analysis using Ghidra~\cite{nsa_ghidra_2025} did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk~\cite{refirmlabs_binwalk_2025} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
\subsubsection*{Firmware Update Mechanism}
@@ -178,8 +178,9 @@ 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} \\
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
\centering
\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.
@@ -278,29 +279,6 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
\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 as shown in \cref{tab:data_fuzzing_result_part1} and \cref{tab:data_fuzzing_result_part2}, 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
@@ -344,6 +322,29 @@ The LED activity ceased only when the card reader was fully disconnected from th
\end{tabular}
\end{table}
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 as shown in \cref{tab:data_fuzzing_result_part1} and \cref{tab:data_fuzzing_result_part2}, 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.
% apdu fuzzing
@@ -427,15 +428,15 @@ The execution time of fuzzed \gls{apdu} sequences varied depending on chip proce
The following classes of errors were consistently encountered during mutation campaigns:
\begin{itemize}
\item \textbf{SCP03TSecurityError}: Occurred during the \texttt{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.
\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.
\item \textbf{ApduException}: Triggered by malformed \gls{asn1} structures, typically due to mutations altering length or tag fields.
\item \textbf{InvalidCertificate}: Observed during \texttt{AuthenticateServer} and \texttt{PrepareDownload}. The \gls{euicc} rejected the server certificate during validation.
\item \textbf{InvalidSignature}: Raised exclusively during \texttt{InitialiseSecureChannelRequest}, indicating that the \gls{euicc} failed to verify the signature required for secure channel establishment.
\item \textbf{InvalidSignature}: Raised exclusively during \texttt{\justify InitialiseSecureChannelRequest}, indicating that the \gls{euicc} failed to verify the signature required for secure channel establishment.
\item \textbf{UnsupportedRemoteOpType}: Also restricted to \texttt{InitialiseSecureChannelRequest}. Mutation operators such as \texttt{ZERO\_BLOCK} or \texttt{TRUNCATE} corrupted the operation type field, which is normally set to \texttt{installBoundProfilePackage (1)}.
\item \textbf{UnsupportedRemoteOpType}: Also restricted to \texttt{\justify InitialiseSecureChannelRequest}. Mutation operators such as \texttt{ZERO\_BLOCK} or \texttt{TRUNCATE} corrupted the operation type field, which is normally set to \texttt{\justify installBoundProfilePackage (1)}.
\item \textbf{UnsupportedCurve}: Introduced via bit-level mutations affecting certificate parameters. The \gls{euicc} did not support the altered elliptic curve definition.