Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
VivienneVMM - ukryta struktura debugowania zaimplementowana za pośrednictwem hypervis
#1
Dzień dobry. Uwalniam framework debugger hypervisora.     Dziennik zmian   2018-11-04 Dodano żądania CECM.   ~~~     VivienneVMM     https://github.com/changeofpace/VivienneVMM   VivienneVMM to ukradkowe narzędzie do debugowania zaimplementowane w hipernadzorcy Intel VT-x. Sterownik udostępnia interfejs sterowania punktem przerwania sprzętowego, który umożliwia klientowi trybu użytkownika ustawianie i zerowanie punktów przerwania. Te punkty przerwania są niewidoczne dla gościa.   Ten projekt wykorzystuje platformę HyperPlatform przez tandasat.       Projektowanie     VivienneVMM   Główny projekt sterownika zawierający monitor maszyn wirtualnych Vivienne.     VivienneCL   Klient VivienneVMM z linii poleceń, który korzysta ze sprzętowego interfejsu kontrolującego punkt przerwania. Prosty debugger.     Testy   Sprawy testowe VivienneVMM.       Realizacja     Breakpoint Manager   Menedżer punktów przerwań (BPM) modyfikuje rejestry debugowania procesora, aby zainstalować i odinstalować punkty przerwań sprzętowych. Każda modyfikacja jest przeprowadzana synchronicznie na wszystkich procesorach logicznych przy użyciu następującego protokołu:    Klient żąda zmiany punktu przerwania za pośrednictwem IOCTL.    BPM odbiera żądanie klienta i zatwierdza parametry wejściowe.    BPM wysyła transmisję IPI, aby wszystkie procesory synchronicznie wykonywały vmcall.    Każdy procesor modyfikuje swoje rejestry debugowania w trybie głównym VMX, aby zdarzenie MovDr nie wystąpiło.   Procesory generują wyjątek debugowania, gdy wykonanie instrukcji spełnia warunki punktu przerwania sprzętowego. Menedżer punktu przerwania monitoruje te wyjątki za pośrednictwem procedury obsługi wyjścia maszyny VM wyjątku debugowania i pobiera wyjątki spowodowane przez punkty przerwań zarządzane przez menedżera BPM.   Użytkownicy mogą dostosować zachowanie punktu przerwania rejestrując wywołanie zwrotne podczas instalacji punktu przerwania. Połączenia zwrotne są wykonywane w trybie głównym VMX, w kontekście procesu docelowego, po spełnieniu warunku punktu przerwania. Przechwytywanie kontekstu wykonania to przykładowe wywołanie zwrotne, które działa jako hak do wykonywania, aby odczytać stan rejestru.     Debuguj rejestr Fasada   Elewacja rejestru debugowania uniemożliwia gościowi dostęp do rejestrów debugowania procesora za pośrednictwem programu obsługi wyjścia VM MovDr. Ten handler emuluje instrukcje dostępu do rejestru debugowania za pomocą zestawu specyficznych dla procesora, "fałszywych" rejestrów debugowania.       Kontekst wykonania przechwytywania   Moduł kontekstu wykonywania przechwytywania (CEC) implementuje dwa wywołania zwrotne punktu przerwania: rejestr kontekstu wykonywania przechwytywania (CECR) i pamięć kontekstu wykonywania przechwytywania (CECM).     Rejestr kontekstu przechwytywania (CECR)   Ten wywołanie zwrotne pobiera zawartość docelowego rejestru i zapisuje unikalne wartości w buforze dostarczanym przez użytkownika.     Przykład   W tym przykładzie musimy odtworzyć strukturę danych odtwarzacza w grze wieloosobowej FPS. Naszym celem jest móc niezawodnie zdobyć wszystkie wskaźniki graczy do gry w "rundzie" od naszego klienta out-of-process.   Zidentyfikowaliśmy następującą funkcję w kodzie gry, która nieustannie iteruje listę wskaźników gracza:       Kod:   VOID ProcessGameTick (_In_ ULONG NumberOfPlayers) {for (ULONG i = 0; i <NumberOfPlayers; ++ i) {PVOID pPlayer = GetDecryptedPlayerPointer (i); SimulatePlayerTick (pPlayer); }}   Demontaż pętli for:       Kod:   . tekst: 0000000140001032 loc_140001032:. tekst: 0000000140001032 mov eax, [rsp + 38h + PlayerIndex]. tekst: 0000000140001036 inc eax. tekst: 0000000140001038 mov [rsp + 38h + PlayerIndex], eax. tekst: 000000014000103C. tekst: 000000014000103C loc_14000103C:. tekst: 000000014000103C mov eax, [rsp + 38h + arg_0]. tekst: 0000000140001040 cmp [rsp + 38h + PlayerIndex], eax. tekst: 0000000140001044 jnb short loc_140001060. tekst: 0000000140001046 mov ecx, [rsp + 38h + PlayerIndex]. text: 000000014000104A wywołanie GetDecryptedPlayerPointer. tekst: 000000014000104F mov [rsp + 38h + pPlayer], rax; Cel CURV. . tekst: 0000000140001054 mov rcx, [rsp + 38h + pPlayer]. tekst: 0000000140001059 zadzwoń SimulatePlayerTick. text: 000000014000105E jmp short loc_140001032   Ustalamy, że możemy obliczyć wskaźniki gracza, jeśli jesteśmy w stanie odtworzyć funkcję GetDecryptedPlayerPointer. Teraz wyobraź sobie, że funkcja ta jest mocno zaciemniona do tego stopnia, że potrzeba odwrócić nierealistyczną ilość czasu. Zwykle odrzucamy ten fragment kodu, ponieważ nagroda nie jest warta czasu na inwestycję.   Możemy osiągnąć nasz cel bez odwracania GetDecryptedPlayerPointer poprzez wykonanie rejestru wartości przechwytywania (CECR) IOCTL dla rejestru RAX pod adresem 0x14000104F. Moduł CEC spełnia to żądanie CECR, instalując efemeryczny punkt przerwania sprzętowego o wartości 0x14000104F dla procesu docelowego. Gdy proces docelowy wykonuje instrukcję pod tym adresem, wyjątek debugowania jest generowany i przetwarzany przez BPM. BPM wywołuje następnie wywołanie zwrotne CECR, które rejestruje każde un
Reply
#2
Dobra robota! + Rep
Reply
#3
całkiem schludny, czy nie ma sposobu, aby zapobiec niezamierzonemu zachowaniu dla gości hwbps?
Reply
#4
Fajne rzeczy. Dziękuję za udostępnienie.
Reply
#5
Świetne wydanie. Najpierw zobaczyłem to na Reddicie, więc cieszę się, że widziałem to tutaj. + rep
Reply
#6
Dodano nowe żądanie kontekstu wykonania przechwytywania do próbkowania dynamicznych adresów pamięci. Ta funkcja jest podobna do istniejącego żądania CECR (poprzednio znanego jako CURV), ale umożliwia klientowi kierowanie na bezwzględne adresy wirtualne lub wyrażenia pamięci. Szczegółowy opis znajduje się w pliku readme projektu. Pytania, krytyka i raporty o błędach są mile widziane
Reply




Users browsing this thread: 2 Guest(s)