Internet

Środowisko uruchomieniowe trybu debugowania jądra systemu Windows 7. Narzędzia do debugowania trybu jądra systemu Windows

Aby debugować jądro, musisz połączyć się z komputerem za pomocą kabel modemu zerowego lub połączenie modemowe. Komputer wykonujący debugowanie zostanie nazwany „Host”, a nazwa „Cel” zostanie nadana komputerowi powodującemu problemy.

Na obu komputerach musi być uruchomiona ta sama wersja systemu Windows, a pliki symboli dla komputera docelowego muszą być zainstalowane na komputerze hosta. Pliki symboli znajdują się na instalacyjnym dysku CD systemu Windows w katalogu Support\Debug.

Aby włączyć debugowanie, musisz wprowadzić zmiany w pliku BOOT.INI na komputerze docelowym.

1. Zmień atrybuty pliku BOOT.INI:

attrib c:\boot.ini -r -s

2. Edytuj ten plik i do linii Uruchamianie systemu Windows dodaj opcję /debug (aby powiedzieć systemowi, aby ładował debugger jądra do pamięci RAM, gdy Uruchamianie systemu Windows). Dodatkowe opcje to /Debugport, aby poinformować system, którego portu COM użyć (domyślnie COM2) i /Baudrate, aby określić szybkość transmisji (domyślnie 19200 bodów, ale 9600 jest lepsze). Na przykład:

multi(0)disk(0)rdisk(0)partition(0)\WINDOWS="Windows NT" /debug /debugport=com2 /baudrate=9600

3. Zapisz plik.

4. Ustaw poprzednie atrybuty pliku BOOT.INI:

attrib c:\boot.ini +r +s

V ten przykład Komputer docelowy umożliwiał połączenie przez port COM2 z prędkością 9600 bps.

Komputer hosta musi być skonfigurowany z ustawieniami wymaganymi do debugowania. Ponadto należy zainstalować pliki symboli. Aby je zainstalować, przejdź do katalogu \support\debug na instalacyjnym dysku CD i wprowadź następujące polecenie:

expndsym : <целевой диск и каталог>

Na przykład:

expndsym f: d:\symbole

Instalacja może zająć trochę czasu. Pamiętaj, że jeśli dodatki Service Pack zostały zainstalowane na komputerze docelowym, pliki symboli tych pakietów muszą być również zainstalowane na komputerze hosta. Pliki symboli dla dodatków Service Pack można pobrać z witryny internetowej firmy Microsoft.

Następnym krokiem jest skonfigurowanie zmiennych środowiskowych potrzebnych do debugowania, takich jak zmienne określające lokalizację plików symboli i tak dalej. Poniżej znajduje się opis tych zmiennych.

Opis zmiennych systemowych

Definicję tych zmiennych można umieścić w pliku wsadowym, aby uniknąć wpisywania odpowiednich poleceń przy każdym rozruchu:

wyłącz echo
ustaw _nt_debug_port=com2
ustaw _nt_debug_baud_rate=9600
ustaw _nt_symbol_path=d:\symbole\i386
ustaw _nt_log_file_open=d:\debug\logs\debug.log

Teraz musisz skopiować oprogramowanie do debugowania jądra, które znajduje się w katalogu support\debug\<процессор>na płycie instalacyjnej (support\debug\I386). Najprościej jest skopiować cały katalog, bo jest mały (około 2,5 MB). Dla platformy I386 używany jest debugger, który jest dostarczany jako plik I386KD.EXE. Debuger jest uruchamiany za pomocą polecenia I386KD. Aby wprowadzić polecenie, naciśnij kombinację klawiszy i poczekaj, aż pojawi się monit wiersz poleceń kd>.

Termin "debugowanie jądra" oznacza badanie wewnętrznej struktury danych jądra i/lub przechodzenie przez funkcje w jądrze. To debugowanie jest bardzo przydatnym sposobem na poznanie wewnętrznych Urządzenia z systemem Windows, ponieważ pozwala wyświetlić wewnętrzne informacje o systemie, które nie są dostępne w inny sposób, i daje jasny obraz postępu kodu w jądrze.

Przed rozważeniem różne drogi debugowanie jądra, przeanalizujmy zestaw plików, które będą potrzebne do przeprowadzenia wszelkiego rodzaju debugowania.

Symbole debugowania jądra

Pliki symboli zawierają nazwy funkcji i zmiennych, a także schemat i format struktur danych. Są one generowane przez program konsolidujący i są używane przez debugery do odwoływania się do tych nazw i wyświetlania ich podczas sesji debugowania. Ta informacja zwykle nie jest przechowywana w postaci binarnej, ponieważ nie jest potrzebna podczas wykonywania kodu. Oznacza to, że bez tego plik binarny staje się mniejszy i działa szybciej. Ale oznacza to również, że podczas debugowania należy upewnić się, że debuger ma dostęp do plików symboli skojarzonych z obrazami binarnymi, do których odwołuje się sesja debugowania.

Aby użyć dowolnego narzędzia do debugowania trybu jądra do celów badawczych urządzenie wewnętrzne Struktury danych jądra systemu Windows (lista procesów, bloki wątków, lista załadowanych sterowników, informacje o wykorzystaniu pamięci itp.), których potrzebujesz poprawne pliki symbole i przynajmniej plik symboli dla binarnego obrazu jądra, Ntoskrnl.exe. Pliki tabeli symboli muszą odpowiadać wersji obrazu binarnego, z którego zostały wyodrębnione. Na przykład, jeśli jest zainstalowany Pakiet Windows Service Pack lub jakaś poprawka aktualizująca jądro, musisz odpowiednio zaktualizować pliki symboli.

Pobierz i zainstaluj symbole dla różne wersje Windows nie jest trudny, ale nie zawsze można zaktualizować symbole do poprawek. Najłatwiej dostać pożądana wersja symbole do debugowania przez dostęp do dedykowanego serwera symboli firmy Microsoft przy użyciu specjalnej składni dla ścieżki symboli określonej w debugerze. Na przykład następująca ścieżka symboli powoduje, że debuger pobiera symbole z internetowego serwera symboli i przechowuje kopię lokalną w c:\symbols:srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Szczegółowe instrukcje dotyczące korzystania z serwera znaków można znaleźć w pliku pomocy Debugging Tools lub w Internecie pod adresem http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.

Ta seria artykułów powstała z dwóch powodów. Po pierwsze lubię pracować z projektem HackSysExtremePodatny na zagrożenia Kierowca. Po drugie, mam dużo życzeń aby podkreślić ten temat.

Cały kod użyty w pisaniu tej serii znajduje się w moim .

W tej serii artykułów przyjrzymy się pisaniu exploitów na poziomie jądra w systemie Windows. Należy zauważyć, że będziemy mieli do czynienia ze znanymi podatnościami i nie ma potrzeby inżynierii wstecznej (przynajmniej nie w przypadku sterownika).

Zakłada się, że po przeczytaniu wszystkich artykułów poznasz wszystkie najczęstsze klasy naruszeń i metody eksploatacji, a także będziesz w stanie przenieść exploity z architektury x86 na architekturę x64 (jeśli to możliwe) i zapoznać się z nową ochroną metody w Windows 10.

Schemat debugowania jądra

W przeciwieństwie do debugowania na poziomie użytkownika, gdy pojedynczy proces jest zawieszony, cały system jest zaangażowany na poziomie jądra i nie będziemy mogli użyć tej metody. W związku z tym potrzebna jest osobna maszyna do debugowania, która może komunikować się z systemem, w którym debugowane jest jądro, wyświetlać pamięć i struktury jądra, a także wykrywać awarie systemu.

Dodatkowy materiał do nauki:

Wykorzystywanie luk w jądrze

Ten proces jest o wiele przyjemniejszy niż eksploatacja na poziomie użytkownika J.

Głównym celem jest osiągnięcie uprzywilejowanego wykonywania w kontekście jądra. A potem wszystko zależy od naszej wyobraźni, począwszy od uczty z domowym piwem, a skończywszy na wprowadzeniu sponsorowanego przez państwo szkodliwego oprogramowania.
Generalnie naszym zadaniem jest zdobycie powłoki z uprawnieniami systemowymi.

Tematy artykułów z tej serii

Część 1: Tworzenie środowiska pracy

Konfiguracja trzech maszyn wirtualnych i systemu, który będzie pełnił funkcję debugera.
Konfigurowanie debugera WinDBG.

Część 2: Ładunki

Poznaj najpopularniejsze ładunki. Kolejne części będą dotyczyć konkretnych luk w zabezpieczeniach i w razie potrzeby zawierać łącza do tego artykułu.

Reszta części.

Uwzględnienie podatności.

Cykl rozwojowy exploita na poziomie jądra

Znalezienie luki. Ten temat nie zostanie omówiony w tej serii, ponieważ wiemy już dokładnie, gdzie są luki.
Przechwytywanie przepływu egzekucji. Niektóre luki wiążą się z wykonaniem kodu, inne mają dodatkowe wymagania.
Rozszerzenie uprawnień. Głównym celem jest uzyskanie powłoki z uprawnieniami systemowymi.
Przywrócenie przepływu egzekucji. Nieobsłużone wyjątki na poziomie jądra powodują awarię systemu. Jeśli nie zamierzasz pisać exploita do ataku DoS, powinieneś wziąć pod uwagę ten fakt.

Rodzaje systemów docelowych

Będziemy pracować z lukami w następujących systemach (konkretna wersja nie jest krytyczna):

Maszyna wirtualna Win7 x86
Win7 x64 maszyna wirtualna
Win10 x64 VM

Zacznijmy od architektury x86, a następnie przeportujemy exploita na system Win7 x64. Niektóre exploity nie będą działać na maszynach Win10 ze względu na obecność nowych zabezpieczeń. W takim przypadku albo zmienimy logikę exploita, albo zastosujemy zupełnie inne podejście.

Użyte oprogramowanie:

Hypervisor (wiele opcji).
Maszyna wirtualna z systemem Windows 7 x86
Maszyna wirtualna z systemem Windows 7 x64
Maszyna wirtualna z systemem Windows 10 x64

Konfigurowanie systemów do debugowania

Systemy debugowania, z którymi będziemy współpracować, są zaprojektowane do ładowania podatnego sterownika. Na tych komputerach często zdarzają się awarie, ponieważ większość wyjątków w jądrze przyczynia się do tego typu rzeczy. Trzeba przeznaczyć odpowiednią ilość pamięć o dostępie swobodnym dla tych systemów.

Na każdym komputerze, który będzie debugowany, musisz wykonać następujące czynności:

W katalogu VirtualKD uruchom plik target\vminstall.exe. Zostanie dodany nowy wpis rozruchowy, a funkcje debugowania i automatyczne połączenie z serwerem VirtualKD zainstalowanym w systemie działającym jako debugger będą dostępne.

W przypadku maszyny wirtualnej z systemem Windows 10 należy włączyć tryb podpisywania testowego, który umożliwia załadowanie do jądra niepodpisanych sterowników.

Po wykonaniu testu bcdedit /set na polecenie i ponownym uruchomieniu, na pulpicie pojawi się „Tryb testowy”.

Krótki opis Moduł HEVD

Procedura DriverEntry jest procedurą początkową dla każdego kierowcy:

NTSTATUS DriverEntry (W PDRIVER_OBJECT DriverObject, W PUNICODE_STRING RegistryPath) (
UINT32 i = 0;
PDEVICE_OBJECT DeviceObject = NULL;
Stan NTSTATUS = STATUS_UNSUCCESSFUL;
UNICODE_STRING NazwaUrządzenia, NazwaUrządzenia Dos = (0);

UNREFERENCED_PARAMETER (Ścieżka Rejestru);
KOD_STR.();

RtlInitUnicodeString(&NazwaUrządzenia, L"\\Device\\HackSysExtremeVulnerableDriver");
RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\HackSysExtremeVulnerableDriver");

// Utwórz urządzenie
Stan = IoCreateDevice(DriverObject,
0,
&Nazwa urządzenia,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
fałszywy,
Obiekt &urządzenia);

Procedura ta zawiera wywołanie funkcji IoCreateDevice zawierającej nazwę drajwera, którego będziemy używać podczas komunikacji.
Zostanie dodany do obiektu DriverObject pożądane struktury i wskaźniki funkcji.
Liczy się dla nas wskaźnik funkcji związany z procedurą DriverObject->MajorFunction , która odpowiada za obsługę IOCTL (I/O Control; input/out control);
W HEVD ta funkcja nazywa się IrpDeviceIoCtlHandler , co jest dużym wyrażeniem warunkowym z wieloma gałęziami dla każdego IOCTL. Każda luka ma unikalny IOCTL.

Przykład: HACKSYS_EVD_IOCTL_STACK_OVERFLOW to IOCTL używany do wyzwalania podatności na przepełnienie stosu.

To kończy pierwszą część. W następnym artykule porozmawiamy o ładunkach. Na ten moment dostępny jest tylko ładunek do kradzieży tokenów, który zostanie wykorzystany w trzeciej części.

PS Rozumiem, że jest wiele subtelności i problemów, z którymi możesz się spotkać. Ponieważ ten cykl koncentruje się na rozwoju exploitów, będziesz musiał sam rozwiązać wszystkie problemy po drodze. Możesz jednak zadać dowolne pytania w komentarzach.

Autorski:
Barinov S.S., Szewczenko O.G.
Rok:
Źródło:
Informatyka i Technologie komputerowe/ Materiały VI Międzynarodowej Konferencji Naukowo-Technicznej Studentów, Doktorantów i Młodych Naukowców - 23-25 listopada 2010 r., Donieck, DonNTU. - 2010r. - 448 s.

adnotacja

Przyniósł analiza porównawcza Debugowanie trybu użytkownika i trybu jądra w zastosowaniu do systemu operacyjnego Microsoft Windows, podkreślono różnice i problemy związane z organizowaniem debugowania tych ostatnich. Na podstawie uzyskanych wyników sformułowano główne wymagania dotyczące konstrukcji debugerów trybu jądra w przypadku debugowania awaryjnego i interaktywnego. Analizowane istniejące rozwiązania na zgodność z wymaganiami. W szczególności szczególną uwagę przywiązuje się do debugera Microsoft Windows.

Głównym elementem

Debugowanie to proces identyfikowania i eliminowania przyczyn błędów w oprogramowanie. W niektórych projektach debugowanie zajmuje do 50% całkowitego czasu opracowywania. Debugowanie można znacznie uprościć, korzystając ze specjalistycznych narzędzi, które są stale ulepszane. Głównym takim narzędziem jest debugger, który pozwala kontrolować wykonywanie oprogramowania, monitorować jego postęp i ingerować w niego. Narzędzia do debugowania jądra są używane głównie przez programistów sterowników.

Zestaw narzędzi do tworzenia oprogramowania aplikacyjnego oferuje programiście szeroki wachlarz możliwości. Każde zintegrowane środowisko programistyczne obejmuje również możliwość debugowania bez konieczności korzystania z narzędzi innych firm. Jeśli mówimy w szczególności o oprogramowaniu systemowym, a zwłaszcza o rozwoju sterowników, to ze względu na jego specyfikę proces tworzenia jest niezwykle trudny i mało zautomatyzowany. Wszystkie fazy rozwoju, w tym debugowanie, są oddzielne. Każdy z nich wymaga specjalnych warunków: kod programowania jest napisany na pełnoprawnym system komputerowy, debugowanie - w systemie debugowania, testowanie - w zależności od okoliczności itp. Sam debugger trybu jądra jest trudniejszy do nauczenia i w związku z tym mniej przyjazny.

Ogólnie możemy mówić o braku narzędzi do debugowania jądra. Chociaż te narzędzia są dostępne, alternatywy często nie są omawiane. Na przykład debuger systemu Microsoft Windows ma zbyt wysoki próg wejścia. Wielu programistów mówi o pierwszym negatywnym doświadczeniu, kiedy się z nim zapoznaje, a większość jego funkcji pozostaje nieodebrana.

Bazując na strukturze wirtualnej przestrzeni adresowej, jeżeli aplikacja popełni błąd, który spowoduje, że aplikacja zapisze dane w dowolnym miejscu pamięci, to aplikacja uszkodzi tylko własną pamięć i nie wpłynie na działanie innych aplikacji oraz działanie system. Podczas gdy kod trybu jądra może ulec uszkodzeniu ważne struktury dane system operacyjny, co nieuchronnie doprowadzi do ogólnego niepowodzenia. Nieefektywnie napisany sterownik może również spowodować poważną degradację całego systemu operacyjnego.

podstawowe funkcje

debugowanie poziomu kod źródłowy;
zarządzanie realizacją;
przeglądanie i zmiana pamięci;
przeglądanie i zmiana zawartości rejestrów procesora;
widok stosu wywołań.

Aby ułatwić pracę z kodem zdemontowanym, tzw. symbole debugowania. Podczas działania linkera, oprócz obrazu pliku wykonywalnego, można również utworzyć plik danych zawierający informacje, które nie są wymagane przy wykonywaniu programu, ale są niezwykle przydatne przy jego debugowaniu: nazwy funkcji, zmienne globalne oraz opisy struktur. Symbole debugowania są dostępne dla wszystkich pliki wykonywalne sala operacyjna Systemy Windows.

Kontrola wykonania odnosi się do możliwości przerwania i wznowienia wykonania kodu programu po osiągnięciu danej instrukcji w kodzie programu. Jeśli kod programu jest wykonywany w tryb krok po kroku- przerwanie występuje dla każdego tokena języka programowania lub przy wychodzeniu z podprogramu. Przy swobodnym wykonywaniu przerwanie wykonania następuje w określonych z góry sekcjach kodu - miejscach, w których ustawiane są punkty przerwania.

Przerwanie kodu trybu jądra rodzi następujący dylemat. Debuger używa interfejsu użytkownika do interakcji z programistą. Tych. przynajmniej widoczna część debuggera działa w trybie użytkownika i naturalnie używa interfejsu do jego budowy programowanie aplikacji(Windows API), który z kolei opiera się na modułach trybu jądra. Dlatego zawieszenie kodu trybu jądra może doprowadzić do zakleszczenia: system przestanie odpowiadać użytkownikowi.

Części debugera muszą również działać w trybie jądra, aby uzyskać dostęp do pamięci jądra. Prowadzi to jednocześnie do dwóch problemów, które są oczywistą konsekwencją organizacji pamięci w trybie chronionym procesora.

Pierwszy problem dotyczy translacji adresów pamięci wirtualnej. Kierowcy stale wchodzą w interakcję z aplikacjami trybu użytkownika, uzyskując dostęp do swojej pamięci. System operacyjny Windows tłumaczy wirtualne adresy na fizyczne, kierując się koncepcją kontekstu przepływu. Kontekst wątku - struktura, która odzwierciedla stan wątku i zawiera w szczególności zbiór rejestrów oraz kilka innych informacji. Gdy sterowanie jest przekazywane do innego wątku, następuje przełączenie kontekstu, które zapisuje informacje o jednym wątku i przywraca informacje o innym. Przełączenie kontekstu wątku na wątek innego procesu powoduje również przełączenie katalogu strony używanego do tłumaczenia adresów wirtualnych na fizyczne.

Osobliwość polega na tym, że podczas wysyłania wywołania systemowe System operacyjny Windows nie przełącza kontekstu. Dzięki temu kod trybu jądra może używać adresów wirtualnych trybu użytkownika.

Sytuacja jest inna w przypadku przerwania rozsyłania lub wykonywania wątków systemowych. Przerwanie może wystąpić w dowolnym momencie, więc nie ma możliwości przewidzenia, który kontekst wątku zostanie użyty. Z drugiej strony wątki systemowe nie należą do żadnego procesu i nie mogą tłumaczyć adresów wirtualnych trybu użytkownika. Wynika z tego, że w takich sytuacjach nie można uzyskać dostępu do pamięci trybu użytkownika.

Drugi problem to relokowalny dostęp do pamięci. Większość informacji w pamięci można przenosić i można je przenieść z pamięci fizycznej do dysk twardy do pliku strony. Jeśli uzyskuje się dostęp do strony, która nie znajduje się w pamięci fizycznej, procesor normalnie wygeneruje przerwanie błędu strony, które będzie obsługiwane przez menedżera pamięci, w wyniku czego strona zostanie odczytana z pliku strony i załadowana do pamięci fizycznej.

Opisane zachowanie jest zepsute, jeśli kod debuggera zostanie zmuszony do użycia wysoki poziomżądania przerwań (poziomy żądań przerwań, IRQL). Jeśli IRQL jest równy lub większy niż IRQL menedżera pamięci, ten ostatni nie będzie w stanie załadować brakującej strony, ponieważ system operacyjny zablokuje przerwanie błędu strony. Spowoduje to awarię systemu operacyjnego.

Debugowanie zwykle dzieli się na interaktywne i awaryjne. W przypadku interaktywnego debugowania lokalnego debuger działa w tym samym systemie, co obiekt debugowania. W interaktywnym debugowaniu zdalnym debuger i obiekt debugowania działają w różnych systemach. Podczas debugowania kodu jądra system musi być kontrolowany od pierwszych etapów jego rozruchu, gdy sieć jeszcze nie działa, dlatego do łączenia systemów używa się prostych interfejsów szeregowych, takich jak COM, FireWire, USB. Ostatnio, dzięki trendom w rozwoju wirtualizacji oprogramowania na różnych poziomach abstrakcji, coraz częściej przyciągają wirtualne maszyny. System operacyjny gościa działa jako system operacyjny debugowany, system operacyjny hosta zawiera interfejs użytkownika debugera.

Dlatego debugowanie awaryjne nie wymaga zainstalowania narzędzia do debugowania na komputerze testowym. Dystrybucja systemu operacyjnego Windows zawiera mechanizmy do implementacji debugowania awaryjnego. Przed ponownym uruchomieniem system operacyjny może zapisać informacje o swoim stanie, które programista może przeanalizować i znaleźć przyczynę. Ta informacja zapisana w pliku nazywana jest zrzutem pamięci.

Główne narzędzia do debugowania trybu jądra są dostarczane przez producenta systemu operacyjnego Windows w ramach darmowego pakietu Debugging Tools for Windows. Narzędzia obejmują debugery graficzne i konsolowe, odpowiednio WinDbg i KD (zwane dalej debugerem Windows). Praca tych debuggerów opiera się na mechanizmach dostarczonych przez twórców systemu operacyjnego i osadzonych w jego jądrze.

Głównym trybem debugera systemu Windows jest tryb interpretera poleceń. Dzięki modułowa konstrukcja wraz z dostarczonymi programistami Polecenia systemu Windows Debuger obsługuje moduły innych firm zwane rozszerzeniami. W rzeczywistości większość wbudowanych poleceń jest również sformatowana jako rozszerzenia.

Windows Debugger koncentruje się na zdalnym debugowaniu interaktywnym i awaryjnym, za pomocą którego ujawniane są wszystkie jego możliwości. Jednocześnie pełnoprawne lokalne interaktywne debugowanie nie jest obsługiwane: debuger umożliwia tylko przeglądanie niektórych struktur jądra.

Istnieje rozszerzenie dla Windows Debugger o nazwie LiveKD, stworzone przez Marka Russinovicha, które w pewnym sensie implementuje lokalne interaktywne debugowanie. LiveKD tworzy zrzut pamięci w podróży działający system i używaj go do debugowania.

Debugging Tools for Windows jest regularnie aktualizowany i obsługuje wszystkie nowoczesne systemy operacyjne Windows.

Debuger jądra SoftICE, wydany przez Compuware w pakiecie oprogramowania DriverStudio, tradycyjnie działał jako alternatywa dla pakietu Debugging Tools for Windows. Charakterystyczną cechą SoftICE była implementacja lokalnego interaktywnego debugowania na obsługiwanym sprzęt komputerowy. Debuger mógł prawie całkowicie kontrolować działanie systemu operacyjnego.

Od 3 kwietnia 2006 r. rodzina produktów DriverStudio została wycofana z „wielu problemów technicznych i biznesowych, a także ogólnych warunków rynkowych”. Ostatnia wersja Obsługiwanym systemem operacyjnym jest Windows XP z dodatkiem Service Pack 2. Dodatki Service Pack zazwyczaj nie zmieniają interfejsu aplikacji systemu operacyjnego, ale numery wywołań systemowych i inne nieudokumentowane informacje mogą ulec zmianie. Debuger SoftICE polegał na zakodowanych na sztywno adresach struktury wewnętrzne dane. W rezultacie wraz z wydaniem dodatku Service Pack 3 kompatybilność została złamana. Oczywiście późniejsze wersje systemu operacyjnego Windows również nie są obsługiwane.

Syser Kernel Debugger został stworzony przez małą chińską firmę Sysersoft jako zamiennik debuggera SoftICE. Pierwsza ostateczna wersja została wydana w 2007 roku. Podobnie jak SoftICE, Syser Kernel Debugger jest zdolny do interaktywnego debugowania w działającym systemie. Tylko 32-bitowe edycje modern Wersje Windows.

Windows Debugger jest obecnie głównym narzędziem wśród twórców modułów jądra. Jest również używany przez zespół programistów jądra systemu operacyjnego Windows.

ChPF OELPFPTSCHE HLBBOYS RP TBVPFE U PFMBDLPK SDTB U BCHBTYKOSHCHNY DBNRBNY RBNSFY. LBL RTBCHYMP, CHBN OKHTSOP VKHDEF ЪBDBFSH PDOP YЪ HUFTPKUFCH RPDLBYULY, RETEYUYUMEOOSCHI CH ZHBKME /etc/fstab. uVTPU PVTBACH RBNSFY O KHUFTPKUFCHB, OE SCHMSAEYEUS KHUFTPKUFCHBNY RPDLBYULY, OBRTYNET, MEOFSHCH, CH DBOOSCHK NPNEOF OE RPDDETSYCHBAFUS.

Notatka: YURPMSH (KhKFE LPNBODH) śmietniki (8) DMS HLBBOYS SDTH NEUFB, ZDE OHTSOP UPITBOSFSH BCHBTYKOSHCHE DBNRSHCH. rPUME OBUFTPCLY RP LPNBODE zamiana (8) TBDEMB RPDLBYuLY DPMTSOB VSHCHFSH CHSHCHCHBOB RTPZTBNNB zrzut . PVSHYUOP LFP CHSHCHRPMOSEPHUS BDBOYEN RETENEOOPK dumpdev H JBKME rc.conf (5). eUMY BDBOB LFB RETENEOOBS, FP RPUME UVPS RTY RETCHPK NOPZPRPMSHЪPCHBFEMSHULPK RETEEBZTHЪLE VHDEF BCHFPNBFYUEULY BRHEEO RTPZTBNNB zapiszcore(8). poB UPITBOYF BCHBTYKOSHK DBNR SDTB W LBFBMPZ, JBDBOOSCHK H RETENEOOPC dumpdir JBKMB rc.conf . rp HNPMYUBOYA LBFBMPZPN DMS BCHBTYKOSHCHI DBNRPC SCHMSEFUS /var/crash .

MYVP CH NPCEFE ЪBDBFSH HUFTPKUFCHP DMS UVTPUB PVTBYB RBNSFY SCHOP Yuete RBTBNEFT zrzut CH UFTPL config LPOZHJZHTBGYPOOPZP ZHBKMB CHBYEZP SDTB. fBLPK URPUPV YURPMSHЪPCHBFSH OE TELPNEODHEFUS Y PO DPMTSEO YURPMSHЪPCHBFSHUS, FPMSHLP EUMY CH IPFYFE RPMHYUBFSH BCHBTYKOSHCHE PVTBJSCH RBNSFY SDTB, LPFPTPE BCHBTYBEFUCHCHCHETY

Notatka: dBMEE FETNYO gdb POBUBEF PFMBDUYL gdb , BRHEEOOSCHK H ``TETSYNE PFMBDLY SDTB "". RETEIPD CH FFPF TETSIN DPUFYZBEFUS BRHULPN gdb U RBTBNEFTPN -k . h TETSYNE PFMBDLY SDTB gdb YЪNEOSEF UCHPЈ RTYZMBYOEOYE O (kgdb) .

Wskazówka: eUMMY CHSH YURPMSHHEFE FreeBSD CHETUYY 3 YMY VPMEE TBOOAA, CHSH DPMTSOSCH CHSHCHRPMOYFSH HUEYUEOYE PFMBDPYUOPZP SDTB LPNBODPK pasek, B OE HUFBOBCHMYCHBFSH VPMSHYPE PFMBDPYUOPE SD:
# cp kernel.debug # strip -g kernel
ffpf ybz oe fbl hts y eepvipdyn, op telpneodhen. (PE FreeBSD 4 J VPMEE RPDOYI TEMYBI FPF YBZ CHSCHRPMOSEFUS BCHFPNBFYYUEULY H LPOGE RTPGEUUB RPUFTPEOYS SDTB marka).

ъBNEFSHFE, UFP CH UVBTSCHI CHETUYSI FreeBSD (DP 3.1, OE CHLMOYUBS FFPF TEMY), YURPMSH'HEFUS SDTB CH ZHPTNBFE a.out, RPFPPNH YI FBVMYGSCH UYNCHPMCH DPMTSOSH TBURPMBZBFSHOPUS RBNSFP w VPMSHYPK FBVMYGEK UYNCHPMCH CHOE HUEYUEOOOPN PFMBDPYUOPN SDTE LFP YЪMYYOSS FTBFB. rPUMEDOYE TEMYJSHCH FreeBSD YURPMSHJHAF SDTB CH JPTNBFE ELF, TUTAJ EFP OE SCHMSEFUS RTPVMENPK.

eUMY BL FEUFYTHEFE OPCHPE RAS ULBTSEN, OBVYTBS YNS OPCHPZP SDTB RTYZMBYEOYY BZTHYUYLB W OP CHBN OHTSOP BZTHTSBFSH J TBVPFBFSH mają DTHZYN SDTPN, YUFPVSCH UOPCHB CHETOHFSHUS A OPTNBMSHOPNH ZHHOLGYPOYTPCHBOYA, BZTHTSBKFE EZP FPMSHLP B PDOPRPMSHPCHBFEMSHULPN TETSYNE RTY RPNPEY ZHMBZB -S HLBSCHCHBENPZP rty BZTHLE, B UBFEN CHSHCHRPMOYFE FBLIE YBZY:

# fsck -p # mount -a -t ufs # więc twój system plików dla /var/crash jest zapisywalny # savecore -N /kernel.panicked /var/crash # wyjdź # ...do wielu użytkowników

uFB RPUMEDPCHBFEMSHOPUFSH HLBSCHCHBEF RTPZTBNNE zapiszcore(8) O YURPMSH'PCHBOYE DTHZPZP SDTB DMS Y'CHMEYUEOYS UICHPMYUEULYI YNEO. yOBYUE POB VHDEF YURPMSHЪPCHBFSH SDTP, TBVPFBAEEEE CH DBOOSCHK NPNEOF Y, ULPTEE CHUEZP, OYUEZP OE UDEMBEF, RPFPNH UFP BCHBTYKOSHCHK PVTB RBNSFY Y Uinchpmshch MYTB VHD.

b FERETSH, RPUME UVTPUB BCHBTYKOPZP DBNRB, RETEKDYFE H LBFBMPZ /sys/compile/WHATEVER Y BRHUFYFE LPNBODH gdb -k . y RTPZTBNNSC gdb UDEMBKFE CHPF UFP:

Plik symbolu kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 DTHZPK RTPZTBNNPK.

ChPF TsHTOBM LPNBOD UEBOUB TBVPFShch gdb, YMMAUFTYTHAEYK LFH RTPGEDHTX. dMYOOSH UFTPLY VSCHMY TBPTCHBOSH DMS HMHYUYOYS YUYFBVEMSHOPUFY Y DMS HDPVUFCHB UFTPLY VSCHMY RTPOHNETPCHBOSHCH. CHUE PUFBMSHOPE SCHMSEFUS FTBUUYTPCHLPK PYYVLY, TEBMSHOP CHPOYLOKHCHYEK CHP CHTHENS TBVPFSCH OBD DTBCCHETPN LPOUPMY pcvt.

1:Skrypt wystartował w piątek 30 grudnia 23:15:22 1994 2: # cd /sys/compile/URIAH 3: # gdb -k kernel /var/crash/vmcore.1 4: Odczytywanie danych symboli z /usr/src/ sys/kompilacja/URIAH/jądro ... gotowe. 5:IdlePTD 1f3000 6:panika: ponieważ kazałeś! 7:bieżąca płytka drukowana w 1e3f70 8:Wczytywanie symboli dla ../../i386/i386/machdep.c... gotowe. 9: (kgdb) gdzie 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c linia 767) 11:#1 0xf0115159 w panice () 12:#2 0xf01955bd w diediedie ( ) (../../i386/i386/machdep.c linia 698) 13:#3 0xf010185e w db_fncall () 14:#4 0xf0101586 w db_command (-266509132, -266509516, -267381073) 15:#0 0x10101 db_command_loop () 16:#6 0xf01040a0 w db_trap () 17:#7 0xf0192976 w kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb w trap_fatal (...) 19:#9 0xfault19 ...) 20:#10 0xf019cb2f w pułapce (...) 21:#11 0xf01932a1 w wyjątek: calltrap () 22:#12 0xf0191503 w cnopen (...) 23:#13 0xf0132c34 w spec_open () 24: #14 0xf012d014 w vn_open () 25:#15 0xf012a183 w open () 26:#16 0xf019d4eb w syscall (...) 27: (kgdb) up 10 28:Czytanie w symbolach dla ../../i386/i386 /trap.c ...Gotowe. 29:#10 0xf019cb2f w pułapce (frame=(tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ -96 eb_ = -27 31:2630 266427884, TF_Edx = 12, TF_ECX = -266427884, TF \ 32: _EAX = 64772224, TF_TRAPNO = 12, TF_ERR = -272695296, TF_EIP = -26 \ 33: 6672343, TF_CS = -26666,ESLA9368, TF_ = 3072, tf_\ 34:ss = -266427884)) (../../i386/i386/trap.c linia 283) 35:283 (nieważne) trap_pfault(&ramka, FAŁSZ); 36: (kgdb) frame frame->tf_ebp frame->tf_eip 37:Wczytywanie symboli dla ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 w pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c linia 403) 40:403 return ((*linesw.l_open)(dev, tp)); 41: (kgdb) lista 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= KLOKALNIE; /* nie może być modemem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw.l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw.l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 ) 52: (kgdb) print tp 53:Wczytywanie symboli dla ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55: (kgdb) print tp->t_line 56:$2 = 1767990816 57: (kgdb) up 58:#1 0xf0191503 w cnopen (dev=0x00000000, flag=3, mode=8192 , p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c linia 126) 60: return ((*cdevsw.d_open)(dev, flag, mode, p) ); 61: (kgdb) w górę 62:#2 0xf0132c34 w spec_open () 63: (kgdb) w górę 64:#3 0xf012d014 w vn_open () 65: (kgdb) w górę 66:#4 0xf012a183 w trybie otwartym () 67: (kgdb) up 68:#5 0xf019d4eb w syscall(frame=(tf_es=39, tf_ds=39, tf_edi=\69:2158592, tf_esi=0, tf_ebp=-272638436, tf_isp=-272629788, tf\ = 70:_ebx, , tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72 := -272638456, tf) (. ./../i386/i386/trap.c linia 673) 73:673 błąd = (*callp->sy_call)(p, args, rval); 74: (kgdb) up 75: Wybrano ramkę początkową; nie możesz iść w górę. 76: (kgdb) quit 77: # exit 78:exit 79:80:Skrypt wykonany w piątek 30 grudnia 23:18:04 1994

lPNNEOFBTYY L CHSHCHYERTYCHEDEOOOPNKH TsHTOBMH:

UFPLB 6:

yFP DBNR, CHJSFC RTY RPNPEY DDB (UNPFTY OYCE), RPFPNH LPNNEOFBTYK L BCHBTYKOPNH PUFBOPCH YNEEF YNEOOP CHYD ``bo tak powiedziałeś! PDOBLP YOBYUBMSHOPK RTYUYOPK RETEIPDB CH DDB VSCHMB BCHBTYKOBS PUFBOPCHLB RTY CHPOYOLOPCHEOYA PYYVLY UFTBOIGSC RBNSFY.

UFPLB 20:

ffp NEUFPOBIPTSDEOYE JHOLGYY trap() H FTBUUYTPCHLE UFEBL.

UFPLB 36:

rTYOHDYFEMSHOPE YURPMSH'PCHBOYE OPCHPK ZTBOYGSCH UFEBL; FERESH FF OE OHTSOP. RTEDRPMBZBEFUUS, UFP ZTBOYGSC UFELB HLBSCCHCHBAF O RTBCHIMSHOPE TBURPMPTSEOYE, DBTSE CH UMHYUBE BCHBTYKOPZP PUFBOPCHB. zMSDS O UFTPLH YUIPDOPZP LPDB 403, NPTsOP ULBBFSH, UFP CHEUSHNB CHETPSFOP, UFP MYVP CHYOPCHBF DPUFHR RP HLBBFEMA ``tp ”, MYVP VSCHM CHSHHIPD IB ZTBOYGSCH NBUUYCHB.

UFPLB 52:

RPIPTSE, UFP CHYOPCHBF HLBBFEMSH, OP PRZEZ SCHMSEFUSA DPRHUFAYNSCHN BDTEUPN.

UFPLB 56:

pDOBLP, PYUECHIDOP, UFP ON HLBSCCHCHBEF O NHUPT, FBL UFP NSC OBYMY OGÓLNE PYYVLH! (DMS FEI, LFP OE OBBLPN U YFPK YUBUFSHHA LPDB: tp->t_line UMKhTSYF DMS ITBOOEOYS TETSYNB LBOBMB LPOUPMSHOPZP HUFTPKUFCHB, Y LFP DPMTSOP VShFSH DPUFBFPYYuP GEMNBMEOSH)