Ten post został ostatnio edytowany przez Summer 2025-10-14 o 10:59
Wersja wirtualnej kamery, która była wcześniej zhakowana przez autora, opublikowała film o Bilibili
Poprzednia wersja, którą złamałem, też była uszkodzona
Łącze:Logowanie do linku jest widoczne.
Niedawno klient poprosił mnie, żebym złamał inną wersję wirtualnej kamery tego samego autora i po prostu ją przeanalizował
Najpierw sprawdź pocisk, wzmocnienie wolne od Bangbang, stosunkowo proste, wystarczy wykrycie Fridy, powyższy link zawiera bardzo szczegółową analizę wzmocnienia i wykrywania wersji wolnej od Bangbang, używając różnych narzędzi, takich jak EBPF
Najpierw zacznij z Fridą, są oznaki awarii, może krok został włożony zbyt wcześnie albo adres jest niedostępny, gdy hak jest gotowy, poprawiając kod haka skryptu na Fridę
Ogólnie czas wstrzykiwania był nieco opóźniony, co rozwiązało problem awarii wstrzykiwania
hook Proces jego aktywacji otrzymuje dane zwrócone przez aktywację i musi poprosić serwer o weryfikację, że otrzymał znacznik czasu aktywacji
Następnie użytkownik otrzymuje czas poprzez obliczenie różnicy czasu.
Ta wirtualna kamera również żąda uprawnień root, w przeciwnym razie nie ma komunikacji między procesami wersji,
W sumie ten aparat uruchamia trzy procesy
Jednym z nich jest główny proces aplikacji kamery, czyli komunikacja międzyprocesowa między warstwą Java a warstwą C++
Drugim jest to, że główny proces uruchamia binarny wykonywalny parametr wcmplay na linii poleceń przez warstwę Java, aby rozpocząć drugi proces, który jest głównie odpowiedzialny za komunikację między procesami między głównym procesem kamery vcmpaly a procesem libvc.so wstrzykiwającym do usługi kamery kamery systemu, a głównym sposobem komunikacji jest ibinder.
Trzeci to plik SO serwera kamery wstrzykniętego do usługi systemowej.
Jeśli aplikacja nie może uzyskać uprawnień root lub wystąpi problem sieciowy, proces nie zostanie uruchomiony
Ta kamera potrzebuje kodu aktywacyjnego, aby aktywować i używać, a analizując warstwę Java, wszystkie jej interfejsy są odłączane
Aktywacja wymaga poproszenia serwera o uzyskanie informacji weryfikacyjnych
Dane, które otrzymujesz, są zaszyfrowane
Analizując plik wykonywalny VCMPLAY, możemy uzyskać, że żądane dane są szyfrowane RSA, a klucz znajduje się za pomocą narzędzia EBPF stackplz, a klucz szyfrujący ma 128 bitów
Jeszcze jedno słowo
Ta aplikacja jest bardzo sprytna, dodał sufiks so do vcmplay, co sprawia, że ludzie myślą, iż to plik SO i trzeba go załadować do pamięci Javy, ale to w rzeczywistości inny proces.
Podłączyłem camera service cameraserver libvc.so okazało się, że Frida zawiesiła się zaraz po awarii usługi attach camera. Nie wiem, czy została wykryta, analizowałem ją długo i przypadkowo odkryłem, że VCMPLAY padł raz, a potem udało się się zahakować. Podejrzewa się, że to proces VCMPLAY wykrył proces cameraserve.
Użyłem IDA do debugowania procesu VCMpay i okazało się, że nadal ma antydebugowanie, zeskanowałem tracepid w proc/self/status, żeby sprawdzić, czy został zdebugowany, a co było jeszcze bardziej przerażające, odkrył, że antydebugowanie nie było awarią programu, tylko faktycznie usunął ważne pliki w systemie Android przez uprawnienia root, a potem telefon zrestartował się do stanu podwójnego czyszczenia, system musiał zostać zaiificalizowany, żeby wejść do systemu, i wszystko w telefonie zniknęło. Napisałem moduł kernel hook w kpm przez kernelpatch i omiłem debugowanie
Po kilku bezsennych nocach tutaj ogólna logika została zrozumiała i szacuje się, że nie będzie łatwo ją złamać.
Dalsze czytanie później......
|
Opublikowano 2025-10-14 10:40:57
|
|
|
|
