Uruchomienie pokładowego komputera Tesla Model 3 dla cyberbezpieczeństwa

Uruchomienie komputera pokładowego Tesla Model 3 na stole: od części z rozbiórki do pełnej funkcjonalności

Pewien entuzjasta i badacz cyberbezpieczeństwa z sukcesem odtworzył funkcjonalny komputer pokładowy Tesli Model 3, wykorzystując części pochodzące z rozbitych samochodów. Celem projektu było stworzenie środowiska testowego do wyszukiwania luk w zabezpieczeniach i analizy oprogramowania układowego w ramach programu nagród Tesli (Bug Bounty). Ten przypadek pokazuje głębokie wyzwania techniczne i niestandardowe rozwiązania niezbędne do uruchomienia złożonej elektroniki samochodowej poza jej docelowym środowiskiem, a także podkreśla znaczenie dostępu do dokumentacji w procesie inżynierii wstecznej.

Budowa stanowiska testowego: od części do zasilania

Projekt rozpoczął się od potrzeby pozyskania sprzętu Tesli Model 3, aby wziąć udział w programie Bug Bounty. Głównymi komponentami komputera pokładowego są jednostka sterująca multimediami (MCU) oraz jednostka autopilota (AP), które zazwyczaj znajdują się za schowkiem pasażera. Te moduły, wielkości tabletu i grubości około 500-stronicowej książki, są zamknięte w metalowej obudowie z chłodzeniem wodnym. Aby nabyć te komponenty, badacz zwrócił się do serwisu eBay, gdzie znalazł wiele ofert od firm specjalizujących się w demontażu uszkodzonych pojazdów. Koszt MCU wahał się od 200 do 300 dolarów amerykańskich.

Oprócz głównego modułu, do uruchomienia potrzebne były następujące elementy:

Zasilacz prądu stałego, zdolny do dostarczania 12 V. Wybrano regulowany zasilacz 10 A, co okazało się słuszną decyzją, ponieważ system w szczytowym momencie mógł pobierać do 8 A.
Moduł dotykowy (ekran) z uszkodzonej Model 3. Ekrany okazały się niespodziewanie drogie, jeden z nich został zakupiony za 175 dolarów.
Specjalistyczny kabel do połączenia MCU i ekranu.

Ostatni punkt okazał się najbardziej skomplikowany. Komputer i ekran dostarczono z obciętymi kablami, co wymagało znalezienia oryginalnego złącza. Dzięki otwartemu „Schematowi elektrycznemu” Tesli, dostępnemu na ich stronie serwisowej, udało się ustalić, że wyświetlacz wykorzystuje 6-pinowy kabel ze specjalnym złączem Rosenberger 99K10D-1D5A5-D. Poszukiwania takiego kabla na rynku okazały się bezowocne. Próby użycia podobnego samochodowego kabla LVDS, stosowanego w BMW, również nie powiodły się z powodu niekompatybilności złączy.

Infrastruktura sieciowa i interfejsy programowe Tesli

Po otrzymaniu MCU i podłączeniu go do zasilania, zaobserwowano migające czerwone diody LED, co świadczyło o uruchomieniu. Bez ekranu interakcja z systemem była ograniczona, ale wcześniejsze badania wskazywały na istnienie wewnętrznej sieci z serwerami WWW na niektórych komponentach. Podłączenie kabla Ethernet do portu na MCU umożliwiło nawiązanie połączenia sieciowego z laptopem.

W tej wewnętrznej sieci brakuje DHCP, dlatego adres IP trzeba było ustawić ręcznie. Zalecany zakres adresów IP to 192.168.90.X/24, przy czym X powinien być większy niż 105, aby uniknąć konfliktów z innymi hostami. Analiza starych plików /etc/hosts z samochodów Tesla pomogła określić standardowe przypisania adresów IP:

192.168.90.100 cid ice # mcu
192.168.90.100 ic # only in Model X/S | IC = instrument cluster
192.168.90.102 gw # gateway
192.168.90.103 ap ape # ap = autopilot
192.168.90.104 lb # no clue
192.168.90.105 ap-b ape-b # also autopilot
192.168.90.30 tuner # Also no clue
192.168.90.60 modem # this has the ftp server

Na MCU (IP 192.168.90.100) odkryto dwie główne usługi: serwer SSH na porcie 22 oraz API typu REST na porcie 8080.

Serwer SSH: Przy próbie połączenia wyświetlał komunikat „SSH dozwolone: samochód zaparkowany”. Dostęp do niego wymaga specjalnie podpisanych kluczy SSH, generowanych przez Teslę. Ważne jest, aby pamiętać, że w ramach programu Bug Bounty Tesla zapewnia stały certyfikat SSH do dostępu root badaczom, którzy odkryli ważną lukę umożliwiającą uzyskanie uprawnień root. To znacznie upraszcza dalsze poszukiwanie luk.
ODIN API: API typu REST na porcie 8080, znane jako ODIN (On-Board Diagnostic Interface Network), zwraca historię „zadań” i jest przeznaczone do użytku z narzędziem diagnostycznym Tesli „Toolbox”.

Wewnętrzna konstrukcja MCU obejmuje dwie płyty, umieszczone jedna nad drugą, co potwierdza jego modułową architekturę.

Pokonywanie trudności sprzętowych: od LVDS do wiązki przewodów

Początkowe próby połączenia ekranu i MCU za pomocą kabla LVDS od BMW zakończyły się niepowodzeniem z powodu fizycznej niekompatybilności złączy. Desperackie próby bezpośredniego połączenia obciętych przewodów doprowadziły do zwarcia i uszkodzenia jednego z mikrokontrolerów zasilania na płycie. Wymagało to zamówienia nowego MCU. Jednak dzięki przyjacielowi-ekspertowi udało się zidentyfikować spalony komponent jako kontroler obniżający napięcie „MAX16932CATIS/V+T”. Układ scalony został zamówiony i pomyślnie wymieniony w warsztacie naprawczym, co pozwoliło na przywrócenie uszkodzonego MCU i posiadanie dwóch działających modułów.

Uświadomiwszy sobie niemożność znalezienia osobnego kabla Rosenberger, badacz doszedł do wniosku, że w rzeczywistych samochodach Tesla nie stosuje się osobnych kabli do wyświetlacza. Zamiast tego wykorzystuje się duże, zintegrowane wiązki przewodów, łączące wiele kabli z sąsiednich obszarów. Korzystając ze schematu elektrycznego Tesli, udało się znaleźć numer części dla potrzebnej wiązki (1067960-XX-E). Zakup takiej wiązki, mimo jej nieporęczności i kosztu około 80 dolarów, okazał się jedynym działającym rozwiązaniem.

Po zainstalowaniu kompletnej wiązki przewodów system zaczął działać poprawnie. Ekran dotykowy włączył się, a na stole pojawił się w pełni funkcjonalny komputer pokładowy Tesli Model 3 z uruchomionym systemem operacyjnym. Był to ważny etap w tworzeniu pełnoprawnego stanowiska testowego do dalszych badań.

Perspektywy badań i dalsze kroki

Uruchomienie komputera pokładowego Tesli Model 3 na stanowisku testowym otwiera szerokie możliwości do głębokiego badania jego funkcjonalności i bezpieczeństwa. Z w pełni działającym systemem badacz planuje skupić się na następujących kierunkach:

Badanie interfejsu użytkownika (UI): Analiza interakcji z systemem, identyfikacja ukrytych funkcji i potencjalnych punktów wejścia.
Interakcja z interfejsami sieciowymi: Bardziej szczegółowe badanie odkrytych SSH i ODIN API, a także poszukiwanie innych otwartych portów i usług.
Badanie magistrali CAN: Analiza danych przesyłanych wewnętrzną siecią samochodową CAN, w celu zrozumienia komunikacji między różnymi komponentami pojazdu.
Ekstrakcja oprogramowania układowego (firmware extraction): Próby uzyskania dostępu do oprogramowania układowego systemu operacyjnego w celu jego statycznej analizy i poszukiwania luk na niższym poziomie.

Te kroki pozwolą nie tylko głębiej zrozumieć architekturę i działanie systemów Tesli, ale także potencjalnie odkryć krytyczne luki w zabezpieczeniach, co jest głównym celem udziału w programie Bug Bounty.

Kluczowe wnioski

Dostęp do platformy sprzętowej: Dla efektywnego badania cyberbezpieczeństwa samochodów Tesla kluczowe jest posiadanie fizycznego dostępu do komputera pokładowego, co osiąga się poprzez nabycie części z uszkodzonych pojazdów.
Znaczenie otwartej dokumentacji: Publikacja przez Teslę szczegółowych schematów elektrycznych znacznie upraszcza proces inżynierii wstecznej i montażu komponentów poza ich docelowym środowiskiem.
Złożoność specjalistycznego sprzętu: Elektronika samochodowa wykorzystuje unikalne złącza i wiązki przewodów, które mogą być trudno dostępne lub wymagać niestandardowych rozwiązań do integracji.
Wewnętrzna architektura sieciowa: Komputer pokładowy Tesli posiada własną, izolowaną sieć z predefiniowanymi adresami IP i wyspecjalizowanymi usługami, takimi jak SSH i ODIN API.
Motywacja dla badaczy: Program Bug Bounty Tesli, obejmujący zapewnienie dostępu root za odkrycie luk w zabezpieczeniach, motywuje ekspertów do głębokiej analizy i zwiększania bezpieczeństwa systemów samochodowych.

— Editorial Team