Przejdź do treści
Strona główna » Aktualności » Telefon dla służb czy dla przestępców?

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.

    Telefon do badań - Elephone PX Pro
    Telefon do badań – Elephone PX Pro

    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ć.

    Pierwszy etap – standardowe narzędzia kryminalistyczne

    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.

    Oględziny płyty głównej

    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ą.
    Widok procesora MediaTek - widoczne ślady ingerencji (odsłonięte pola testowe).
    Widok procesora MediaTek – widoczne ślady ingerencji (odsłonięte pola testowe).

    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.

    ISP i pełny odczyt pamięci eMMC

    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.

    Identyfikacja sygnałów CLK, CMD oraz linii DATA do połączenia ISP
    Identyfikacja sygnałów CLK, CMD oraz linii DATA do połączenia ISP

    Do realizacji odczytu wykorzystano platformę Medusa Pro.

    Odczyt z wykorzystaniem platformy Medusa Pro
    Odczyt z wykorzystaniem platformy Medusa Pro
    Wynik odczytu danych z pamięci Micron eMMC S0J9K9
    Wynik odczytu danych z pamięci Micron eMMC S0J9K9

    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.
    Pełny binarny odczyt pamięci urządzenia - widok zabezpieczonych partycji
    Pełny binarny odczyt pamięci urządzenia – widok zabezpieczonych partycji

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

    Co ujawnił odczyt pamięci?

    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.

    Wynik analizy zabezpieczonego obrazu
    Wynik analizy zabezpieczonego obrazu

    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ę.

    Analiza niskopoziomowa zabezpieczonego obrazu

    Pozyskany materiał został poddany wieloetapowej analizie.

    Autor: Bartosz Mataczyński