[Cpp] Zabezpieczenie pamięci innej aplikacji

Witajcie!
Przyszły takie czasy, że webmasterowi przyszło się pisać anticheata do gry, a więc zwracam się do was tutaj. Sprawa jest następująca: Potrzebuję zabezpieczyć się przed odczytywaniem pamięci danemu procesowi gry, który (ten proces) moja aplikacja utworzyła. Wystarczy zablokować kilka pól żeby wszystkie tandetne boty poszły w pi***, tylko... jak to zrobić? Czy da się z poziomu WinAPI jakoś zmienić status pamięci, tak żeby nic poza jej właścicielem nie mogło jej odczytać? Zakładam że mam w aplikacji prawa administratora.

Z góry dzięki za odpowiedzi.

Data Protection API?
http://msdn.microsoft.com/en-us/library/ms995355.aspx

To jest API do szyfrowania danych, jeśli dobrze się doczytałem. Tylko ja nie mam dostępu do procesu który chcę chronić, więc nie mogę zmienić nic w sposobie w jaki czyta i pisze po pamięci. Może jakoś hooknąć ReadProcessMemory? Tylko jak?

Zerknij tutaj: http://4programmers.net/Forum/C_i_C++/104080-Przechwycenie_funkcji_systemowej moze Ci to pomoze :)

Wielkie dzięki, to jest jakiś krok do przodu. DLL Injection załatwione (póki co teoretycznie), tylko ten sposób nic nie zrobi zewnętrznym programom kradnącym dane z pamięci.

Demonical Monk napisał(a)

DLL Injection załatwione (póki co teoretycznie)

Można wiedzieć w jaki sposób?

Każde 'poważne' zabezpieczenie tego rodzaju to obecnie coś na kształt rootkita...

W praktyce jeszcze tego nie testowałem, skoro hookowanie ReadProcessMemory robi DLL podpięty pod aplikację, to inne injectnięte DLL wywołają ten hook, dobrze mówię?

Dll wstrzyknięty do jednego procesu może hookować tylko w nim. Żeby się 'bronić' przed ingerencją musiałbyś hookować we wszystkich procesach (także nowych) rzeczy typu NtCreateThread, NtMapViewOfSection, LdrLoadDll, NtWriteVirtualMemory, NtQueueApcThread itd. Typowy hook na wiadomości (do 'wstrzykiwania') odpada, dll nie będzie mapowany w procesy nie posiadające pętli komunikatów - bez problemu można rozdzielić dowolny tool na proces roboczy i proces GUI. Największą barierą byłoby zablokowanie NtOpenProcess - bez uchwytu to sobie możesz nagwizdać co najwyżej. Problemem pozostaje uchwyt pochodzący z utworzenia procesu, to już zależy od podejścia.

Nie da się globalnie hooknąć ReadProcessMemory/OpenProcess jakoś?

http://webcache.googleusercontent.com/search?q=cache:rhGbqB2ST1IJ:pastebin.com/BjFCkTpx+hkreadProcessMemory&cd=1&hl=pl&ct=clnk&gl=pl

Coś takiego widziałem któryś raz, tylko tu nie ma rejestracji tego hooka i/lub działa tylko dla lokalnej aplikacji :( Nie rozumiem o co chodzi z tym DETOUR_TRAMPOLINE, ogarnia ktoś co ten kod robi?

No globalnie się niby da - zmodyfikować odpowiednią stronę pamięci fizycznej i łapać wyjątki w kernelu (to tak półżartem). Zawsze można się pobawić hookowaniem na poziomie jądra systemu (wtedy masz pełną niezależność od procesu)), chociaż zrobienie tego 'legalnie' do najprostszych rzeczy nie należy, potem jeszcze pozostaje problem systemów 64-bit, zrobienia tak żeby PatchGuard się nie czepiał itd. Znając życie to ten kod korzysta po części z http://research.microsoft.com/en-us/projects/detours/.

Co do trampoliny - to taki niskopoziomowy obiekt proxy, który służy przekazaniu sterowania ze zmodyfikowanego kodu funkcji do właściwego hooka.

Ogólnie co do wbijania się do pamięci, to chyba mogę po prostu walnąć w pętli:

GetModuleHandle('hook.dll');

I wykryje czy jest załadowana biblioteka bota o który akurat mi chodzi. Bo zabezpieczam się przed typowymi tibiakidami (jest z tego zysk jako tako), które nie potrafią nic poza wysłaniem SMSa. W każdym razie jakby znalazł się inteligentniejszy to go zablokuje - reversować programu na pewno nie będą. Tylko nadal no idea co zrobić z robotami które cisną na ReadProcessMemory i WriteProcessMemory i mają suwerenny proces bez injectowania...

Zaznacze na poczatku - wielkiej wiedzy w temacie nie mam, wiec moge sie mylic, lepiej doczytaj/poczekaj na odp Deusa/dokladnie przetestuj:
Ten sposob z GetModuleHandle ma jedna spora wade(o ile dobrze rozumiem jak chcesz to stosowac) - wystarczy minimalna zmiana nazwy dllki i jakis syf sie przecisnie. Moze zobacz jakie biblioteki laduje gra, zaladuj do jej procesu swoja dllke, ktora na wejsciu odpali dodatkowy watek, ktory bedzie stale kontrolowal aktualnie zaladowane dllki i wywalal te ktorych nie ma na liscie "dozwolonych". Co prawda czesc dllek laduje sie, chociaz nie maja "zlych zamiarow" - np. ggwhook.dll (nie wiem czy jest w nowszych wersjach, ale u mnie jest na 100% i wciska sie do kazdego procesu), ale mysle, ze nic zlego sie nie stanie jak je po prostu wywalisz :)

Co do hookow na poziomie jadra - prawde mowiac tez mi to wpadlo do glowy i chyba bylby to niezly sposob na poradzenie sobie z OpenProcess(tibia, PROCES_HAKIER_ACCESS). Nie mam pojecia jak sytuacja wyglada na systemach 64bitowych(czas zainstalowac.... ech juz od pol roku sie zbieram ;) ), ale sprobuje w wolnej chwili(pewnie w czwartek/piatek) cos klepnac i sprawdzic jak to dziala na xp 32bit - zobaczymy co z tego wyjdzie.

Wiesz, elfbot czy NG ładuje się przez loader.exe, więc zmiana nazwy DLLki nie wchodzi w grę bo loader by przestał działać, a nooba z XVI32 albo innym reshackerem jeszcze nie widziałem. Dobry pomysł z tym kickowaniem DLLek, tylko jak ją wyrzucić i jak sprawdzić jakie są załadowane? Szukałem coś w deseń GetModulesList, ni ma. Moje poszukiwania nieco są utrudnione, albowiem jestem wycięty na microsoft.com, sam nie wiem za co.

Edit: O mam. Zabawnie tak na google cache jechać.

http://webcache.googleusercontent.com/search?q=cache:lJuHWNzYhWYJ:msdn.microsoft.com/en-us/library/ms682631%28v%3Dvs.85%29.aspx+winapi+modules+list+site:msdn.microsoft.com&cd=2&hl=pl&ct=clnk&gl=pl

Sprawdzanie jakie sa zaladowane - http://msdn.microsoft.com/en-us/library/ms682621(v=VS.85).aspx, jezeli uznasz ze dllka jest "zla" to FreeLibrary. Pytanie jaki bedzie efekt jak dllka sie zaladuje odpali jakis watek, a Ty ja(dllke) wywalisz? Teoretycznie powinna obslugiwac "wyladowywanie"-konczyc wszystkie watki, zamykac uchwyty itp, ale watpie w to, ze tworcy takich smieci o tym mysla... Z reszta - po co mieliby to implementowac? Powstaje pytanie czy system sam zajmie sie takim watkiem..?

A w dupie to mam, jak ciśnie na bocie to niech się liczy z crashem. Hooków GG/Tlena nie będę wywalać, tylko te które mają brzydkie sumy kontrolne, manifesty etc.

Ajjj... Coś dziwnego. Kiedy injectowałem testowe DLL wszystko działało, jak injectuję DLL kiedy jest załadowany bot, to DLL jest załadowany, ale w ogóle jakby nie wchodził do DllMaina. Wtf?

Hook na LoadLibrary?