Identyfikowanie funkcji edytującej rejestr systemu

Czy wiecie może jak zidentyfikować w kodzie (assemblera) miejsce, w którym wywoływana jest funkcja, która zmienia wartość klucza DWORD w rejestrze systemu? Jak byście do takiego problemu podeszli? Działam w x64dbg. Rejestr nazywa się MRUCount, chociaż ta informacja nie jest istotna.

Zlokalizowałem plik .dll (Hex editorem), w którym została użyta ta nazwa. Następnie zdebugowałem ten plik i szukałem tej frazy w kodzie assemblera - niestety nie występuje.
Chcę się dowiedzieć skąd ładowana jest wartość do tego rejestru?

Nigdy nie korzystałem z x64dbg, ale w IDA najłatwiej chyba by było znaleźć referencje do ciągu "MRUCount", a następnie sprawdzić, pod którą referencją znajduje się kod edytujący rejestr. W x64dbg pewnie też jest podobna opcja. Ewentualnie poszukaj innych dezasemblerów. Może radare2 się nada. Nie wiem, bo też nie miałem jeszcze okazji korzystać. :D

Jak jedynym narzędziem które znasz jest młotek, to wszystko wydaje się gwoździem :P.

Modyfikacja rejestru systemu to tak "głośna" operacja że prawie każde narzędzie to potrafi wyłapać. Używanie debuggera tutaj jest możliwe, ale przekombinowane.

Banalnie proste rozwiązanie - użycie czegoś w rodzaju procmon (z sysinternals suite). Procmon loguje stacktrace, więc jesteś ustawiony od razu. Ma to tą zaletę że nie musisz z góry wiedzieć nawet który program zmienia ten klucz (chociaż w Twoim przypadku wiesz, z tego co rozumiem).

Drugie rozwiązanie, bardziej złożone - użycie apimon (albo innego programu hookującego wywołania funkcji) i zaczajenie się na wywołanie RegSetValueEx/RegOpenKeyEx. Później analogicznie, szukasz stacktrace.

Jesli chcesz utrudniać sobie życie i hackersko używać niskopoziomowych narzędzi, to już lepiej użyć dobrego dizasemblera, zlokalizować tam ten string, i znaleźć odwołania do offsetu pod ktorym się znajduje w kodzie - z odpowiednim narzędziem powinno na to zejść kilka minut max (z IDĄ 30 sekund).

A jeśli jesteś fanem debuggerów, to zrób tak - wczytujesz program który robi to co Cię interesuje do debuggera i robisz breakpointa na main/EP. Następnie szukasz tego stringa w pamięci (szukaj go jako bajtów za pomocą debuggera - musi występować jeśli dll zostało załadowane do procesu, a jeśli nie ma żadnych cudów to będzie załadowana od razu). Następnie stawiasz jednobajtowy hardware breakpoint na read na początku napisu. Uruchamiasz program, breakpoint powinien zostać triggerowany. Wtedy patrzysz na stacktrace (prawdopodobnie znajdujesz się w jakiejś funkcji z Advapi32), i cofasz się nim aż trafisz na ramkę stosu z programu który Cię interesuje.

Bardzo fajne narzędzie ten Process Monitor. W narzędziach rzeczywiście jest Stack Summary, który pokazuje mi jakie funkcje zostały wykonane. Znalazłem interesującą mnie funkcję oraz został zlokalizowany plik .dll który tą funkcję wykonał. Jest też przedstawiony offset dla tej funkcji w postaci "0x173f3" oraz w postaci "nazwa_funkcji + 0x43". Jak teraz mam w x64dbg zlokalizować tą funkcję w tym pliku? Czy mogę już skoczyć w interesujące mnie miejsce w kodzie assemblera?

Druga sprawa to czy znacie jakieś narzędzie do porównywania kodu assemblera dwóch plików (w którym miejscu są różnice)

Trzecia sprawa: Jak chcę w x64dbg otworzyć plik A.dll to w oknie pojawia mi się że jestem w pliku ntdll.dll mimo że otworzyłem plik A.dll. Chcę pójść to określonego offsetu w pliku A.dll, ale niestety offset wykonuje się na pliku ntdll.dll

A czy da się sprawić aby program rozpoczął debugowanie programu i w pewnym momencie odczepił się od programu. Nie chcę, aby program debugowany zamykał się wraz z debuggerem.

@dawido000

1. W x64dbg w zakładce memory map będziesz miał wszystkie załadowane dll i regiony pamięci dla nich, dwuklik ustawci ci CPU view na ten region i możesz tam sobie wstawiać breakpointy.
2. Musialbyś zrobić attach to process i dopiąć się do istniejącego procesu żeby tak zrobić.

Najciekawsze jest to, że udało mi się w pewnym programie zmienić ilość pozostałych dni używania programu w wersji trial i w trybie debugowania program odpala się z tą ilością dni. Ale kiedy robię patcha. I uruchamiam program z patchem bez debuggera to program jakby wykrywa na początku jakąś ingerencję i kończy program zwracając wartość 0 do systemu. Czy to jakiś rodzaj zabezpieczenia? Czy da się jakoś łatwo znaleźć miejsce w którym postanawia wyjść z programu?

Bardzo możliwe że program ma gdzieś sumę kontrolną i testuje czy nie był modyfikowany, niemniej to dość dziwne że działa pod debugerem.

No właśnie moim zdaniem nie. Program uruchamia się wykonuje sumy kontrolne itp. , wszystko się zgadza. Leci dalej kontroluje ilość dni trial. Ja je podmieniam i się uruchamia. Oczywiście to wszystko pod debuggerem. A kiedy już plik już jest na samym początku spachowany to sumy kontrolne mają już na początku wartość false i program się wyłącza wtedy.

Jeśli to jest dllka, i ty ją zmieniasz, no to przed wykonaniem LoadLibrary w exe programu, może być generowana suma kontrolna i jest ona sprawdzana. Sobie launcher z injectem napisz, żeby poczekać aż exe wykona LoadLibrary (najlepiej zrób hooka), podmień instrukcje w dllce, i ciesz się nielimitowanymi rozmowami w Orange... A nie.. to nie tu. Tak czy inaczej, tutaj raczej nikt ci nie pomoże w sprawach crackowania.

Ok dzięki. A mam jeszcze pytanie:

Jak zlokalizować na podstawie tego wyrażenia wartość pamięci kopiowanej do rejestru eax. Rozumiem, że to jest adres w pamięci ale jak szybko do niego przeskoczyć?

Myślałem o wirtualce. Na pewno przetestuję. Póki co mam chęć jeszcze powalczyć na tej drodze, którą idę. Jutro dam znać co z kliknięciem na ten adres, aby wyświetlił się w widoku pamięci.

Możesz kliknąć sobie na to i dać "follow in dump -> selected address" i pokaże ci w co tam leży w pamięci, a możesz też dać "search for -> current region -> string references" i znajdzie ci odwołania do stringów w pamieci z tego obszaru.

Shalom napisał(a):

Możesz kliknąć sobie na to i dać "follow in dump -> selected address" i pokaże ci w co tam leży w pamięci, a możesz też dać "search for -> current region -> string references" i znajdzie ci odwołania do stringów w pamieci z tego obszaru.

A jak znaleźć instrukcje w assemblerze, które wcześniej modyfikują tą pobieraną wartość

Chodzi ci o wyłapanie instrukcji które zapisują coś w tym obszarze pamięci? Możesz wstawić hardware breakpoint na ten blok. Jak klikniesz prawym klawiszem w widoku hexdump (tam gdzie cie przeniesie "follow in dump -> selected address" to możesz taki breakpoint postawić. Wtedy debugger będzie się zatrzymywał podczas modyfikacji tej pamięci.

Shalom napisał(a):

Chodzi ci o wyłapanie instrukcji które zapisują coś w tym obszarze pamięci? Możesz wstawić hardware breakpoint na ten blok. Jak klikniesz prawym klawiszem w widoku hexdump (tam gdzie cie przeniesie "follow in dump -> selected address" to możesz taki breakpoint postawić. Wtedy debugger będzie się zatrzymywał podczas modyfikacji tej pamięci.

Ok. Ale jest tutaj pewna niekonsekwencja. Mam taką linijkę kodu:

a w pamięci mam takie wartości:

tryb unsigned long (32-bit):

tryb unsigned long (16-bit):

Co ciekawe do rejestru eax kopiowana jest wartość 57096 (decymalnie) lub (DF08) hex. Wartość ta ma inny adres tj. 3D1202C.

Musiałby się wypowiedzieć ktoś trochę lepiej obeznany z tym tematem (@msm, @Rev, @Gynvael Coldwind) bo jedyne co przychodzi mi do głowy to memory misalignment, tzn fakt że tam jest mov z adresu który nie jest wielokrotnością 64bitów/8 bajtów stąd też faktyczny read odbywa się na przesuniętym adresie.