From b782db5c5d2582f792d0f344ef6825970fcfa488 Mon Sep 17 00:00:00 2001 From: nb72soza Bittner Date: Tue, 24 Jun 2025 14:08:17 +0000 Subject: [PATCH] Update on Overleaf. --- Chapters/Evaluation.tex | 72 ++++++++++++++++++++++++++++++----------- 1 file changed, 54 insertions(+), 18 deletions(-) diff --git a/Chapters/Evaluation.tex b/Chapters/Evaluation.tex index 400e389..e3d9881 100644 --- a/Chapters/Evaluation.tex +++ b/Chapters/Evaluation.tex @@ -21,12 +21,6 @@ % findings -% different isd-r aids -% during the intital setup process of the tracer when running the tracer between some esim and their corresponding lpa -% we noticed that some esim used different aids to select the isd-r when intercepting the traffic -% xesim, 5ber and esim.me use different aids -% esim.me offers both their custom aid and the common aid to select the isd-r - % estk.me fwupd % estk.me offers an esim firmware update utility on their website % this tool can be run on some host machine and comes with the newest firmware image of the esim @@ -41,21 +35,62 @@ % TODO: explain fwupd mechanism here % update mechanism offers 2 functions: get_version and flash_firmware -% the custom flash endpoint is locate under the aid A06573746B6D65FFFFFFFF6677757064 -% the aid is the hex encoded text 'estkmeÿÿÿÿfwupd' - -% get_version retrieves the version code of the currently installed firmware by sending the apdu packet APDU(class=0xAA, instruction=0xFF, p1=0x00, p2=0x00, le=0x08) +% the custom flash endpoint is locate under the aid A06573746B6D65FFFFFFFF6677757064 for v1 and A06573746B6D65FFFFFFFFFFFF6D6774 for v2 +% the card the i have for testing is an v1 version +% the aid is the hex encoded text 'estkmeÿÿÿÿfwupd' for v1 and 'estkmeÿÿÿÿÿÿmgt' for v2 +% get_version retrieves the version code of the currently installed firmware by first selecting the aid and then sending the apdu packet APDU(class=0xAA, instruction=0xFF, p1=0x00, p2=0x00, le=0x08) % our estk.me esim responds with Version 'T001V06' which corresponds to the 4.6.0 received via the euicc info 1 % this shows that this is an older estk.me model with the current one having the firmware version 'T3V7' as shown in newer firmware versions -% the firmware update happens ins 6 Steps: setup, unlock, send_program_block, validate, and check_flash_status -% -% setup: to setup esim.me for flashing, the firmware update tool selects the custom flashing endpoint with the APDU command APDUPacket(cla=0x01, ins=0x55, p1=0x55, p2=0x55) and enters the esim into flashing mode -% unlock: +% from the available firmware updates in the download page these versions exist: +% T000V06-3.4.3 +% T001V02-T001V05 +% T001V03_V04-T001V05 +% T001V05-T001V06 +% T001V06-3.4.3 +% T002V01-T002V06 +% T002V06-3.4.3 +% T003V03-4.2.4.1 +% T003V03-4.4.3.1 +% T003V03-4.5.1 +% T003V03-T3V6SS0 +% T3V4SS0-T3V6SS0 +% T3V5SS0-T3V6SS0 +% T3V6SS0-T3V7SS0 (v5.4.3) +% T001V06-3.4.3 seems to be the highest available version available for our card +% the list contains intermediate firmware versions which are used to upgrade from one major version to another i.e TXXXVXX-TXXVXX and current versions i.e TXXXVXX-X.X.X which are minor updates +% the list shows that there are 4 generations of cards: T000, T001, T002, and T003 +% cards cannot be upgraded between generations +% only upugrade no downgrade support by the update mechanism -> autoselects the next firmware to update based on the installed one -% we could reimplement the code in python -> see implementation -% with the reimplementation we could analyze the traffic further and apply similar mutations as used in the apdu fuzzing section (cref) -% when applying these mutations to every firmware section blob the esim would immediatly reject the section -% based on this behaviour we assume that there is some signing of the blocks involved or some checksum or hash implementeted in each section to prevent transmission errors and subsequently writing a faulty firmware image, which in the worst case could corrupt the fwupd mechanism and prevent further fixing of the image +% error handling is not really suported by the update mechanism -> wrong apdus or malformed apdus result in a CardConnectionException by the smartcard library which results from the pcsc-lite error SCARD_E_NOT_TRANSACTED (0x80100016) +% SCARD_E_NOT_TRANSACTED is thrown when the library tries to close a non existent connection \cite{https://pcsclite.apdu.fr/api/group__ErrorCodes.html} -> connection is already closed by the euicc -> euicc just closes the connection when erroring + +% updating firmware +% the firmware update happens ins 6 Steps: setup, unlock, send_program_block, validate, and check_flash_status +% to initialise the fwup: select fwup endpoint and send APDU (cla=0x01, ins=0x55, p1=0x55, p2=0x55) -> init complete +% from here on the CLA for v0 APDUs is '00' and 'aa' for v1 +% unlock the euicc: send apdu 'AA21000000' +% firmware is send in multiple blocks with the size 0x80D -> amount of blocks is defined by the firmware size i.e num_blocks = ceil(firmware_size / 0x80D) +% the mss is set to 255 bytes -> limit of normal APDU size defined by standard if not using extended APDUs (limit is 65536) +% each firmware block is sent in smaller APDUs where P1 indicates the current chunk of the program block and P2 the current_chunk & 0xFF +% after each program block is sent, the same data is sent again to euicc but the data part of the APDU is empty, the Le part of the APDU contains the chunk size and the instruction byte is set to 0x12 instead of 0x11 i.e go through each sent apdu and check that the received data length matches the chunk size provided in the Le of the APDU +% the update mechanism then sends the "AA13000000" APDU to check the flash status and indicate the next program block +% when all program blocks are sent -> send APDU 'AA00000000' to indicate the end of the flashing process +% using the information gathered through the reverse engeneering process -> reimplementation in python for further experimentation (also included in the resimulate as shown in implementation section TODO: cref to section) + +% APDU mutation +% for APDU mutation we applied the same as shown in the mutation section i.e bitflip, random byte, zero block, shuffle block, truncate +% mutation are applied on a per chunk basis and in the same way when initially sending the program block +% same mutation is also applied when validating the blocks to ensure that the chunk size stays the same +% euicc accepts chunks initally until we send the check flash status APDU -> immediate crash +% indicates some sort of checksum or hash that is attached to each program block to ensure that the data received by the euicc is valid +% could not find any such thing in the binary -> road block thus could not find any further information about how this is beeing hashed or checksumed + +% firmware binary analysis +% binary analysis was done with various tools like binwalk to check for known file types included in the firmware binary -> nothing +% entropy analysis with binwalk indicate that the firmware is encrypted (TODO: include image of entropy analysis) +% 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 @@ -68,6 +103,7 @@ % xesim: A0000005591010FFFFFFFF8900000177 % 5ber: A0000005591010FFFFFFFF8900050500 % esim.me: A0000005591010000000008900000300 +% esim.me offers both their custom aid and the common aid to select the isd-r % replaying the traffic to other esims did not show any relevant or interisting behaviour % limited to small subset of esim functionality due to usage of nonces for specific tasks