Zrzut pamięci i analiza jądra w systemach Windows i Unix

Informatec Digital » Zasoby » Zrzut pamięci i analiza jądra w systemach Windows i Unix

Gdy system operacyjny wpada w panikę lub ulega spektakularnej awarii, jedynym sposobem, aby dowiedzieć się, co się stało, jest... zrzut pamięci jądra i późniejsza analizaZrzuty te rejestrują stan wewnętrzny systemu w chwili awarii i stanowią podstawowy materiał do debugowania złożonych błędów, badania incydentów bezpieczeństwa lub przeprowadzania analiz kryminalistycznych.

Choć może to brzmieć bardzo „niskopoziomowo”, analiza zrzutu pamięci nie jest domeną wyłącznie programistów jądra. Administratorzy systemów, inżynierowie wsparcia, a nawet audytorzy bezpieczeństwa mogą z niej skorzystać, jeśli znają podstawy. odpowiednie narzędzia, rodzaje zrzutów i podstawowe techniki interpretacjiPrzeprowadzimy całą tę ścieżkę w systemach Windows, Unix/Linux i BSD, korzystając z narzędzi takich jak WinDbg, crash, kgdb i LiME.

Czym jest zrzut pamięci jądra i dlaczego warto się nim zająć?

Zrzut pamięci jądra (często nazywany Zrzut awaryjny jądra lub po prostu zrzut awaryjny) to plik zawierający kopię, całkowitą lub częściową, pamięci w momencie, gdy system ulegnie krytycznej awarii, np. panika jądra w systemach Unix/Linux lub niebieski ekran śmierci (BSOD) w systemie Windows.

W praktyce zrzut tego typu pozwala zaoszczędzić wewnętrzne struktury jądra, stosy wywołań, kontekst procesu i załadowane sterownikiDzięki temu po katastrofie można przeprowadzić analizę „post-mortem”, bardzo podobną do debugowania działającego systemu, ale bez presji związanej z koniecznością dotykania maszyny produkcyjnej w trakcie jej awarii.

Powody zagłębiania się w zrzuty jądra są różne: od debugowanie pozornie losowych błędów i sporadycznych awarii...badamy nawet, czy system został złośliwie zmanipulowany lub czy awaria mogła pozostawić ślady poufnych informacji na dysku.

Oprócz pełnych zrzutów jądra istnieje możliwość wyodrębniania zrzutów poszczególnych procesów (klasyczny zrzuty rdzeni), które są bardzo przydatne, gdy chcemy ograniczenie problemu do konkretnego zastosowania lub sprawdzenie wpływu na poufność usługi jak klient poczty elektronicznej lub komunikatora.

Rodzaje zrzutów pamięci w systemie Windows i ich przydatność

W systemach Windows sam system operacyjny może generować różne typy zrzutów w przypadku wystąpienia błędu STOP. Każdy typ obejmuje inny poziom szczegółowości, dlatego kluczowe jest, aby wiedzieć, z których zrzutów korzystać. Jakiego typu zrzutu potrzebujemy, biorąc pod uwagę rodzaj problemu i ograniczenia miejsca na dysku?.

Jednym z najczęściej spotykanych formatów w środowiskach użytkowników i wielu serwerach jest mały zrzut pamięci (minidump)Jest to ten, który zajmuje najmniej miejsca i zwykle znajduje się w %SystemRoot%\Minidump, z plikami w stylu MiniMMDDYY-01.dmp.

Ten mini zrzut zawiera bardzo szczegółowe, ale ważne informacje: Kod błędu STOP i jego parametry, listę sterowników załadowanych w momencie awarii, kontekst procesora, który się zatrzymał (PRCB), konteksty zaangażowanego procesu i wątku (struktury EPROCESS i ETHREAD) oraz stos wywołań trybu jądra tego wątku.

Dzięki tym podstawowym strukturom, nawet przy użyciu minizrzutu, często można zidentyfikować sterownik lub moduł powodujący awarie, choć nie zawsze da się prześledzić cały problem, jeśli jego źródło jest odległe od wątku, który był uruchomiony w momencie awarii. Dostępność informacji kontekstowych jest ograniczona.

System Windows może również generować zrzuty pamięci jądra oraz znacznie większe zrzuty pełne, zawierające fragmenty lub całość pamięci fizycznej. Są one szczególnie przydatne w analiza niskiego poziomu, dochodzenia kryminalistyczne i zaawansowane debugowanie sterowników lub samego systemu.

Konfigurowanie i otwieranie zrzutów pamięci w systemie Windows za pomocą WinDbg i KD

Aby w pełni wykorzystać możliwości zrzutów w systemie Windows, należy najpierw poprawnie skonfigurować opcje. uruchamianie i odzyskiwanieW Panelu sterowania, w zaawansowanych właściwościach systemu, możesz wybrać typ zrzutu, jaki chcesz wygenerować w razie awarii, na przykład „Mały zrzut pamięci (256 KB)”, a także ścieżkę, w której zostanie on zapisany.

System wymaga również plik stronicowania na woluminie rozruchowym o rozmiarze co najmniej kilku megabajtów w celu zapisania zrzutu. W nowoczesnych wersjach systemu Windows każda awaria tworzy nowy plik, a historia jest przechowywana w skonfigurowanym folderze, co umożliwia łatwy przegląd wcześniejszych incydentów.

Po wygenerowaniu istnieje kilka sposobów na sprawdzenie poprawności zrzutów. Jednym z klasycznych narzędzi jest Dumpchk.execo pozwala na sprawdzenie podstawowej integralności pliku i wydrukowanie podsumowania. Do bardziej zaawansowanej analizy wykorzystywane są następujące narzędzia: Narzędzia debugowania dla systemu Windowsw tym WinDbg (interfejs graficzny) i KD (wersja wiersza poleceń).

Po zainstalowaniu pakietu debugowania ze strony internetowej firmy Microsoft narzędzia zwykle znajdują się w folderze takim jak C:\Pliki programów\Narzędzia debugowania dla systemu WindowsStamtąd możemy otworzyć wiersz poleceń i załadować zrzut za pomocą WinDbg lub KD z użyciem parametru -z aby określić plik:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Ścieżka symbolu może wskazywać na serwer symboli z lokalną pamięcią podręczną, na przykład:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Chociaż ścieżka binarna zwykle wygląda tak: C:\Windows\I386 lub folder, do którego skopiowaliśmy pliki wykonywalne systemu odpowiadające wersji, która wygenerowała zrzut. Jest to ważne, ponieważ Minizrzuty nie zawierają wszystkich plików binarnych, tylko odniesienia do nich, więc debuger musi być w stanie je znaleźć.

Podstawowa analiza zrzutu awaryjnego jądra w systemie Windows

Po załadowaniu zrzutu za pomocą WinDbg lub KD, analiza zrzutu awaryjnego jądra jest dość podobna do sesji debugowania post mortem. Pierwszym poleceniem, które prawie każdy uruchamia, jest !analizować, który uruchamia automatyczną analizę i generuje początkowy raport.

Polecenie !analyze -show pokazuje kod sprawdzający błędy i jego parametryPodczas !analyze -v Daje znacznie bardziej szczegółowy wynik: podejrzany moduł, stos wywołań, informacje kontekstowe, a w wielu przypadkach także sugestie dotyczące możliwych przyczyn lub kroków diagnostycznych.

Aby uzupełnić tę analizę, polecenie .sprawdzanie błędów Ponownie drukuje kod błędu i powiązane parametry, które następnie można porównać z odniesienie do kodu sprawdzającego błędy od Microsoftu, aby poznać dokładne znaczenie każdej wartości i typowe przyczyny.

Polecenie lm N T (lista modułów) pozwala zobaczyć Lista załadowanych modułów ze ścieżką, adresami i statusemPomaga to potwierdzić, czy sterownik zidentyfikowany przez automatyczną analizę rzeczywiście znajduje się w pamięci i w jakiej jest wersji. Ta lista jest szczególnie przydatna, gdy podejrzewamy, że sterowniki innych firm lub komponenty zabezpieczeń wchodzą w interakcję z jądrem.

Jeśli zajdzie taka potrzeba, możemy uprościć proces ładowania zrzutu, tworząc plik wsadowy Powinien otrzymać ścieżkę do pliku zrzutu i uruchomić KD lub WinDbg z odpowiednimi parametrami. W ten sposób wystarczy napisać krótkie polecenie zawierające lokalizację pliku, a skrypt zajmie się resztą.

Korzystanie z WinDbg do głębokich zrzutów jądra

W przypadku zrzutów pamięci w trybie jądra WinDbg oferuje również możliwość pracy z wieloma plikami i sesjami. Zrzuty można otwierać z wiersza poleceń za pomocą -zlub z interfejsu graficznego, korzystając z menu Plik > Otwórz zrzut pamięci lub skrótu klawiaturowego Ctrl + D.

Jeśli WinDbg jest już otwarty w trybie pasywnym, wystarczy wybrać plik w oknie dialogowym „Otwórz zrzut awaryjny”, podając ścieżkę lub przeglądając dysk. Po załadowaniu możemy rozpocząć sesję poleceniem g (Idź) w pewnych scenariuszach lub bezpośrednio uruchomić pierwsze polecenia analizy.

Oprócz klasycznego !analyzeWarto zapoznać się z sekcja odniesienia do poleceń debugeraOpisuje wszystkie dostępne polecenia do odczytu struktur wewnętrznych, badania pamięci, interpretacji stosów i wielu innych. Wiele z tych technik ma zastosowanie zarówno w sesjach na żywo, jak i w zrzutach offline.

WinDbg pozwala również na pracę z wiele równoległych zrzutówMożemy dodać wiele parametrów -z w wierszu poleceń, po każdym z których będzie następować inna nazwa pliku, lub dodać nowe cele za pomocą polecenia .opendumpDebugowanie wielu miejsc docelowych jest przydatne do porównywania powtarzających się awarii lub łańcuchów incydentów.

W niektórych środowiskach zrzuty pamięci są pakowane w pliki CAB, aby zaoszczędzić miejsce lub ułatwić transmisję. WinDbg może bezpośrednio otwierać .cab z zrzutem wewnątrz, zarówno używając -z, jak i z .opendumpchociaż będzie czytał Wyodrębniony zostanie tylko jeden z wyrzuconych plików, a pozostałe nie zostaną wyodrębnione. które mogłyby znaleźć się w tym samym pakiecie.

Zrzuty awaryjne w systemach Unix i Linux: narzędzia, użyteczność i wymagania

W systemach Unix i GNU/Linux filozofia jest podobna, ale ekosystem narzędzi znacznie się różni. Większość jąder typu Unix oferuje możliwość zapisz kopię pamięci, gdy wydarzy się katastrofaco znamy jako zrzut rdzenia lub Kernel Crash Dump.

Chociaż ich głównym zastosowaniem pozostaje rozwój jądra i sterowników, te zrzuty danych mają wyraźny aspekt bezpieczeństwa. Awaria może być spowodowana przez błędy programistyczne, ale także działania złośliwe nieudane próby manipulowania elementami systemu lub nieudolne wykorzystanie warunków wyścigu.

W dobrze skonfigurowanym systemie Unix codzienne awarie nie zdarzają się często, lecz gdy już się zdarzają, warto mieć przygotowany plan zapasowy. infrastruktura zrzutowa, taka jak Kdump, LKCD lub inne rozwiązania które umożliwiają przechwycenie pamięci systemowej. Należy jednak rozważyć zarówno wartość diagnostyczną zrzutu, jak i ryzyko, że zawiera on bardzo wrażliwe dane.

Jednym z najbardziej kompletnych i rozpowszechnionych narzędzi do tego typu analizy w systemie Linux jest crashNarzędzie to, pierwotnie opracowane przez firmę Red Hat, stało się w zasadzie standardem do badania zrzutów jądra i analizowania działających systemów.

Awaria może działać na szkodę pamięci operacyjnej systemu poprzez /dev/mem lub w Red Hat i dystrybucjach pochodnych, używając konkretnego urządzenia /dev/crashMimo to powszechną praktyką jest dostarczanie narzędziu pliku zrzutu wygenerowanego przez mechanizmy takie jak Kdump, plik makedump, Zrzut dysku lub zrzuty specyficzne dla architektury, takie jak s390/s390x lub xendump w środowiskach wirtualnych.

Rola awarii i znaczenie vmlinux w systemie Linux

Narzędzie do usuwania awarii zostało stworzone częściowo w celu przezwyciężenia ograniczeń związanych z używaniem gdb bezpośrednio na /proc/kcoreMiędzy innymi dostęp do tego pseudo-obrazu pamięci może być ograniczony, a ponadto niektóre opcje kompilacji jądra utrudniają właściwą interpretację wewnętrznych struktur, jeśli dysponujemy wyłącznie skompresowanym plikiem wykonywalnym.

Aby crash działał prawidłowo, niezbędne są dwa kluczowe elementy: plik vmlinux skompilowany z symbolami debugowania (zwykle z flagami takimi jak -g) i samym zrzutem jądra. Ta kombinacja pozwala narzędziu mapować adresy pamięci na funkcje, struktury i wiersze kodu.

Ważne jest, aby rozróżnić vmlinux i vmlinuzW większości systemów widoczny jest tylko vmlinux, czyli skompresowana, bootowalna wersja jądra. Crash wymaga symbolicznie zdekompresowanego vmlinux; bez niego, podczas próby załadowania zrzutu lub /dev/mem Napotkamy błędy typu nie można znaleźć uruchomionego jądra — proszę wprowadzić argument listy nazw.

Mimo że możliwe jest ręczne rozpakowanie vmlinuz, proces ten nie zawsze jest łatwy i w praktyce okazuje się znacznie wygodniejszy. Przekompiluj jądro, aby uzyskać zarówno vmlinux, jak i vmlinuz Równolegle. W środowiskach wymagających poważnej administracji, dobrą praktyką jest utrzymywanie vmlinux odpowiadającego każdej wersji jądra wdrożonej właśnie na potrzeby takich przypadków.

Po spełnieniu wymagań, awaria zrzutu jest stosunkowo prosta: należy określić odpowiedni plik vmlinux i zrzut, a narzędzie otwiera sesję interaktywną, z której można przeglądaj struktury jądra, wyświetlaj listę procesów, przeglądaj stosy wywołań i wyodrębniaj informacje kryminalistyczneOsoby zainteresowane bardziej szczegółowym zrozumieniem tematu mogą zapoznać się ze specjalistyczną dokumentacją, np. powszechnie znanym technicznym dokumentem opisującym awarie.

Ograniczenia /dev/mem i pierwsze podejścia w systemie Linux

Zanim zaczęto korzystać z konkretnych narzędzi, wielu administratorów próbowało wykonać zrzut pamięci. odczyt bezpośrednio z urządzenia /dev/memTo podejście wydawało się proste: użyj narzędzia takiego jak zrzut pamięci (który zrzuca to urządzenie na STDOUT) lub wyciąga z dd if=/dev/mem of=volcado.mem.

Jednakże współczesne jądra oferują opcje kompilacji, takie jak: CONFIG_STRICT_DEVMEMktóre poważnie ograniczają dostęp z przestrzeni użytkownika do /dev/memTypowym wynikiem jest to, że odczyt zostaje przerwany po małym bloku (np. 1 MB) lub, w najgorszym przypadku, błąd w tej interakcji może zakończyć się panika jądra natychmiastowe ponowne uruchomienie maszyny.

Ta ochrona jest całkowicie uzasadniona z punktu widzenia bezpieczeństwa, ale zmusza nas do poszukiwania Inne sposoby uzyskania wiarygodnego i kompletnego zrzutu bez polegania wyłącznie na urządzeniach uniwersalnych, które nie są już tak dostępne jak kiedyś.

Dlatego też obecnie panuje tendencja do polegania na konkretnych modułach lub zintegrowanej infrastrukturze zrzutu awaryjnego, zamiast po prostu próbować „zgarniać pamięć” za pomocą narzędzi przestrzeni użytkownika, które nie są zaprojektowane do współistnienia z nowoczesnymi zasadami ochrony jądra.

LiME Forensics: Ekstrakcja pamięci w systemach Linux i Android

Bardzo mocną alternatywą w świecie medycyny sądowej jest LiME (Linux Memory Extractor)LiME to moduł jądra zaprojektowany specjalnie do kontrolowanego przechwytywania pamięci ulotnej bez ograniczeń, które dotyczą /dev/mem. LiME działa w przestrzeni jądra, dzięki czemu ma znacznie bardziej bezpośredni dostęp do pamięci RAM.

LiME jest dystrybuowany wraz z kodem źródłowym i kompiluje się w oparciu o nagłówki jądra w użyciuProces kompilacji generuje moduł .ko specyficzne dla wersji jądra, do której zostanie załadowany. Po skompilowaniu możemy go zweryfikować za pomocą narzędzi takich jak file aby mieć pewność, że moduł ELF odpowiadający naszej architekturze został poprawnie wygenerowany.

Aby użyć LiME, wystarczy załadować moduł insmod z roota i przekazać mu odpowiednie opcje, na przykład poprzez określenie miejsce zrzutu sieciowego przy użyciu protokołu TCP i formatu surowego:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

Równolegle na komputerze, który będzie odbierał zrzut, nasłuchujemy na skonfigurowanym porcie za pomocą narzędzia takiego jak ncprzekierowywanie wyjścia do pliku:

nc <IP_origen> 4444 > volcado.mem

Po kilku minutach, w zależności od ilości pamięci RAM i wydajności sieci, otrzymamy plik o rozmiarze odpowiadającym rozmiarowi pamięci fizycznej systemu źródłowego. To jest kompletny zrzut pamięci RAM, który możemy analizować za pomocą narzędzi kryminalistycznych, a nawet ciągów znaków lub innych narzędzi jako pierwszy krok w celu zlokalizowania interesujących łańcuchów.

Zrzuty procesów i ryzyko ujawnienia danych

Pełny zrzut jądra jest niezwykle pouczający, ale może być też przesadny, gdy interesuje nas tylko konkretny proces. W takim przypadku bardzo sensowne jest skorzystanie z... indywidualne zrzuty procesów korzystając z narzędzi takich jak gcore w systemach Unix/Linux.

Te zrzuty dla poszczególnych procesów są znacznie mniejsze i łatwiejsze w zarządzaniu, a także pozwalają skupić analizę na konkretnych aplikacjach, takich jak klient wiadomości (np. Skype) lub klient poczty e-mail (np. Thunderbird), gdzie stosunkowo łatwo je znaleźć hasła w postaci zwykłego tekstu, tokenów sesji lub danych kontaktowych jeśli ciągi pamięci zostaną zbadane.

Z perspektywy programistycznej te zrzuty pamięci pomagają zlokalizować błędy programistyczne, wycieki pamięci lub niespójne stany w usłudze. Jednak z perspektywy bezpieczeństwa problem pojawia się, gdy Zrzuty są generowane rutynowo i przechowywane w lokalizacjach dostępnych dla innych użytkowników.zarówno w samym systemie, jak i w udostępnionych zasobach sieciowych.

Jeśli użytkownik zaplanuje na przykład zadanie cron Okresowo przechwytując zrzuty wrażliwych procesów i pozostawiając je w globalnie czytelnym katalogu, atakujący otwiera ogromne możliwości ujawnienia krytycznych informacji. W wielu scenariuszach audytu analiza tych plików pozwala atakującemu na odzyskanie danych. dane uwierzytelniające, listy kontaktów, historie komunikacji i inne prywatne dane przy stosunkowo niewielkim wysiłku.

Dlatego też podczas każdego poważnego audytu systemu Unix wskazane jest poświęcenie kilku minut na sprawdzenie, czy generowane są zrzuty (pełne lub częściowe), gdzie są przechowywane, jakie mają uprawnienia i czy występują jakiekolwiek zautomatyzowany proces, który pozostawia kopie pamięci dostępne dla nieautoryzowanych użytkowników.

Analiza post mortem zrzutów w FreeBSD z kgdb

W świecie BSD, a szczególnie w FreeBSD, podejście do analizy post mortem obejmuje Włącz zrzuty awaryjne w systemie i skompiluj jądro z symbolami debugowaniaJest to kontrolowane z katalogu konfiguracji jądra, zwykle w /usr/src/sys/<arq>/conf.

W odpowiednim pliku konfiguracyjnym generowanie symboli można włączyć za pomocą następującego wiersza:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

Po zmianie konfiguracji jądro musi zostać ponownie skompilowane. Niektóre obiekty zostaną wygenerowane ponownie (np. trap.o) ze względu na zmianę plików kompilacji. Celem jest uzyskanie jądra z ten sam kod, który powoduje problemy, ale dodaje niezbędne informacje debugowaniaZaleca się porównanie starych i nowych rozmiarów za pomocą polecenia size aby mieć pewność, że w pliku binarnym nie zaszły żadne nieoczekiwane zmiany.

Po zainstalowaniu jądra za pomocą symboli możemy teraz zbadać zrzuty za pomocą kgdb Zgodnie z opisem w oficjalnej dokumentacji. Nie wszystkie symbole mogą być kompletne, a niektóre funkcje mogą pojawiać się bez numerów wierszy lub informacji o argumentach, ale w większości przypadków poziom szczegółowości jest wystarczający, aby zlokalizować problem.

Nie ma absolutnej gwarancji, że analiza rozwiąże wszystkie incydenty, ale w praktyce Ta strategia sprawdza się bardzo dobrze w wielu scenariuszachszczególnie, gdy zrzuty pamięci połączy się z rzetelnym przeglądem ostatnich zmian w systemie.

Najlepsze praktyki analizowania i dokumentowania błędów jądra

Niezależnie od systemu operacyjnego analiza zrzutu jądra zwykle kończy się dokumentacja techniczna, bazy wiedzy, specjalistyczne fora, a nawet sam kod źródłowy jądra interpretować komunikaty, kody błędów i nieznane symbole.

W Linuksie bardzo pomocne jest korzystanie z oficjalnego drzewa kodu źródłowego, wbudowanej dokumentacji i zasobów społeczności. Wiele komunikatów o błędach jądra można powiązać z konkretnym plikiem, z którego pochodzą, co pomaga w zrozumieniu problemu. kontekst, w którym wyzwalany jest BUG() lub WARN() ustalona.

W systemie Windows szczegółowe wyjaśnienia można znaleźć w dokumentacji firmy Microsoft, jej bazie wiedzy (KB) i na forach technicznych. kody sprawdzające błędy, zalecenia dotyczące rozwiązywania problemów i znane wzorce błędówŁącząc te informacje z raportami polecenia !analyze -v, możliwe jest sporządzenie rozsądnego planu łagodzenia skutków.

Prawdziwa wartość zrzutu awaryjnego ujawnia się, gdy wszystkie te informacje zostaną porównane z solidna znajomość systemu operacyjnego i konkretnego środowiska, w którym wystąpiła awariaTylko w ten sposób można proponować trwałe rozwiązania i, przede wszystkim, zapobiegać ponownemu wystąpieniu tego samego problemu w przyszłości i poważniejszym skutkom.

Analiza zrzutu pamięci jądra to w gruncie rzeczy połączenie nauki i rzemiosła: wymaga odpowiednich narzędzi, wcześniejszej konfiguracji (symboli, opcji zrzutu, bezpiecznego przechowywania) oraz sporego doświadczenia w odczytywaniu stosów, struktur i kodów błędów. Opanowanie tych technik pozwala nie tylko debugować złożone incydenty, ale także… aby radykalnie zwiększyć poziom bezpieczeństwa i odporności zarządzanych przez nas systemów.