globalny hook na dowolną funkcję

0

Chcę założyć hooki (takie funkcje callbackowe, nie wiem jak to się po polsku tłumaczy) na niektóre funkcje w pewnych plikach dll i exe (a dokładniej funkcje send(), recv() w winsock, i któraśtam odpowiedzialna za majdanie w rejestrze co by monitorować i ewentualnie blokować "śmieciarzy" + parę hooków dla zabawy żeby umić). Znalazłem parę rzeczy na ten temat ale polegają na statycznym (hardcode... tak to jest jak się człowiek po angielsku uczy) wstrzyknięciu funkcji i odwołującej się do niej instrukcji skoku (JMP). Niestety to wymaga modyfikacji pliku z kodem docelowym a ja chciałbym żeby to był taki program który hookuje inny proces i żeby to działało bez statycznej modyfikacji pliku (dll/exe). Da się tak <ort>w ogóle</ort>? Jak?

Z góry dziękuję

0

wyszukujesz ten proces, suspendujesz, otwierasz jego pamiec, alokujesz/znajdujesz sobie tam wolne miejsce, zapisujesz do niego kod Twoich funkcji, (mozesz teraz np. stworzyc w procesie (wciaz zdalnym!) watek). analizujesz pamiec tego procesu w poszukiwaniu tablicy importow, nadpisujesz oryginalne adresy funkcji Twoimi adresami funkcji tych co wlasnie zapisales, ale zeby proces nie zauwazyl nic - te Twoje funkcje musza w koncu wywolac te wlasciwe oryginalne funkcje przez_oryginalne wskazniki. hm.. no i gotowe

0

a tak trochę techniczniej...
znalazłem proces, jakoś zawiesiłem (znajdę to sobie, na bank gdzieś jest) i teraz szukam wolnej pamięci. czyli mam grzebać w jego rejonach ramu, jak to się robi? bo próbowałem kiedyś przejrzeć pamięć po prostu robiąc memcpy( bufor, (void*)adres, sizeof(typ_bufora) ) gdzie adres to int z numerem komórki ale wywalało mi błąd Access Violation.

potem mam wrzucić tam kod swojej funkcji, czyli memcpy() do tej wolnej pamięci procesu docelowego, z &moja_funkcja(), ale ile? jak sprawdzić rozmiar? jakaś sekwencja bajtów? w ogóle może macie jakieś linki do materiałów które uczą jak rozpoznać widząc chociarzby hexy (chciałbym) poznać że tu zaczyna się funkcja a tu kończy, tu zaczyna się program a tu kończy...

na koniec mam znaleźć funkcję którą chcę zhookować (w dll jakimiś funkcjami importującymi chyba się to znajdzie, tak?) i zmienić coś (no właśnie co? bo mógłbym np. w każdym JMP X gdzie X = adres tej funkcji zmienić X na adres mojej funkcji ale to chyba nie tak) na adres mojej funkcji, w której pod koniec robię _asm(JMP adres_który_nadpisałem) (domysł, nie znam asamblera, mam zamiar w wakacje się za to zabrać)

dobrze zrozumiałem?

0

troszke tektu na temat: http://4programmers.net/Forum/366882
zamiescilem tam link do czegos nowego, zwanego DetourAPI. Nie bawilem sie tym, ale to powinno byc super narzedzie do wlasnie robienia takich rzeczy!

a ogolnie to kojarzysz dobrze, tylko narzedzia nie te. funkcje mem* na nic sie nie zdadza, poniewaz musisz zauwazyc ze oba procesy maja .... inna przestrzen adresowa. adres 0x123456 z procesu pierwszego to nie jest to samo co adres 0x123456 z procesu drugiego. nie da sie nawet tego jakos przeliczyc, zoffsetowac, nic. to jest cos jakbys adresy z procesu1 byly po chinsku a z procesu2 po hiszpansku.

po funkcje ktorych potrzebujesz, zerknij na http://msdn2.microsoft.com/en-us/library/aa366781.aspx sekcja 'virtual memory functions', np takie VirtualQueryEx (patrz param#1 tej funkcji)

0

goglując "Import Table" znalazłem to:
http://www.codeguru.com/cpp/w-p/win32/security/article.php/c12253__3/

To chyba dokładnie to o czym mówiłeś

W punkcie 10. jest kod asamblera. Czy jest on potrzebny, czy tylko do pokazania co zostało wrzucone do pamięci procesu? Bo nie widzę odwołania do niego

Są gdzieś jakieś materiały z których się dowiem co to jest to PEB, TEB, sektor FS itd...?

Jestem bardzo wdzięczny za pomoc, dzięki

0
zgubiłemlogin napisał(a)

Są gdzieś jakieś materiały z których się dowiem co to jest to PEB, TEB, sektor FS itd...?

http://en.wikipedia.org/wiki/Win32_Thread_Information_Block <- to jeśli chodzi o rejestr FS

PEB <- po co Ci to? Adres funkcji możesz zdobyć po przez wstrzyknięcie GetModuleHandle, a ten z reguły jest stały w każdym procesie odpalonym pod daną kopią systemu.

Co do IAT przejrzyj ostatnie wątki w tym dziale i dziale inne.

[edited]
Jestem mocno zmęczony ale sposób opisany w podanym przez Ciebie artykule jest zdeka przymulający... Problem hooków był już nieraz poruszany na forum. Ogólnie obstało przy rozwiązaniu przekierowań w podstawionych bibliotekach.

0

No nawet bardzo przymulający. Ciągle próbuję go zrozumieć (niezbyt mi to wychodzi). Autor jeszcze do tego używa nagłówka ntundoc.h który najwyraźniej jest niestandardowy (jest dołączony do przykładowego kodu). Przyznaję się, nie rozumiem tego. To znaczy ogólną technikę tak, ale po prostu nie mogę się w tym kodzie połapać. Autor ciągle coś czyta z pamięci nie opisując co czyta, po co mu to, jak można to znaleźć inaczej niż przepisując ten kod (np. skąd tam się wzięły te przesunięcia bitowe, wiem że to dlatego że wskaźnik jest na początek a trzeba coś ze środka, ale skąd wiadomo że o tyle przesunąć).

Jest może łatwiejszy sposób (ale inny niż gotowy interfejs)? Szukałem na forum ale większość to hooki z funkcji SetWindowHookEx a to nie potrafi się podszyć pod funkcję (chyba że da się tym).

0

Wczoraj zmęczenie widocznie dało się we znaki, nie skumałem, że chodzi Ci o globalnego hooka ;) W tym wypadku numer z podstawianiem DLLi jest troszke nie na miejscu.

Artykuł, który przytoczyłeś pokazuje jak przechwycić wywoływaną funkcję zastępując odniesienie do niej w tablicy przetrzymującej adresy do "załadowanych" funkcji bibliotecznych. Krótko mówiąc wygląda to tak:

  1. wywołanie: funkcja(); <--- w programie

  2. odczytanie adresu z tablicy <--- w tym przypadku jest to adres naszej funkcji przechwytującej

  3. skok do funkcji przechwytującej

  4. skok do właściwej funkcji API

W normalnych warunkach odbyło by się to bez punktu 3. Ten sposób jest dość dobry ale nie zastosujesz go w momencie kiedy ktoś zdobędzie adres do funkcji poprzez GetProcAddress.

SetWindowsHookEx AFAiR to tylko część odpowiadająca za zarażenie procesu. Działa to tak, że kod Twojego Hooka wykonuje się w każdym możliwym procesie. Równie dobrze możesz zarazić wybrany proces poprzez DLL injection wykonując CreateRemoteThread pod adresem LoadLibrary w procesie, który chcesz zarazić. W tym wypadku jako parametr przekazujesz adres nazwy Twojej biblioteki, którą chcesz wstrzyknąć. Firewalle są dość wrażliwe na ten sposób dlatego możęsz także wrzucić swój kod do przestrzeni atakowanego procesu i użyć na nim CreateRemoteThread z parametrem zawierającym dane. Przykładowy kod znajduje się na cc-team.org.

Samo przechwycenie funkcji możesz zrobić totalnie łopatologicznie w taki oto sposób:

Kopiujesz w bezpieczne miejsce klika pierwszych bajtów z funkcji, którą chcesz przechwycić. Zastępujesz skopiowane dane skokiem do funkcji przechwytującej. Wykonujesz co Ci trzeba i skaczesz do miejsca gdzie masz przekopiowane bajty, a po ich wykonaniu skaczesz z powrotem do funkcji API.

0

a to: http://www.gamedev.net/community/forums/topic.asp?topic_id=359794

chyba działa, ort! z biblioteki apihijack, a ta z kolei ma funkcję RedirectIAT, czyli też tabela importów... tylko że dokumentacji tego nie mogę znaleźć, to chyba przechodzi przez wszystkie procesy i sprawdza czy ort! z celu, jak tak to przekierowuje

jak się mylę to mnie poprawcie

0

Istnieje prosty sposób na załadowanie własnej biblioteki do innego procesu .

Na podstawie "Rootkity - sabotowanie jądra systemu" -
Greg Hoglund , James Butler
W systemach Windows NT/2000/XP/2003
dostępny jest klucz rejestru o nazwie :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
...
..
W momencie uruchamiania aplikacji korzystającej
z biblioteki User32.dll razem z tą biblioteką do przestrzeni
adresowej aplikacji ładowane są wszystkie biblioteki wymienione w podanym kluczu rejestru .

(osobista uwaga - ze względu na to że biblioteka będzie załadowana do każdego
procesu używającego User32.dll (jeśli bibliotekę umieścimy w katalogu system32 lub system)
należy zaopatrzyć się w dyskietkę
startową win 98 , aby można było ewent. usunąć
ręcznie bibliotekę , źle przemyślana konstrukcja biblioteki
nie pozwoli na uruchomienie systemu :-) .
Oczywiście jeśli system plików to max. Fat32 , dla NTFS niestety nie.

Jeśli umieścimy odpowiedni wpis w kluczu rejestru oraz bibliotekę (.dll)
w katalogu aplikacji to zostanie ona załadowana tylko do przestrzeni
adresowej tej aplikacji .

1 użytkowników online, w tym zalogowanych: 0, gości: 1