Co wywołuje funkcja Windows Do Before Main()?

Question

System Windows musi zrobić coś, aby przeanalizować nagłówek PE, załadować plik wykonywalny do pamięci i przekazać argumenty wiersza poleceń do main().

Korzystanie OllyDbg mam ustawić debugera do przerwy na main(), więc mogłem zobaczyć stos wywołań:

Wydaje się jakby symbole brakuje więc nie możemy dostać nazwę funkcji, tylko jej adres pamięci widoczny. Jednak widzimy, że głównym wywoływaczem jest kernel32.767262C4, który jest kłamcą ntdll.77A90FD9. W kierunku dołu stosu widzimy POWRÓT do ntdll.77A90FA4, który uważam za pierwszą funkcję, która kiedykolwiek zostanie wywołana, aby uruchomić plik wykonywalny. Wydaje się, że godnymi uwagi argumentami przekazywanymi do tej funkcji są: Windows Structure Exception Handler address oraz punkt wejścia pliku wykonywalnego.

Jak dokładnie te funkcje kończą się na załadowaniu programu do pamięci i przygotowaniu go do wykonania punktu wejścia? Czy debugger pokazuje cały proces wykonywany przez system operacyjny przed main()?

Answer 1

jeśli zadzwonisz systemu CreateProcess wewnętrznie zadzwonić ZwCreateThread[Ex] stworzyć pierwszy wątek w procesie

podczas tworzenia wątku - ty (jeśli bezpośrednie połączenie ZwCreateThread) lub system zainicjować rekord nowego wątku CONTEXT - TUTAJ Eip(i386) lub Rip(amd64) na punkt wejścia wątku. jeśli to zrobisz - możesz podać dowolny adres. ale kiedy zadzwonisz, powiedz Create[Remote]Thread[Ex] - jak mówię - wypełnij system CONTEXT i ustaw samoczynną rutynę jako punkt wejścia wątku. Twój oryginalny punkt wejścia zostanie zapisany w rejestrze Eax(i386) lub Rcx(amd64).

Nazwa tej procedury zależała od wersji systemu Windows.

wcześniej to było BaseThreadStartThunk lub BaseProcessStartThunk (w przypadku od CreateProcess nazywany) od kernel32.dll.

, ale teraz system określa RtlUserThreadStart z ntdll.dll. RtlUserThreadStart zwykle wywołuje BaseThreadInitThunk od kernel32.dll (z wyjątkiem rodzimych (uruchamianie rozruchu) aplikacji, takich jak smss.exe i chkdsk.exe, które nie mają w ogóle przestrzeni adresowej w ogóle). BaseThreadInitThunk już wywołuje swój pierwotny punkt wejścia wątku i po (jeśli) go zwróci - RtlExitUserThread wywołana.

głównym celem tego wspólnego wątku startowego owijki - zestaw najwyższym poziomie SEH filtr. tylko dlatego, że możemy nazwać funkcję SetUnhandledExceptionFilter. jeśli wątek rozpoczyna się bezpośrednio od punktu wejścia, bez opakowania - funkcja Top level Exception Filter staje się niedostępna.

ale niezależnie od punktu wejścia wątku - wątku w przestrzeni użytkownika - NIGDY zacznij wykonywać od tego punktu!

wcześnie, kiedy użytkownik rozpoczyna wątek Tryb wykonać - System APC wstawić do wątku z LdrInitializeThunk jako APC-rutyna - odbywa się to poprzez kopiowanie (zapisz) wątek CONTEXT do stosu użytkownika, a następnie zadzwonić KiUserApcDispatcher który nazywamy LdrInitializeThunk.gdy zakończy się LdrInitializeThunk - wracamy do KiUserApcDispatcher, który wywołał NtContinue z zapisanym wątkiem CONTEXT - dopiero po tym, jak już zaczyna się wykonywanie punktu wejścia wątku.

, ale teraz system wykonuje pewne optymalizacje w tym procesie - kopiuje (zapisuje) wątek CONTEXT do stosu użytkownika i wywołuje bezpośrednio LdrInitializeThunk. na końcu tej funkcji wywołana - i wykonywany jest punkt wejścia wątku.

tak KAŻDY wątek rozpocząć wykonywać w trybie użytkownika z LdrInitializeThunk. (tej funkcji z dokładnie nazwie istnieje i nazywa się we wszystkich wersjach Windows z NT4 do win10)

Co to jest funkcja zrobić? bo co to jest? możesz być słuchać powiadomienia o DLL_THREAD_ATTACH? kiedy rozpoczyna się nowy wątek w procesie (z wyjątkiem specjalnych obrobionych przez system wątków, takich jak LdrpWorkCallback) - przechodzi on przez załadowaną listę DLL i wywołuje punkty wejściowe bibliotek DLL z powiadomieniem DLL_THREAD_ATTACH (oczywiście, jeśli DLL ma punkt wejścia i DisableThreadLibraryCalls nie jest wywoływany dla tej biblioteki DLL). ale w jaki sposób jest to realizowane? Dzięki LdrInitializeThunk, które wymagają LdrpInitialize ->LdrpInitializeThread ->LdrpCallInitRoutine (DLL dla PE)

gdy pierwsza nić na początku procesu - jest to przypadek szczególny. potrzeba wielu dodatkowych zadań do inicjalizacji procesu. w tej chwili tylko dwa moduły załadowane w procesie - EXE i ntdll.dll. LdrInitializeThunk zadzwoń pod numer LdrpInitializeProcess dla tego zadania. jeśli bardzo krótko:

1. różne struktury proces jest inicjowany
2. ładowanie wszystkich DLL (i ich rodzin), do którego EXE statycznie powiązane - ale nie nazywają EPS!
3. nazywa LdrpDoDebuggerBreak - funkcja wygląd - są debugger dołączone do procesu, a jeśli tak - int 3 nazywa - tak debugger otrzymać wiadomość Wyjątek - STATUS_BREAKPOINT - większość debugery mogą rozpocząć debugowanie rozpocząć UI tylko z tego punktu. jednak istnieje debugger (S), które pozwoli jak proces debugowania z LdrInitializeThunk - wszystkie moje screeny z tego rodzaju debuggera
4. ważny punkt - aż w procesie wykonywany kod tylko z ntdll.dll (i może wynosić od kernel32.dll) - kod z innego Pliki DLL, jakikolwiek kod firm zewnętrznych, który nie został jeszcze wykonany w procesie.
5. Opcjonalny załadowany shim dll do przetworzenia - Zainicjowano silnik Shim. ale jest to opcjonalne
6. spacer przez załadowanej listy DLL i wywołać jego EPki z DLL_PROCESS_DETACH

7. TLS inicjacji i wywołania zwrotne TLS zwanych (jeśli istnieje)

8. ZwTestAlert nazywa - to sprawdzenie połączenia są istnieć APC w wątek kolejki i wykonaj jego. ten punkt istnieje we wszystkich wersjach od NT4 do win 10.To pozwoli na przykład stworzyć proces w zawiesinie w a następnie wstawić połączenia APC (QueueUserAPC), aby gwint (PROCESS_INFORMATION.hThread) - w wyniku tego połączenia będzie wykonywane po zakończeniu procesu zostanie całkowicie inicjowane wszystkie DLL_PROCESS_DETACH nazywa, ale przed EXE Punkt wejścia. w kontekście pierwszego wątku procesu.

9. i NtContinue nazywa wreszcie - to przywrócenie zachowanego kontekstu wątek i wreszcie przejść do wątku EP

przeczytać również Flow of CreateProcess