Zine.net online

Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc
w Szukaj

mgrzeg.net - Admin on Rails :)

Xperf a autoruns

Podczas startu systemu uruchamianych jest sporo rozmaitych procesów i zaglądając do menadżera zadań często zadajemy sobie pytanie: "a skąd to się tu wzięło?". Najczęściej w takich przypadkach sięgamy po Autoruns Sysinternals, z pomocą którego możemy precyzyjnie ustalić co jest uruchamiane w czasie startu, nie wspominając w tym momencie o innych możliwościach tego narzędzia.


Rys 1. Autoruns

Podobnie, mając log xperf możemy czasem zapragnąć odtworzyć drzewo procesów i ustalić rzeczywiste pochodzenie danego procesu. Przygotowując log zgodnie z opisem z poprzednich moich wpisów bez trudu będziemy w stanie to zrobić. Dziś dwa przykłady, resztę pozostawiam wyobraźni i inwencji czytelnika.

Process Lifetime

Zaczynamy od sprawdzenia listy procesów wraz z ich czasem życia.


Rys 2. Process Lifetimes & Generic Events

Ładujemy plik .etl do xperfview, znajdujemy 'Process Lifetimes', prawa mysz -> Process Summary Table. Przy okazji polecam zapoznanie się z 'Image Summary Table' - można dowiedzieć się jakie pliki były ładowane - ich wersje, etc.
Dobieramy w kolumnach nazwę, ścieżkę uruchamianego procesu, Process ID, Parent Process ID, sortujemy po Start Time i właściwie mamy wszystko, czego możemy w tym momencie potrzebować.


Rys 3. Process Lifetimes

1. Programy uruchamiane przez explorer.exe.
Na Rys 3 widzimy, że proces z linii 46 (2284) został uruchomiony przez process o ID=1756, czyli explorer.exe z linii 32. Podobnie widzimy, że procesy z linii 45, 47, 50 również mają jako swojego przodka process 1756, a zatem zostały utworzone przez explorer.exe. Możemy się domyślać, że eksplorator załadował te procesy w ramach autostartu.

2. Taskeng
Nieco ciekawiej wygląda sprawa procesów 468 (SmartDefrag.exe), 1068 (AutoUpdate.exe), 1212 (AutoSweep.exe), etc., mających wspólny proces macierzysty - 1980, czyli taskeng.exe. Zauważmy, że nie jest to jedyne wystąpienie procesu o tej nazwie - w linii 34 oraz 35 mamy dwa inne, uruchomione jednak z innymi parametrami command line, a jednym z potomków jednego z tych procesów (1880) jest proces o ID=1968 (GoogleUpdate.exe).
Sam Taskeng.exe jest procesem potomnym procesu svchost.exe (984), który jest hostem m.in. usługi "Harmonogram zadań".

Generic Events

Zajrzyjmy teraz w inne miejsce - do 'Generic Events'. Prawa mysz -> 'Summary Table'. Ustawiamy sobie Provider Name, Event Name, Process Name, Task Name, a z prawej Count, Opcode Name, Time, Task, Opcode i kolejne Field 1, 2, etc.

1. Explorer
Znajdujemy dostawcę o nazwie 'Microsoft-Windows-Shell-Core', rozwijamy listę zdarzeń i znajdujemy 'Microsoft-Windows-Shell-Core/Explorer_ExecutingFromRunKey/win:Start', po czym ponownie rozwijamy. Po dalszych kilku '+' bez trudu odnajdziemy w Field 1 ścieżki do procesów, które widzieliśmy poprzednio na liście procesów. Zauważmy przy okazji, że znaleźliśmy też process runonce.exe (na liście ID=2292) oraz jego proces potomny (AvastUI, 2364), także uruchamiane w ramach tego tasku.


Rys 4. Explorer -> Run

2. Taskeng
Podobnie jak wyżej, rozwijamy provider 'Microsoft-Windows-TaskScheduler', znajdujemy zdarzenie 'Microsoft-Windows-TaskScheduler/task:JobExecute/win:Start' i klikając dalsze '+' dochodzimy do listy zadań, które bez trudu odnajdziemy w Harmonogramie zadań. Nieco niżej znajdziemy zadanie 'Microsoft-Windows-TaskScheduler/task:LogonTrigger/win:Info', czyli zestaw zadań uruchomionych podczas logowania. W pozostałych polach znajdziemy takie informacje jak UserContext (tudzież UserName), czy InstanceId, ale o tym innym razem.


Rys 5. Task scheduler - spojrzenie z xperf

Gdy przyjrzymy się jeszcze raz procesom z Process Lifetimes oraz ich odpowiednikom w Generic Events, to okaże się, że każda instancja taskeng.exe powiązana jest z innym użytkownikiem i to ona uruchamia kolejne zadania.

Dzięki prostemu powiązaniu listy procesów ze zdarzeniami, które nie mają swojego dedykowanego wykresu i trafiły do Generic Events udało nam się zrekonstruować źródła tworzenia procesów, co na pewno może ułatwić podjęcie decyzji co z nimi dalej robić: zachować, czy jednak usunąć.

W ten oto piękny sposób dotarliśmy do miejsca będącego wstępem do kolejnego wpisu, w którym popatrzymy, co też możemy wygrzebać z lsass.exe odnośnie harmonogramu zadań i dlaczego następujące wywołanie:
LogonUserW("@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAMEA3AQNAEEADBwMAMDA0AQLAQEAwAANAcDAtAANAcDA3AwQA0CABBANAQDA4AQLAIDAGBQQAkDACBAMAADACBAOAIDA0AQNA0HA", NULL, NULL, LOGON32_LOGON_BATCH, LOGON32_PROVIDER_DEFAULT, 0x0000000001635648)
w ramach usługi "Task Scheduler" kończy się sukcesem i utworzeniem żetonu użytkownika, pomimo przedziwnej nazwy użytkownika i nulla w miejscu domeny i hasła.

Opublikowane 19 lutego 2013 21:09 przez mgrzeg

Powiadamianie o komentarzach

Jeżeli chciałbyś otrzymywać email gdy ta wypowiedź zostanie zaktualizowana, to zarejestruj się tutaj

Subskrybuj komentarze za pomocą RSS

Komentarze:

Brak komentarzy

Co o tym myślisz?

(wymagane) 
(opcjonalne)
(wymagane) 

  
Wprowadź kod: (wymagane)
Wyślij

Subskrypcje

W oparciu o Community Server (Personal Edition), Telligent Systems