Telefon dla służb czy dla przestępców?

Studium przypadku urządzenia „powered by c0der” – gdy Kiedy ISP, analiza TEE, pełny dump eMMC, transplantacja procesora i brute force nadal nie wystarczają…

W informatyce śledczej urządzeń mobilnych często spotykam się z przekonaniem, że wykonanie pełnego odczytu pamięci urządzenia automatycznie oznacza dostęp do zapisanych w nim danych. Jeszcze kilka lat temu takie założenie często było prawdziwe. Współczesne urządzenia mobilne coraz częściej pokazują jednak, że sam obraz pamięci jest jedynie początkiem znacznie bardziej złożonego procesu analitycznego.

Do laboratorium trafiło urządzenie bazujące na platformie sprzętowej Elephone PX Pro, wyposażone w procesor MediaTek Helio P60 MT6771V. Już podczas pierwszych oględzin było jasne, że nie będzie to typowy przypadek.

Na etapie oględzin nie było dostępnych informacji wskazujących na niestandardową konfigurację systemową urządzenia. Telefon identyfikował się jako standardowy przedstawiciel rodziny PX Pro, a publicznie dostępne materiały nie wskazywały na występowanie jakichkolwiek nietypowych funkcji bezpieczeństwa.

Podczas poszukiwania informacji o modelu udało się odnaleźć jedynie pojedyncze wzmianki dotyczące bardzo podobnej konstrukcji:

Dziwny telefon – urządzenie służb specjalnych? – (forum.benchmark.pl)

Autor opisywał urządzenie pozbawione oznaczeń producenta, wyposażone w niestandardowe funkcje bezpieczeństwa oraz system określany jako „powered by c0der”. W tamtym momencie była to jedynie ciekawostka, której nie można było w żaden sposób zweryfikować.

Badania rozpoczęto od wykorzystania specjalistycznych narzędzi stosowanych w informatyce śledczej urządzeń mobilnych.

W pierwszej kolejności podjęto próby komunikacji z urządzeniem przy wykorzystaniu:

• GrayKey,
• Cellebrite UFED,
• Cellebrite Inspector.

Wykorzystano dostępne mechanizmy komunikacji oraz procedury eksploatacji podatności przeznaczone dla urządzeń z systemem Android.

omimo przeprowadzonych działań nie udało się uzyskać dostępu do danych użytkownika ani pozyskać materiału kryptograficznego umożliwiającego dalszą analizę.

Po wyczerpaniu standardowych metod podjęto decyzję o przejściu do badań sprzętowych.

Po demontażu ekranów EMI zauważalne były ślady wcześniejszej ingerencji.

Widoczne były:

• usunięte elementy ekranowania,
• odsłonięte pola testowe,
• ślady lutowania,
• miejsca wskazujące na wcześniejsze próby komunikacji z płytą główną.

Wszystko wskazywało na to, że urządzenie było już wcześniej przedmiotem analiz prowadzonych przez inne osoby lub podmioty.
Jednocześnie nie było możliwe ustalenie, jakie metody zostały wcześniej wykorzystane oraz czy zakończyły się powodzeniem.

Brak dokumentacji technicznej wymusił rozpoczęcie pracy od podstaw. W pierwszej kolejności zidentyfikowano zastosowany układ pamięci:
Micron eMMC S0J9K9 o pojemności około 116 GB

Następnie odtworzono połączenia komunikacyjne pamięci, zidentyfikowano sygnały CLK, CMD oraz linie DATA i przygotowano połączenie ISP umożliwiające bezpośrednią komunikację z układem pamięci.

Do realizacji odczytu wykorzystano platformę Medusa Pro.

Po zestawieniu komunikacji wykonano pełny binarny odczyt pamięci urządzenia, zabezpieczając między innymi partycje:

• userdata,
• metadata,
• tee1,
• tee2,
• persist,
• nvram,
• nvdata,
• seccfg,
• md_udc,
• frp.

Dopiero na tym etapie możliwe było ustalenie rzeczywistej konfiguracji badanego urządzenia.

Analiza zabezpieczonego obrazu wykazała, że urządzenie pracuje pod kontrolą systemu: Android 10
oraz wykorzystuje niestandardową kompilację oznaczoną jako: Build ID: k0der-v5.6

Dodatkowo ustalono: Build Description: full_v598-user 10 QP1A.190711.020 20200430 release-keys

To właśnie na tym etapie pojawił się pierwszy naprawdę interesujący trop.
Nazewnictwo odnalezione w strukturach systemowych urządzenia wykazywało wyraźne podobieństwo do określenia „c0der”, które wcześniej pojawiało się w opisach podobnych konstrukcji dostępnych w Internecie.

Nie pozwala to oczywiście na jednoznaczne potwierdzenie wspólnego pochodzenia obu urządzeń, jednak zbieżność ta okazała się na tyle charakterystyczna, że zasługiwała na dalszą uwagę.

Pozyskany materiał został poddany wieloetapowej analizie.

W badaniach wykorzystano:

Narzędzia kryminalistyczne

• X-Ways Forensics,
• Oxygen Forensic Detective,
• Cellebrite Inseyets,
• Magnet Axiom.

Narzędzia środowiska Linux

• binwalk,
• strings,
• grep,
• fdisk,
• gdisk,
• parted,
• losetup,
• mount,
• xxd,
• ghex,

oraz dedykowane skrypty Python przygotowane na potrzeby badań.

Analizie poddano zarówno strukturę GPT, jak i zawartość partycji odpowiedzialnych za bezpieczeństwo urządzenia, w tym metadata, tee1, tee2, nvdata, nvram, persist, seccfg oraz userdata.

Przeprowadzone badania potwierdziły wykorzystanie mechanizmu: Android File-Based Encryption (FBE).
W strukturze danych zidentyfikowano charakterystyczne katalogi: system_de, system_ce, user_de i user_ce.

Jednocześnie cała zawartość danych użytkownika pozostawała zaszyfrowana. Na tym etapie stało się jasne, że pełny obraz pamięci nie będzie wystarczający do uzyskania dostępu do danych użytkownika.

Najciekawsze informacje ujawniła analiza partycji: tee1 i tee2.

W ich strukturze zidentyfikowano liczne artefakty wskazujące na wykorzystanie środowiska:
TrustKernel Trusted Execution Environment (TEE)

Podczas analizy odnaleziono między innymi wpisy związane z:

• TrustKernel OS,
• SECURE_OS,
• TRUSTED_UI,
• tee_comm,
• tee_ta_open_session,
• tee_ta_invoke_command.

Uzyskane artefakty jednoznacznie wskazywały, że urządzenie wykorzystuje odseparowane środowisko bezpieczeństwa oparte o architekturę ARM TrustZone.
W praktyce oznacza to, że klucze szyfrujące dane użytkownika nie znajdują się bezpośrednio w systemie Android ani w pamięci użytkownika.

Są one chronione przez środowisko TEE współpracujące z mechanizmami:

• Keymaster,
• Gatekeeper,
• RPMB,
• Android File-Based Encryption.

Podczas analizy potwierdzono również obecność obszaru:
Replay Protected Memory Block (RPMB)
stanowiącego jeden z elementów łańcucha ochrony kluczy kryptograficznych.

Próby odczytu RPMB zakończyły się niepowodzeniem.

Osoby zajmujące się analizą urządzeń MediaTek wiedzą, że przez wiele lat jedną z najskuteczniejszych metod pozyskiwania materiału kryptograficznego było wykorzystanie środowiska BootROM (BROM).

W przypadku wielu platform MTK możliwe było uzyskanie dostępu do niskopoziomowych funkcji procesora, pozyskanie identyfikatorów sprzętowych SoC oraz materiału wykorzystywanego przez mechanizmy kryptograficzne Androida. W analizowanym przypadku sytuacja wyglądała jednak zupełnie inaczej.

Pomimo licznych prób urządzenie nie udostępniało funkcjonalności pozwalających na uzyskanie dostępu do środowiska BROM.

Nie udało się pozyskać:

• SOC_ID,
• HRID,
• identyfikatorów sprzętowych procesora,
• materiału kryptograficznego Keymaster,
• kluczy powiązanych z TEE.

Analiza zachowania urządzenia wskazywała na zastosowanie mechanizmów ograniczających dostęp do środowiska BootROM, potencjalnie wykorzystujących konfigurację eFuse oraz zmodyfikowany łańcuch rozruchowy. To właśnie ten element okazał się kluczowy.
Pomimo wykonania pełnego odczytu pamięci eMMC oraz uzyskania dostępu do wszystkich istotnych partycji urządzenia nie było możliwe odtworzenie kluczy szyfrujących Android File-Based Encryption.
Sam obraz pamięci nie zawierał bowiem wszystkich informacji niezbędnych do odszyfrowania danych użytkownika.
Co istotne, analiza wykazała również, że sam identyfikator pamięci eMMC nie posiada wartości umożliwiającej odtworzenie kluczy szyfrujących.
Klucze te są powiązane nie tylko z pamięcią masową, ale również z unikalnymi identyfikatorami procesora oraz środowiskiem Trusted Execution Environment.

W celu weryfikacji alternatywnej ścieżki pozyskania materiału kryptograficznego zakupiono urządzenie-dawcę wyposażone w identyczny procesor:
MediaTek Helio P60 MT6771V.

Następnie wykonano pełną transplantację procesora BGA z urządzenia dowodowego na płytę dawcy.
Założeniem było uruchomienie funkcji serwisowych niedostępnych w oryginalnym urządzeniu oraz próba pozyskania materiału kryptograficznego bezpośrednio z układu SoC.

Pomimo prawidłowo przeprowadzonej operacji również ta metoda nie pozwoliła na uzyskanie dostępu do kluczy kryptograficznych.
Po zakończeniu badań procesor ponownie zamontowano na oryginalnej płycie głównej.

W ostatnim etapie wykorzystano urządzenie XPin Clip, umożliwiające wykonywanie kontrolowanych prób odblokowania telefonu poprzez automatyczne wprowadzanie kodów dostępu.
Pierwsze serie najczęściej stosowanych kombinacji nie przyniosły rezultatu.
Dodatkowo mechanizm bezpieczeństwa urządzenia zaczął sukcesywnie wydłużać czas oczekiwania pomiędzy kolejnymi próbami logowania.

Z uwagi na ryzyko trwałej blokady urządzenia oraz możliwość utraty danych odstąpiono od dalszych działań.

Przeprowadzone badania pozwoliły:

• wykonać pełny odczyt pamięci eMMC,
• przeanalizować architekturę bezpieczeństwa urządzenia,
• potwierdzić wykorzystanie Android File-Based Encryption,
• zidentyfikować środowisko TrustKernel Trusted Execution Environment,
• potwierdzić obecność mechanizmów ochrony opartych o TrustZone i RPMB,
• zweryfikować wykorzystanie zabezpieczeń ograniczających dostęp do środowiska BootROM.

Nie udało się natomiast pozyskać materiału kryptograficznego niezbędnego do odszyfrowania danych użytkownika.
Przypadek ten stanowi interesujący przykład skutecznego połączenia mechanizmów Android File-Based Encryption, Trusted Execution Environment, RPMB oraz sprzętowych zabezpieczeń procesora MediaTek.

Pokazuje również, że współczesna informatyka śledcza coraz częściej wymaga nie tylko wykonania odczytu pamięci, lecz także pełnego zrozumienia architektury kryptograficznej badanego urządzenia.

W niektórych przypadkach największą wartością badania nie jest odzyskanie danych, lecz precyzyjne ustalenie, dlaczego dostęp do tych danych pozostaje niemożliwy pomimo wykorzystania najbardziej zaawansowanych metod analizy sprzętowej i programowej.

Autor: Bartosz Mataczyński