Aby debugować jądro, musisz połączyć się z komputerem za pomocą kabla null-modem lub połączenia modemowego. Komputer debugujący otrzyma nazwę „Host”, a komputer powodujący problemy - „Docelowy”.
Na obu komputerach musi działać ta sama wersja systemu Windows, a pliki symboli komputera docelowego muszą być zainstalowane na komputerze-hoście. Pliki symboli znajdują się na płycie instalacyjnej Windows w katalogu Support \\ Debug.
Aby włączyć debugowanie, należy zmodyfikować plik BOOT.INI na komputerze docelowym.
1. Zmień atrybuty pliku BOOT.INI:
atrybuty c: \\ boot.ini - r - s
2. Edytuj ten plik i dodaj parametr / debug do wiersza startowego systemu Windows (w celu poinformowania systemu o załadowaniu debugera jądra do pamięci RAM podczas uruchamiania systemu Windows). Dodatkowe parametry to / Debugport, który informuje system, którego portu COM użyć (domyślnie COM2) i / Baudrate - do określenia szybkości transmisji (domyślnie prędkość transmisji to 19200, ale 9600 jest lepsza). Na przykład:
dysk multi (0) (0) rdisk (0) partycja (0) \\ WINDOWS \u003d "Windows NT" / debug / debugport \u003d com2 / baudrate \u003d 9600
3. Zapisz plik.
4. Ustaw poprzednie atrybuty pliku BOOT.INI:
atrybuty c: \\ boot.ini + r + s
W tym przykładzie Target zezwolił na połączenie 9600 bps na porcie COM2.
Komputer hosta musi mieć skonfigurowane parametry wymagane 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: \\ symbols
Instalacja może zająć trochę czasu. Pamiętaj, że jeśli dodatki Service Pack zostały zainstalowane na komputerze docelowym, pliki symboli dla tych pakietów muszą być również zainstalowane na komputerze-hoście. Pliki symboli dla dodatków Service Pack można pobrać z witryny internetowej firmy Microsoft.
Następnym etapem jest skonfigurowanie zmiennych środowiskowych niezbędnych do debugowania, na przykład zmiennych wskazujących lokalizację plików symboli itp. Poniżej znajduje się opis tych zmiennych.
Opis zmiennych systemowych
Definicję tych zmiennych można umieścić w pliku wsadowym, aby uniknąć wprowadzania odpowiednich poleceń przy każdym uruchomieniu:
echo wyłączone
set _nt_debug_port \u003d com2
set _nt_debug_baud_rate \u003d 9600
set _nt_symbol_path \u003d d: \\ symbols \\ i386
set _nt_log_file_open \u003d d: \\ debug \\ logs \\ debug.log
Teraz musisz skopiować oprogramowanie do debugowania jądra, które znajduje się w katalogu support \\ debug \\<процессор> na instalacyjnym dysku CD (support \\ debug \\ I386). Najłatwiej jest skopiować cały katalog, ponieważ jest mały (około 2,5 MB). W przypadku platformy I386 używany jest debugger, który jest dostarczany jako plik I386KD.EXE. Debugger jest uruchamiany za pomocą komendy I386KD. Aby wprowadzić polecenie, naciśnij kombinację klawiszy
Debugery trybu jądra znajdują się między procesorem a systemem operacyjnym. Oznacza to, że po zatrzymaniu debuggera w trybie jądra system operacyjny również zatrzymuje się całkowicie. Nietrudno zdać sobie sprawę, że nagłe zatrzymanie systemu operacyjnego jest przydatne podczas pracy z problemami z zegarem i synchronizacją. Jednak z wyjątkiem jednego debuggera, który zostanie omówiony poniżej (w sekcji SoftlCE Debugger tego rozdziału), nie można debugować kodu trybu użytkownika za pomocą debuggerów w trybie jądra.
Nie ma wielu debuggerów w trybie jądra. Niektóre z nich to: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG i SoftlCE. Każdy z tych debugerów został krótko opisany w poniższych sekcjach.
Debugger WDEB386
WDEB386 to debugger trybu jądra systemu Windows 98, który jest dystrybuowany z zestawem Platform SDK. Ten debugger jest przydatny tylko dla programistów piszących sterowniki urządzeń wirtualnych Windows 98 (VxD). Podobnie jak większość debuggerów trybu jądra dla systemów operacyjnych Windows, debugger WDEB386 wymaga do działania dwóch komputerów i kabla modemu zerowego. Te dwie maszyny są potrzebne, ponieważ część debugera, która działa na maszynie docelowej, ma ograniczony dostęp do swojego sprzętu, więc wysyła swoje dane wyjściowe i odbiera polecenia z drugiej maszyny.
Debugger WDEB386 ma ciekawą historię. Zaczęło się jako wewnętrzne narzędzie Microsoft działające w tle w erze Windows 3.0. Był trudny w użyciu i brakowało mu wystarczającej obsługi debugowania kodu źródłowego i innych fajnych funkcji, którymi zrujnowały nas debugery Visual C ++ i Visual Basic.
Polecenia kropkowe są najważniejszą cechą WDEB386. Poprzez przerwanie INT 41 można rozszerzyć WDEB386, aby dodać polecenia. Ta rozszerzalność umożliwia autorom sterowników VxD tworzenie niestandardowych poleceń debugowania, które zapewniają im swobodny dostęp do informacji na ich urządzeniach wirtualnych. Wersja systemu Windows 98 do debugowania obsługuje wiele poleceń DOT, które umożliwiają obserwację dokładnego stanu systemu operacyjnego w dowolnym momencie procesu debugowania.
Debugger I386KD
Windows 2000 różni się od Windows 98 tym, że faktyczna część debuggera trybu jądra jest częścią NTOSKRNL. EXE - główny plik jądra systemu operacyjnego Windows 2000. Ten debugger jest dostępny zarówno w wersji bezpłatnej (wydanie), jak i zweryfikowanej (debugowanie) systemu operacyjnego. Aby włączyć debugowanie w trybie jądra, ustaw parametr programu ładującego / DEBUG na BOOT. INI i opcjonalnie opcję bootloadera / DEBUGPORT, jeśli chcesz ustawić port komunikacyjny debugera jądra na inny niż domyślny (COM1). I386KD działa na własnej maszynie i komunikuje się z maszyną z Windows 2000 poprzez kabel modemu zerowego.
Debuger trybu jądra NTOSKRNL. EXE wystarcza tylko do kontrolowania procesora, aby można było debugować system operacyjny. Większość prac związanych z debugowaniem - obsługa symboli, rozszerzone punkty przerwania i dezasemblacja - jest wykonywana po stronie 1386KD. W pewnym momencie zestaw sterowników urządzeń systemu Windows NT 4 (DDK) dokumentował protokół używany w kablach bezmodemowych. Jednak Microsoft już tego nie dokumentuje.
Potęga 1386KD jest oczywista, gdy spojrzy się na wszystkie polecenia, które oferuje, aby uzyskać dostęp do wewnętrznego stanu systemu Windows 2000. Wiedza o działaniu sterowników urządzeń w systemie Windows 2000 może pomóc programiście w śledzeniu wyników wielu poleceń. Mimo całej swojej mocy i386KD prawie nigdy nie jest używany, ponieważ jest to aplikacja konsolowa, której używanie do debugowania na poziomie źródła jest bardzo żmudne.
- Autorski:
Barinov S.S., Shevchenko 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 \u200b\u200blistopada 2010, Donieck, DonNTU. - 2010. - 448 pkt.
adnotacja
Podano analizę porównawczą debugowania trybu użytkownika i trybu jądra w odniesieniu do systemu operacyjnego Microsoft Windows, podkreślono różnice i problemy z organizacją debugowania tego ostatniego. Na podstawie uzyskanych wyników sformułowano podstawowe wymagania dotyczące budowy debuggerów w trybie jądra w przypadku debugowania awaryjnego i interaktywnego. Analiza istniejących rozwiązań pod kątem zgodności z wymaganiami. W szczególności szczególną uwagę zwraca się na debuger Microsoft Windows.
Głównym elementem
Debugowanie to proces identyfikowania i naprawiania głównej przyczyny błędów oprogramowania. W niektórych projektach debugowanie zajmuje do 50% całkowitego czasu programowania. 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ć wykonanie oprogramowania, monitorować jego postęp i interweniować w nim. Narzędzia do debugowania jądra są używane głównie przez programistów sterowników.
Zestaw narzędzi do tworzenia aplikacji oferuje programiście szerokie możliwości. Każde zintegrowane środowisko programistyczne obejmuje również możliwość debugowania bez użycia narzędzi innych firm. Jeśli mówimy w szczególności o rozwoju oprogramowania systemowego i sterowników, to ze względu na swoją specyfikę proces rozwoju jest niezwykle trudny i mało zautomatyzowany. Wszystkie fazy rozwoju, w tym debugowanie, są oddzielne. Do wykonania każdego z nich wymagane są specjalne warunki: pisanie kodu programu odbywa się na pełnoprawnym systemie komputerowym, debugowanie - w systemie debugującym, testowanie - w zależności od okoliczności itp. Sam debugger trybu jądra jest trudniejszy do nauczenia, a zatem mniej przyjazny dla użytkownika.
Ogólnie możemy mówić o braku narzędzi do debugowania jądra. Chociaż takie narzędzia są dostępne, często nie ma potrzeby rozmawiania o alternatywach. Na przykład debuger Microsoft Windows ma zbyt wysoki próg wejścia. Wielu programistów podczas spotkania z nim mówi o pierwszym negatywnym doświadczeniu, a większość jego możliwości pozostaje niezamówiona.
Bazując na strukturze wirtualnej przestrzeni adresowej, jeśli w aplikacji wystąpi błąd, w wyniku którego aplikacja zapisze dane do dowolnego miejsca w pamięci, to aplikacja uszkodzi tylko swoją pamięć i nie wpłynie na działanie innych aplikacji i systemu operacyjnego. Natomiast kod trybu jądra może uszkodzić ważne struktury danych systemu operacyjnego, co nieuchronnie doprowadzi do ogólnej awarii. Nieefektywnie napisany sterownik może również spowodować poważne uszkodzenie całego systemu operacyjnego.
- Nowoczesne debuggery zapewniają następujące podstawowe funkcje:
- debugowanie na poziomie kodu źródłowego;
- kontrola wykonania;
- przeglądanie i zmiana pamięci;
- przeglądanie i zmiana zawartości rejestrów procesora;
- wyświetlić stos wywołań.
Aby ułatwić pracę z zdemontowanym kodem, tzw. symbole debugowania. Podczas działania konsolidatora, oprócz obrazu pliku wykonywalnego, można również utworzyć plik danych, który zawiera informacje, które nie są wymagane podczas wykonywania programu, ale są niezwykle przydatne do debugowania: nazwy funkcji, zmienne globalne, opis struktur. Symbole debugowania są dostępne dla wszystkich plików wykonywalnych systemu operacyjnego Windows.
Kontrola wykonania odnosi się do możliwości przerwania i wznowienia wykonywania kodu programu po osiągnięciu danej instrukcji w kodzie programu. Jeśli kod programu jest wykonywany w trybie krok po kroku, dla każdego leksemu języka programowania lub przy wychodzeniu z podprogramu występuje przerwanie. Przy swobodnym wykonaniu przerwanie występuje we wcześniej określonych sekcjach kodu - miejscach, w których ustawiane są punkty przerwania.
Przerwanie kodu trybu jądra przedstawia następujący dylemat. Debugger używa interfejsu użytkownika do interakcji z programistą. Te. przynajmniej widoczna część debuggera działa w trybie użytkownika i naturalnie używa interfejsu programowania aplikacji (Windows API) do jego zbudowania, który z kolei opiera się na modułach trybu jądra. Dlatego zawieszenie kodu trybu jądra może doprowadzić do zakleszczenia: system przestaje odpowiadać na żądania użytkowników.
Aby uzyskać dostęp do pamięci jądra, części debuggera muszą również działać w trybie jądra. Prowadzi to do dwóch problemów naraz, które są oczywistą konsekwencją organizacji pamięci w trybie chronionym procesora.
Pierwszy problem dotyczy tłumaczenia adresów pamięci wirtualnej. Sterowniki stale współpracują z aplikacjami trybu użytkownika, uzyskując dostęp do ich pamięci. System operacyjny Windows tłumaczy adresy wirtualne na adresy fizyczne, kierując się koncepcją kontekstu wątku. Kontekst strumienia to struktura, która odzwierciedla stan strumienia i zawiera w szczególności zestaw rejestrów i inne informacje. Kiedy kontrola jest przenoszona do innego wątku, następuje przełączenie kontekstu, w którym przechowywane są informacje o jednym wątku, a informacje o innym są odtwarzane. Kiedy kontekst wątku przełącza się na wątek z innego procesu, katalog strony używany do tłumaczenia adresów wirtualnych na adresy fizyczne jest również przełączany.
Osobliwością jest to, że podczas wysyłania wywołań systemowych system operacyjny Windows nie zmienia kontekstu. Dzięki temu kod trybu jądra może używać wirtualnych adresów trybu użytkownika.
Sytuacja wygląda inaczej podczas wysyłania przerwań lub wykonywania wątków systemowych. Przerwa może wystąpić w dowolnym momencie, więc nie można przewidzieć, który kontekst wątku zostanie użyty. Wątki systemowe nie należą do żadnego procesu i nie mogą tłumaczyć wirtualnych adresów trybu użytkownika. Wynika z tego, że w takich sytuacjach nie jest możliwy dostęp do pamięci trybu użytkownika.
Drugim problemem jest relokowalny dostęp do pamięci. Większość informacji w pamięci można przenieść i przenieść z pamięci fizycznej na dysk twardy do pliku stronicowania w dowolnym momencie. Jeśli uzyskasz dostęp do strony, która nie znajduje się w pamięci fizycznej, procesor zwykle generuje 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.
To zachowanie jest zepsute, jeśli kod debugera jest zmuszony do używania wysokich poziomów żądania przerwań (IRQL). Jeśli IRQL pasuje lub przekracza 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 interaktywnym debugowaniu lokalnym 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ć monitorowany od pierwszych etapów jego rozruchu, kiedy sieć jeszcze nie funkcjonuje, dlatego do komunikacji systemów wykorzystywane są proste interfejsy szeregowe takie jak COM, FireWire, USB. Ostatnio, ze względu na trendy rozwoju wirtualizacji oprogramowania na różnych poziomach abstrakcji, coraz większe zainteresowanie przyciąga maszyny wirtualne. System gościa działa jako system operacyjny debugera, a hostowany system operacyjny zawiera interfejs użytkownika debugera.
W związku z tym debugowanie awaryjne nie wymaga zainstalowania narzędzia debugującego na maszynie testowej. Dystrybucja systemu operacyjnego Windows zawiera mechanizmy implementacji awaryjnego debugowania. Przed ponownym uruchomieniem system operacyjny może zapisać informacje o swoim stanie, które programista może przeanalizować i znaleźć przyczynę. Te informacje zapisane w pliku nazywamy zrzutem pamięci.
Podstawowe narzędzia do debugowania w trybie jądra są dostarczane przez producenta systemu operacyjnego Windows jako część bezpłatnego pakietu narzędzi do debugowania dla systemu Windows. Narzędzia te obejmują odpowiednio graficzne debugery WinDbg i KD oraz debuggery konsoli (dalej zwane Debuggerem 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ń. Ze względu na swoją modularną strukturę, wraz z poleceniami dostarczonymi przez programistów, Windows Debugger obsługuje moduły innych firm zwane rozszerzeniami. W rzeczywistości większość wbudowanych poleceń jest również dostarczanych jako rozszerzenia.
Windows Debugger koncentruje się na zdalnym, interaktywnym i awaryjnym debugowaniu, gdy jest używany, ujawniane są wszystkie jego możliwości. Jednocześnie pełnoprawne lokalne interaktywne debugowanie nie jest obsługiwane: debugger pozwala tylko na przeglądanie niektórych struktur jądra.
Istnieje wtyczka Windows Debugger o nazwie LiveKD, stworzona przez Marka Russinovicha, która w pewnym sensie implementuje lokalne interaktywne debugowanie. LiveKD tworzy w locie zrzut pamięci systemu produkcyjnego i używa go do debugowania.
Narzędzia do debugowania dla systemu Windows są regularnie aktualizowane, aby obsługiwały wszystkie nowoczesne systemy operacyjne Windows.
Debugger jądra Compuware SoftICE w pakiecie oprogramowania DriverStudio był tradycyjnie alternatywą dla pakietu Debugging Tools for Windows. Charakterystyczną cechą SoftICE była implementacja lokalnego interaktywnego debugowania na obsługiwanym sprzęcie. Debugger miał prawie pełną kontrolę nad działaniem systemu operacyjnego.
Z dniem 3 kwietnia 2006 r. Sprzedaż produktów z rodziny DriverStudio została wstrzymana z powodu „wielu problemów technicznych i biznesowych, a także ogólnych warunków rynkowych”. Najnowszą wersją obsługiwanego systemu operacyjnego jest Windows XP z dodatkiem Service Pack 2. Zazwyczaj dodatki Service Pack nie zmieniają interfejsu API systemu operacyjnego, ale mogą ulec zmianie numery wywołań systemowych i inne nieudokumentowane informacje. Debugger SoftICE polegał na zakodowanych na stałe adresach wewnętrznych struktur danych. W rezultacie kompatybilność została zerwana z wydaniem dodatku Service Pack 3. Oczywiście nowsze 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. Obsługiwane są tylko nowoczesne 32-bitowe wersje systemu Windows.
Debugger systemu Windows jest obecnie głównym narzędziem wśród twórców modułów jądra. Jest również używany przez zespół jądra systemu Windows.
Jak uruchomić debugera jądra?
Odpowiedź Mistrza:
Jest jeden bardzo ważny element procesu tworzenia oprogramowania - debugowanie. W odniesieniu do programów użytkowych odbywa się to za pomocą środków, które działają w trybie użytkownika i często są wbudowane w IDE. Aby móc na przykład debugować sterowniki, musisz uruchomić debuger jądra.
Musisz uruchomić procesor poleceń cmd. Otwórz menu Start na pasku zadań. W wyświetlonym oknie kliknij element „Uruchom ...”. Pojawi się okno Uruchom program. Wpisz cmd w polu tekstowym, a następnie kliknij OK.
Teraz wykonaj kopię zapasową pliku boot.ini. Najpierw znajdź ścieżkę instalacji aktualnej kopii systemu Windows za pomocą polecenia: echo% SystemRoot%
Następnie przejdź na dysk z zainstalowanym systemem operacyjnym, wpisując litery urządzeń, a po nich dwukropek. Używając polecenia cd, przejdź do katalogu głównego. Teraz użyj polecenia attribute, aby usunąć atrybuty ukryte, tylko do odczytu i systemowe z pliku boot.ini. Użyj polecenia kopiowania, aby utworzyć kopię zapasową, a następnie ustaw atrybuty w miejscu.
Aby wyświetlić aktualną listę opcji rozruchu, użyj polecenia bootcfg / query. Przejrzyj listę i zidentyfikuj element, z którego chcesz zbudować nowe ustawienia jądra, które można debugować. Zapamiętaj identyfikator rekordu rozruchowego.
Użyj polecenia bootcfg / copy, aby utworzyć rekord rozruchowy. Użyj parametru / id, aby określić identyfikator wpisu, który ma zostać skopiowany. Za pomocą parametru / d określ nazwę wpisu, który ma zostać wyświetlony. Teraz musisz wrócić do listy opcji rozruchu za pomocą polecenia bootcfg / query i spojrzeć na identyfikator dodanego wpisu.
Teraz musisz uwzględnić opcje uruchamiania debugera jądra we wcześniej utworzonym rekordzie rozruchowym. Jeśli będziesz debugować na maszynie docelowej, wystarczy dodać opcję / debug.
Jeśli chcesz przeprowadzić zdalne debugowanie z komputerem docelowym podłączonym przez port COM do komputera hosta, użyj opcji / port i / baud, aby określić numer portu i szybkość transmisji.
Jeśli zamierzasz przeprowadzić zdalne debugowanie za pomocą kabla FireWire (interfejs IEEE 1394), to aby włączyć odpowiedni tryb użyj opcji / dbg1394 i podaj numer kanału opcję / ch.
Aby sprawdzić, czy zmiany zostały wprowadzone, przetestuj pliki rozruchowe za pomocą polecenia bootcfg z parametrem / query. Zamknij okno powłoki po wydaniu polecenia wyjścia.
W razie potrzeby zmień parametry rozruchu systemu operacyjnego. Otwórz panel sterowania poprzez menu „Start” i już w nim otwórz element „System”. W otwartym oknie „Właściwości systemu” wybierz kartę „Zaawansowane”. Na tej karcie wybierz sekcję zatytułowaną „Uruchamianie i odzyskiwanie” i kliknij w niej przycisk „Opcje”. W wyświetlonym oknie „Uruchamianie i odzyskiwanie” aktywuj opcję „Wyświetl listę systemów operacyjnych”. Zamknij oba okna dialogowe przyciskiem „OK”.
Zrestartuj swój komputer. Wybierz rozruch z debugerem. Zaloguj się i rozpocznij pracę na maszynie docelowej lub rozpocznij zdalne debugowanie. Użyj narzędzi takich jak WinDbg i KD.
Debugger to druga, po kompilatorze, rzecz do tworzenia programów. Jednak wielu z tych, którzy piszą programy komputerowe i używają debuggera, nie jest świadomych zasad i mechanizmów jego działania.
Trudno być debugerem ...
W związku z tym, że programiści używają debuggera w dzień iw nocy, zwłaszcza gdy wchodzą w tryb głębokiego debugowania, warto powiedzieć, że gdyby debugger nie był programem, a sprzętem, prawdopodobnie by się przegrzał i zepsuł. Ponieważ nawet kompilator nie ma tyle pracy, ile dostaje debugger.
Oczywiście, ponieważ obecnie istnieje wiele różnych języków programowania, debuggery dla każdego z nich są różne. I oczywiście dla różnych kategorii tych języków istnieją różnice w działaniu debuggerów: na przykład debugger dla interpretowanych programów Ruby będzie działał inaczej niż dla Javy skompilowanej do kodu bajtowego, a debugger dla Javy będzie się z kolei różnił od debuggera Visual C ++.
Omówię debugowanie dla platformy Windows. Po zrozumieniu zasad debuggerów do tego celu będzie można zrozumieć zarówno debuggery dla systemów POSIX, jak i debuggery, które nie działają na poziomie systemu operacyjnego, ale na poziomie maszyny wirtualnej lub jakiegoś interpretera.
Debugery dla systemu Windows: dwa rodzaje
Istnieją dwa zasadniczo różne typy debugerów dla systemu Windows. Myślę, że wszyscy jako pierwsi zetknęli się, kiedy programowali w Delphi (nie programowali w tym? Aż trudno w to uwierzyć. Co programowaliście w szkole i w młodszych latach?). Są to debugery aplikacji niestandardowych. Jest ich wiele i istnieją one zarówno osobno, jak i (nawiasem mówiąc, często) w ramach zintegrowanych środowisk programistycznych. OllyDbg tradycyjnie wyróżnia się wśród debuggerów dystrybuowanych jako osobne oprogramowanie, o czym pisałem kiedyś w „Computer News”.
Drugim typem debuggera jest jądro systemu operacyjnego. Są one spotykane i używane rzadziej, a ich konstrukcja znacznie różni się od debugerów do aplikacji niestandardowych. Najbardziej znanym i jednocześnie najlepszym z debuggerów jądra jest SoftIce. Być może nie tylko o tym słyszałeś, ale nawet z niego korzystałeś.
Ponieważ praca każdego z dwóch typów debuggerów ma swoją specyfikę, opowiem więcej o każdym z nich.
Debuger aplikacji niestandardowych
Debugger aplikacji niestandardowych jest prostszy, ponieważ system operacyjny przejmuje najbrudniejszą i najbrudniejszą pracę. System Windows ma specjalne interfejsy programistyczne do debugowania aplikacji na poziomie użytkownika - nazywane są one interfejsem API debugowania systemu Windows. Są to interfejsy API debugowania, z których korzystają wszystkie debugery wbudowane w popularne środowiska IDE systemu Windows.
Aby debugowanie się rozpoczęło, debugger musi rozpocząć debugowany proces w specjalny sposób, tak aby system wiedział, że ten proces będzie w trakcie debugowania. Następnie rozpoczyna się cykl debugowania: program jest wykonywany do momentu wystąpienia określonego zdarzenia, które nazywa się zdarzeniem debugowania lub zdarzeniem debugowania. Spowoduje to uruchomienie pętli debugowania w oddzielnym wątku, aby zapobiec zawieszaniu się debugera.
Ale to dopiero początek. Ponieważ najciekawsza rzecz w pracy debugera zaczyna się już w momencie wystąpienia zdarzenia debugowania. W końcu jakie jest zadanie debuggera? Aby pomóc programiście zlokalizować błąd do określonej funkcji, określonej operacji lub określonej zmiennej. System operacyjny może również pomóc debugerowi w tym trudnym zadaniu.
Tak więc wystąpiło zdarzenie związane z debugowaniem, a następnie musimy jakoś dowiedzieć się, jak to się ma do tekstu programu. Jest to możliwe tylko wtedy, gdy sam program zawiera specjalne informacje dotyczące debugowania - tabelę symboli debugowania. Zawiera informacje o zgodności między adresami a nazwami funkcji, typami danych, numerami linii kodowych. To dzięki nim możliwe jest debugowanie, które zna każdy programista Windows. Tabele symboli mają różne formaty i dlatego nie zawsze jest możliwe debugowanie programu skompilowanego przez kompilator jednego dostawcy za pomocą debugera innego producenta. Jednak nadal można określić najpopularniejszy format - jest to PDB (Baza danych programów) i został on oczywiście opracowany przez firmę Microsoft.
Tak więc, jeśli tablica symboli debugowania jest w formacie PDB, możesz użyć specjalnego narzędzia firmy Microsoft - symbolicznego procesora debugowania. Kiedyś był częścią jądra systemu i nosił nazwę Imagehlp.dll, ale dawno temu został podzielony na osobną bibliotekę. Procesor znaków pozwala znaleźć najbliższą otwartą funkcję lub zmienną globalną pod podanym adresem, a także numer linii i nazwę pliku źródłowego, w którym ta linia się znajduje. Obsługiwane są również operacje odwrotne, na przykład znajdowanie adresu funkcji według jej nazwy.
To oczywiście nie wszystko, co wykonuje niestandardowy debugger aplikacji. Na przykład podczas debugowania aplikacji wielowątkowych występuje wiele bardzo subtelnych problemów związanych z interakcją wątków. Nawet podczas debugowania stosunkowo prostych rzeczy, takich jak usługi, istnieją niuanse.
Ale nie będziemy teraz rozwodzić się nad niuansami - na końcu artykułu powiem ci, gdzie o nich przeczytać. Na razie przyjrzyjmy się debugerom jądra.
Debuger jądra
Debugery jądra są znacznie bardziej złożonymi programami niż niestandardowe debugery aplikacji i przypuszczam, że jest to zrozumiałe, dlaczego: brakuje im pomocnika systemu operacyjnego. W tym przypadku jest ich klientem, ponieważ to ona ostatecznie muszą debugować.
Większość debuggerów jądra wymaga do działania dwóch komputerów połączonych kablem modemu zerowego. Modem zerowy to sposób na bezpośrednie połączenie dwóch komputerów za pomocą kabla przez ich porty COM lub LTP. Drugi komputer jest potrzebny, ponieważ część debugera znajdująca się na pierwszym (tym, na którym debugowany jest system) ma ograniczony dostęp do sprzętu, a zatem wszystkie dane wyjściowe przechodzą przez modem zerowy do drugiego komputera.
W nowoczesnych procesorach architektury Intel x86 występują specjalne rejestry debugowania (zarówno w starym modelu 368, jak i nowszych jest ich tylko osiem, nazywane są DR0-DR7). Rejestry te umożliwiają debugerowi ustawianie punktów przerwania dla odczytów i zapisów pamięci, a także dla portów we / wy. Ogólnie wszystko wygląda dokładnie tak i nie sądzę, aby warto było teraz szczegółowo opisywać, za co odpowiada każdy z rejestrów debugowania, jakie przerwania są używane do implementacji punktów przerwania i podawania innych podobnych informacji. Wolałbym mówić o konkretnych istniejących debuggerach jądra dla Windows.
Przede wszystkim jest to debugger wbudowany w samo jądro systemu operacyjnego. Jest dostępny we wszystkich systemach operacyjnych NT, począwszy od Windows 2000. Jest częścią pliku NTOSKRNL.EXE i można go włączyć, ustawiając opcję „/ Debug” dla systemu operacyjnego w pliku BOOT.INI. Ten debugger wymaga zerowego połączenia modemowego i drugiego komputera z tym samym systemem operacyjnym.
Istnieje inny debugger jądra firmy Microsoft - WinDBG. Ściśle mówiąc, nie jest to debugger jądra, ale debugger hybrydowy, którego można również używać do debugowania aplikacji na poziomie użytkownika. W przeciwieństwie do debugera wbudowanego w jądro ma powłokę graficzną, a zatem jest łatwiejszy w użyciu. Ten debugger obsługuje również specjalne rozszerzenia, które mogą być przydatne w niektórych zadaniach debugowania. Ale wymaga również dwóch komputerów do debugowania jądra.
Istnieje jednak debugger jądra, który może debugować na pojedynczym komputerze. To jest SoftIce. W tym samym czasie SoftIce może również debugować aplikacje. Użycie tego debuggera do programów użytkownika jest uzasadnione, na przykład, w przypadku debugowania systemów czasu rzeczywistego powiązanych z zegarem systemowym. Jeśli debugujesz za pomocą zwykłego debuggera, wynik może być nieprawidłowy, nawet jeśli program działa poprawnie, a SoftIce zatrzyma zarówno program, jak i licznik czasu. Jest to przydatne podczas debugowania aplikacji wielowątkowych. Dodatkowo SoftIce posiada bardzo, bardzo dobrze rozwinięte sposoby wyświetlania informacji o wszystkich wątkach w systemie, o synchronizacji wątków dla aplikacji wielowątkowych, informacji o uchwycie "ah ... Jedyną wadą tego debuggera jest jego złożoność dla programisty aplikacji. Ale z debuggerów jądra jest to najprostsze i najskuteczniejsze.
Dla najbardziej zaciekawionych
Oczywiście mówienie o debuggerach dla aplikacji Windows nie jest tak istotne, jak dziesięć lat temu. Cały świat zainteresował się Internetem, a głównymi użytkownikami SoftIce byli crackerzy, niestrudzeni pracownicy w dziedzinie piractwa. Jednak nie jest tak źle. Komunikacja z SoftIce niewątpliwie rozwija osobę w zakresie wiedzy o komputerze, chociaż oczywiście jeśli komunikujesz się tylko z debuggerami i nie komunikujesz się z prawdziwymi ludźmi, to możliwe są pewne skutki uboczne.
Debuggery to jedne z najbardziej charakterystycznych typów oprogramowania, ale jeśli chodzi o programowanie, nawet debuggery na poziomie użytkownika są dość złożone. Niemniej jednak, jeśli masz ochotę i czas na opracowanie własnego debuggera, Twoja wiedza na temat systemów operacyjnych i programowania znacznie wzrośnie, co oznacza, że \u200b\u200bwzrosną również Twoje szanse na dobrze płatną pracę.
Jeśli więc chcesz stworzyć swój własny debugger, to najpierw powinieneś przeczytać materiały na ten temat. Moim zdaniem najlepszym miejscem do rozpoczęcia jest książka Johna Robbinsa Debugging Windows Applications. Jest już stary, opublikowany w 2001 r., Ale zawarte w nim informacje są nadal aktualne, ponieważ mają ogólny, wręcz nieco fundamentalny charakter. Ta książka zawiera przykłady pisania debuggerów dla Windows i jest również przydatna, jeśli programujesz w C ++ i chcesz lepiej zrozumieć obsługę wyjątków. Właściwie to z tej książki uzyskałem informacje o debuggerach opisane w artykule. Jeśli nie możesz znaleźć tej książki (w końcu jest już dość stara), jest kilka adresów, które mogą Ci się przydać. Pierwsza wygląda tak: www.xakep.ru/post/19158/default.asp. Ten artykuł z magazynu „Hacker” mówi trochę więcej o debuggerach jądra niż ja, a ponadto zawiera kod prostego debuggera. A na kalashnikoff.ru/Assembler/issues/016.htm możesz dowiedzieć się, jak napisać debugger DOS. Ale oczywiście najlepiej jest przeczytać MSDN i po drodze znaleźć debuger typu open source, aby to rozgryźć. I oczywiście, jeśli zacząłeś pisać debugger, to sukces w tym trudnym zadaniu!
