Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - Wersja do druku +- SafeGroup (https://safegroup.pl) +-- Dział: Forum ogólne (https://safegroup.pl/forum-6.html) +--- Dział: Programowanie - języki i technologie (https://safegroup.pl/forum-34.html) +---- Dział: C#, VB, VC++ .NET (https://safegroup.pl/forum-38.html) +---- Wątek: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) (/thread-10269.html) |
Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - chomikos - 14.04.2016 Przez ostatnie kilka dni siedziałem, wykorzystywałem przycisk "Search" w wyszukiwarce Google aż nazbyt dużo razy, gdyż próbowałem znaleźć jakiś sposób, na autoochronę w C#. Jest to strasznie ciekawe zagadnienie, dlatego postanowiłem o tym napisać. Od razu mówię, post nie będzie zbyt ładny, tekst będzie dość precyzyjny. UWAGA Aby zakończyć proces uruchomiony z użyciem następującego kodu, wymagane są uprawnienia administratora (ring 1), a więc sposób ten nie jest całkowicie efektywny. Krótko mówiąc, działa on na takiej zasadzie - uruchamia proces z wirtualnego konta innego użytkownika, co wykorzystuje Windowsowe restrykcje do zablokowania możliwości ubicia procesu, jeśli nie ma się wystarczających uprawnień. Wykorzystane źródła (większość msdn, trochę pinvoke (bez którego trwało by to wieki (znajdowanie DLL z danymi funkcjami w systemowym API pod C# <3)) i jeden blog, gość pisał niemal to samo co ja (znalazłem jak szukałem informacji o RawSecurityDescriptor)): Cały kod jest dostępny tutaj: [Aby zobaczyć linki, zarejestruj się tutaj] A więc prócz zadeklarowanych przestrzeni nazw, musimy pobawić się trochę z WinAPI, a szczególnie dwoma bibliotekami - advapi32.dll oraz kernel32.dll. Będziemy potrzebować tylko kilku funkcji. Zacznijmy od advapi32 i funkcji GetKernelObjectSecurity (boolean) Kod: [DllImport("advapi32.dll", SetLastError = true)] Dalej advapi32 i funckja SetKernelObjectSecurity (boolean, analogicznie - tu set, tam get) Kod: [DllImport("advapi32.dll", SetLastError = true)] Kod: [DllImport("kernel32.dll")] Kod: private static RawSecurityDescriptor GetProcessSecurityDescriptor(IntPtr processHandle) Co tu się dzieje? Jako argument funkcji mamy podać uchwyt do aktualnego procesu. Zgodnie z MSDN tworzymy stały typ int o wartości 0x00000004 (advice WinAPI), dalej tablicę bajtów o zerowej wielkości, i typ int bez znaku, w którym określimy potem ilość bajtów które muszą zostać sparsowane. Teraz korzystamy z naszego "gettera" -> getKernelObjSec (pierwszy omówiony dllimport) z takimi argumentami, które ta funkcja WinAPI wymaga. Wyrzuci ona nam jednak do naszego uinta BytesNeed pewną ilość, która jest nam potrzebna do poprawnego działania aplikacji. Jeżeli jest < 0 albo większe od 32767 wyrzuci ona nam wyjątek (MSDN), podobnie, jeżeli operacja "gettera" się nam nie uda (jest on typem BOOL). W przeciwnym razie (który dzieje się prawie zawsze) zostanie nam zwrócony poprawny RawSecurityDescriptor (dokładnie DACL (Discretionary Access Control List)), na którym możemy spokojnie operować. Teraz stworzyliśmy coś w stylu gettera na DACL, teraz musimy mieć możliwość ustawienia go wedle naszych własnych preferencji. Kod: private static void setProcessSecurityDescriptor(IntPtr processHandle, RawSecurityDescriptor dacl) //ustawiamy DACL Teraz musimy stworzyć coś w stylu listy z wartościami wykorzystywanymi przez WinAPI, a dokładniej DACL i ACE (Access Control Entries). Nadaje się do tego idealnie enum, w którym to zhardcodujemy te wartości (a w zasadzie flagi). Jak zwykle MSDN jest naszym zbawieniem Kod: [Flags] I w zasadzie tyle. Teraz pozostało nam tylko stworzyć nowe ACE i powiedzieć programowi, aby z nich korzystał. Robi się to mniej więcej tak (żywcem z tamtego bloga): Kod: IntPtr hProcess = GetCurrentProcess(); Ja to sobie wrzuciłem do voida, i mam to jako funkcję. Spróbujmy teraz dany program tak uruchomiony "zabić". (polecenie taskkill /im <nazwapliku>) [Aby zobaczyć linki, zarejestruj się tutaj] Jak widać działa! Nie mamy możliwości zakończenia działania procesu bez uprawnień administratora.To by było na tyle, jeżeli macie pomysły jak lepiej napisać taki mechanizm, proszę piszcie, także, jak czegoś nie rozumiecie również. Liczę na Ciebie @TW RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - M'cin - 16.04.2016 Kapitanie, a takie jedno pytanie, tak na szybkości... Szansa, że taki program się zawiesi, i Windows go nie zamknie, bo odmowa dostępu, to są? Uprzedzając, w C# ja nigdy nic... RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - Konto usunięte - 16.04.2016 IMO (ale strzelam) jak się zawiesi to go nie ubijesz z wiersza poleceń, ale z menadżera zadań już tak - bo on wymaga uprawnień admina. No ale... chomikos może puść mu tam coś typu sleep albo sleep + nieskończony loop i zobacz, czy da się ubić? Pewnie tak A sam temat - chylę czoła, bo ja sam w C# i owszem, coś robiłem, ale raczej okienkowo RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - chomikos - 16.04.2016 (16.04.2016, 12:31)lukasamd napisał(a): Można to też zastosować do aplikacji okienkowych Ale kontynuując - Process Hacker też nie ubija jeżeli jest uruchamiany poprzez control+alt+delete lub z paska, zapewne także taskmgr tak samo. [Aby zobaczyć linki, zarejestruj się tutaj] Cały czas zastanawiam się, jak Kardo u siebie zrobił autoochronęCytat:Kapitanie, a takie jedno pytanie, tak na szybkości...Się nawet nad tym nie zastanawiałem Ale raczej da rady go zamknąć bo to już z poziomu systemu. W sumie to ciekawy grunt pod exploitacje Windowsa. RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - M'cin - 16.04.2016 Próbuj. Jestem ciekaw RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - tachion - 17.04.2016 Chomik A czemu nie używasz parametru /f na końcu np. C:\>Taskkill /IM firefox.exe /F dodatkowo ten parametr powoduje siłowe zamykanie procesu. RE: Próba stworzenia mechanizmu autoochrony (SELF-DEFENCE) - chomikos - 18.04.2016 (17.04.2016, 20:39)tachion napisał(a): @tachion: [Aby zobaczyć linki, zarejestruj się tutaj] |