Analýza výpisu paměti a jádra v systémech Windows a Unix

Informatec Digital » Zdroje » Analýza výpisu paměti a jádra v systémech Windows a Unix

Když operační systém zpanikaří nebo se zhroutí, jediný způsob, jak pochopit, co se stalo, je vytvořit a analyzovat výpis paměti jádra . Tyto výpisy zachycují vnitřní stav systému v okamžiku selhání a jsou nezbytné pro ladění složitých chyb, vyšetřování bezpečnostních incidentů nebo provádění forenzních šetření.

I když to může znít velmi „nízkoúrovňově“, analýza výpisů paměti není výhradně určena pro vývojáře jádra. Systémoví administrátoři, technici podpory a dokonce i bezpečnostní auditoři z ní mohou těžit, pokud znají správné nástroje, různé typy výpisů a základní interpretační techniky . Provedeme vás tím vším na Windows, Unix/Linux a BSD s využitím nástrojů jako WinDbg, crash, kgdb a LiME.

Co je to výpis paměti jádra a proč se vyplatí ho analyzovat?

Výpis paměti jádra (často nazývaný výpis jádra při havárii nebo jednoduše výpis jádra ) je soubor, který obsahuje kopii, úplnou nebo částečnou, paměti v okamžiku, kdy systém utrpí kritickou chybu, jako je například panika jádra v Unixu/Linuxu nebo modrá obrazovka smrti (BSOD) ve Windows.

V praxi tento typ výpisu ukládá interní struktury jádra, zásobníky volání, kontext procesů a načtené ovladače . Díky tomu lze po havárii provést analýzu post mortem, která je velmi podobná ladění živého systému, ale bez tlaku na to, že se musíte dotýkat produkčního stroje, když selhává.

Důvody pro hluboké zkoumání výpisů jádra jsou různé: od ladění zdánlivě náhodných chyb a občasných pádů až po zkoumání, zda byl systém škodlivě manipulován nebo zda pád mohl zanechat na disku stopy citlivých informací.

Kromě úplných výpisů jádra existuje možnost pořizovat výpisy jednotlivých procesů (klasické výpisy jádra ), které jsou velmi užitečné, když chceme omezit problém na konkrétní aplikaci nebo zkontrolovat dopad na důvěrnost služby, jako je e-mailový nebo messagingový klient.

Typy výpisů paměti ve Windows a jejich užitečnost

V systémech Windows může samotný operační systém generovat různé typy výpisů, když dojde k chybě STOP. Každý typ zahrnuje jinou úroveň detailů, takže je důležité vědět, jaký typ výpisu potřebujete v závislosti na problému a omezeních místa na disku.

Jedním z nejběžnějších formátů v uživatelských prostředích a na mnoha serverech je malý výpis paměti (minidump)Je to ten, který zabírá nejméně místa a obvykle se nachází v %SystemRoot%\Minidump, se soubory ve stylu MiniMMDDYY-01.dmp.

Tento mini dump obsahuje velmi specifické, ale důležité informace: kód chyby STOP a jeho parametry , seznam ovladačů načtených v době selhání, kontext procesoru, který se zastavil (PRCB), kontexty zapojeného procesu a vlákna (struktury EPROCESS a ETHREAD) a zásobník volání kernelového režimu daného vlákna.

Díky těmto základním strukturám je i s minidumpem často možné identifikovat, který ovladač nebo modul způsobuje pády, i když nebude vždy možné sledovat celou stopu, pokud problém pochází daleko od vlákna, které běželo v době pádu, a dostupné kontextové informace jsou omezené.

Systém Windows může také generovat výpisy paměti jádra a mnohem větší plné výpisy, které obsahují části nebo celou fyzickou paměť. Ty jsou obzvláště užitečné pro nízkoúrovňovou analýzu, forenzní vyšetřování a pokročilé ladění ovladačů nebo samotného systému.

Konfigurace a otevření výpisů paměti ve Windows pomocí WinDbg a KD

Abyste mohli ve Windows využívat systémové výpisy, prvním krokem je správná konfigurace možností spuštění a obnovení . V Ovládacích panelech v pokročilých vlastnostech systému můžete zvolit typ výpisu, který chcete v případě selhání vygenerovat: například „Malý výpis paměti (256 KB)“ a cestu, kam bude uložen.

Systém také vyžaduje stránkovací soubor na spouštěcím svazku o velikosti alespoň několika megabajtů pro zápis výpisu. V moderních verzích systému Windows každý pád vytvoří nový soubor a v nakonfigurované složce se uchovává historie, což umožňuje snadnou kontrolu minulých incidentů.

Po vygenerování existuje několik způsobů, jak ověřit správnost výpisů. Klasickým nástrojem je Dumpchk.exe , který umožňuje zkontrolovat základní integritu souboru a vytisknout souhrnné informace. Pro pokročilejší analýzu se používají ladicí nástroje systému Windows , včetně WinDbg (grafické rozhraní) a KD (verze pro příkazový řádek).

Po instalaci ladicího balíčku z webu společnosti Microsoft se nástroje obvykle nacházejí ve složce, například C:\Program Files\Debugging Tools for Windows . Odtud můžete otevřít příkazový řádek a načíst soubor s výpisem paměti pomocí WinDbg nebo KD, přičemž soubor zadáte pomocí parametru -z .

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

Cesta k symbolům může ukazovat na server symbolů s lokálním ukládáním do mezipaměti , například:

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

Zatímco binární cesta je obvykle něco jako C:\Windows\I386 nebo složku, kam jsme zkopírovali spustitelné soubory systému odpovídající verzi, která vygenerovala výpis. To je důležité, protože Minidumpy neobsahují všechny binární soubory, pouze odkazy na ně, takže je ladicí program musí být schopen najít.

Základní analýza výpisu stavu jádra ve Windows

Jakmile je výpis dat načten pomocí WinDbg nebo KD, je analýza výpisu dat z havárie jádra docela podobná ladění po pádu systému. První příkaz, který téměř každý spustí, je `!analyze` , který spustí automatickou analýzu a vygeneruje počáteční zprávu.

Příkaz !analyze -show ukazuje kód pro kontrolu chyb a jeho parametryZatímco !analyze -v Vytváří mnohem podrobnější výstup: podezřelý modul, zásobník volání, kontextové informace a v mnoha případech i návrhy možných příčin nebo diagnostických kroků.

Pro doplnění této analýzy příkaz .bugcheck znovu vypíše kód chyby a související parametry, které lze porovnat s referenčním kódem pro kontrolu chyb od společnosti Microsoft a zjistit tak přesný význam každé hodnoty a typické příčiny.

Příkaz lm N T (seznam modulů) vám umožňuje zobrazit Seznam načtených modulů s jejich cestou, adresami a stavemTo pomáhá ověřit, zda se ovladač identifikovaný automatickou analýzou skutečně nachází v paměti a jakou verzi má. Tento seznam je obzvláště užitečný, když máme podezření na ovladače nebo bezpečnostní komponenty třetích stran, které interagují s jádrem.

V případě potřeby můžeme zjednodušit načítání výpisů vytvořením dávkového souboru , který obdrží cestu k výpisu a spustí KD nebo WinDbg s příslušnými parametry. Tímto způsobem stačí napsat krátký příkaz, který obsahuje pouze umístění souboru, a skript se postará o vše ostatní.

Použití WinDbg pro hluboké výpisy jádra

Pro výpisy paměti v režimu jádra nabízí WinDbg také možnost práce s více soubory a relacemi. Výpisy lze otevřít z příkazového řádku pomocí -z nebo z grafického rozhraní pomocí nabídky Soubor > Otevřít výpis paměti nebo klávesové zkratky Ctrl+D.

Pokud je WinDbg již otevřen v pasivním režimu, jednoduše vyberte soubor v dialogovém okně „Otevřít výpis stavu systému“, zadejte cestu nebo procházejte disk. Po načtení můžete v určitých scénářích spustit relaci příkazem „g“ (Go) nebo přímo spustit počáteční příkazy analýzy.

Kromě klasických !analyzeJe vhodné seznámit se s sekce s referenčními informacemi o příkazech ladicího programuZde jsou popsány všechny dostupné příkazy pro čtení vnitřních struktur, zkoumání paměti, interpretaci zásobníků a mnoho dalšího. Mnoho z těchto technik je použitelných jak pro živé relace, tak pro offline výpisy.

WinDbg vám také umožňuje pracovat s více paralelních výpisůNa příkazovém řádku můžeme přidat více parametrů -z, každý následovaný jiným názvem souboru, nebo přidat nové cíle pomocí příkazu .opendumpLadění více cílů je užitečné pro porovnávání opakujících se selhání nebo zřetězených incidentů.

V některých prostředích jsou výpisy paměti zabaleny do souborů CAB, aby se ušetřilo místo nebo usnadnil přenos. WinDbg může přímo otevřít .cab s výpisem uvnitř, a to jak s použitím -z, tak s .opendumpi když bude číst Rozbalí pouze jeden z uložených souborů a nerozbalí ostatní soubory. to by mohlo jít do stejného balíčku.

Výpisy chyb v Unixu a Linuxu: utilita, nástroje a požadavky

V systémech Unix a GNU/Linux je filozofie podobná, ale ekosystém nástrojů se značně liší. Většina unixových jader nabízí možnost uložit kopii paměti v případě katastrofické události , což je známé jako výpis jádra nebo výpis pádu jádra.

Ačkoli jejich primárním využitím zůstává vývoj jádra a ovladačů, tyto výpisy mají jasný bezpečnostní aspekt. Pád systému může být způsoben programátorskými chybami, ale také neúspěšnými škodlivými akcemi, pokusy o manipulaci se systémovými komponentami nebo neobratně zneužitými podmínkami závodění.

V dobře nakonfigurovaném unixovém systému jsou denní pády neobvyklé, ale pokud k nim dojde, je vhodné mít zavedenou infrastrukturu pro výpisy, jako je Kdump, LKCD nebo jiná řešení , která umožňují zachytit systémovou paměť. Je však zásadní zvážit diagnostickou hodnotu výpisu oproti riziku, že obsahuje vysoce citlivá data.

Jedním z nejkomplexnějších a nejpoužívanějších nástrojů pro tento typ analýzy v Linuxu je crash , původně vyvinutý společností Red Hat. Tento nástroj se stal prakticky de facto standardem pro zkoumání výpisů jádra a také pro analýzu běžících systémů.

Havárie může ovlivnit živou paměť systému prostřednictvím /dev/mem nebo v Red Hatu a odvozených distribucích s použitím specifického zařízení /dev/crashPřesto je běžnou praxí dodávat nástroji soubor s výpisem generovaný mechanismy, jako je Kdump, soubor s výpisem z paměti, Výpis disku nebo architektonicky specifické výpisy jako s390/s390x nebo xendump ve virtualizovaných prostředích.

Role crash a důležitost vmlinuxu v Linuxu

Nástroj pro crash byl částečně vytvořen proto, aby překonal omezení používání gdb přímo na /proc/kcoreMimo jiné může být přístup k tomuto pseudoobrazu paměti omezen a navíc některé možnosti kompilace jádra ztěžují správnou interpretaci vnitřních struktur, pokud máme k dispozici pouze komprimovaný spustitelný binární soubor.

Pro správné fungování funkce crash jsou potřeba dva klíčové prvky: zkompilovaný soubor vmlinux s ladicími symboly (obvykle s příznaky jako -g) a samotný výpis jádra. Tato kombinace umožňuje nástroji mapovat paměťové adresy na funkce, struktury a řádky kódu.

Je důležité rozlišovat mezi vmlinux a vmlinuzNa většině systémů je viditelný pouze vmlinux, což je komprimovaná, bootovací verze jádra. Pád vyžaduje symbolicky dekomprimovaný vmlinux; bez něj se při pokusu o načtení výpisu nebo /dev/mem Setkáme se s chybami typu Nelze najít spuštěné jádro – zadejte prosím argument seznamu názvů.

Ačkoli je možné ručně extrahovat balíček vmlinuz, tento proces není vždy přímočarý a v praxi je často mnohem pohodlnější jádro znovu zkompilovat, abyste získali vmlinux i vmlinuz současně. V seriózních administrátorských prostředích je dobrým zvykem udržovat pro každou nasazenou verzi jádra samostatný balíček vmlinuz, konkrétně pro tyto situace.

Jakmile jsou splněny požadavky, spuštění crash s výpisem je relativně jednoduché: zadáte příslušný vmlinux a soubor s výpisem a nástroj otevře interaktivní relaci, ze které můžete prozkoumávat struktury jádra, vypisovat procesy, prohlížet zásobníky volání a extrahovat forenzní informace . Ti, kteří se chtějí ponořit hlouběji, mohou nahlédnout do specializované dokumentace, jako je například známý technický dokument o crash.

Omezení /dev/mem a první přístupy v Linuxu

Než se uchýlili ke konkrétním nástrojům, mnoho administrátorů se historicky snažilo získat výpis paměti. čtení přímo ze zařízení /dev/memTento přístup se zdál jednoduchý: použít nástroj jako výpis paměti (který vypíše dané zařízení do STDOUT) nebo z něj stáhne dd if=/dev/mem of=volcado.mem.

Moderní jádra však nabízejí možnosti kompilace, jako například CONFIG_STRICT_DEVMEMkteré výrazně omezují přístup z uživatelského prostoru k /dev/memTypickým výsledkem je, že čtení je po malém bloku (např. 1 MB) přerušeno, nebo v nejhorším případě může chyba v této interakci skončit... panika panny okamžitý a restart stroje.

Tato ochrana dává z bezpečnostního hlediska dokonalý smysl, ale nutí nás hledat jiné způsoby, jak získat spolehlivý a úplný výpis, aniž bychom se museli spoléhat výhradně na generická zařízení, která již nejsou tak dostupná jako dříve.

Současným trendem je proto spoléhat se na specifické moduly nebo integrované infrastruktury pro výpisy chyb, místo aby se jednoduše snažili „pročistit paměť“ pomocí nástrojů uživatelského prostoru, které nejsou navrženy pro koexistenci s moderními zásadami ochrany jádra.

LiME Forensics: Extrakce paměti v Linuxu a Androidu

Velmi silnou alternativou ve světě forenzních analýz je LiME (Linux Memory Extractor) , modul jádra navržený přesně tak, aby kontrolovaným způsobem a bez omezení, která ovlivňují /dev/mem, zachytával volatilní paměť. LiME běží v prostoru jádra, takže může mnohem přímočařeji přistupovat k paměti RAM.

LiME je distribuován se zdrojovým kódem a kompiluje se s ním. používané hlavičky jádraProces kompilace generuje modul .ko specifické pro verzi jádra, do které bude načten. Po kompilaci jej můžeme ověřit pomocí nástrojů, jako je file abychom zajistili, že modul ELF odpovídající naší architektuře byl správně vygenerován.

Pro použití LiME jednoduše načtěte modul pomocí insmod z kořenového adresáře a předat mu příslušné možnosti, například zadáním cíl síťového výpisu pomocí TCP a RAW formátu:

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

Souběžně na počítači, který bude přijímat výpis, posloucháme nakonfigurovaný port pomocí nástroje, jako je ncpřesměrování výstupu do souboru:

nc <IP_origen> 4444 > volcado.mem

Po několika minutách, v závislosti na množství RAM a výkonu sítě, budeme mít soubor, jehož velikost odpovídá fyzické paměti zdrojového systému. Jedná se o kompletní výpis RAM, který můžeme analyzovat pomocí forenzních nástrojů nebo dokonce pomocí řetězců či jiných utilit jako první krok k nalezení zajímavých řetězců.

Výpisy procesů a rizika úniku dat

Úplný výpis jádra je extrémně informativní, ale může být také nadbytečný, pokud nás zajímá pouze konkrétní proces. V takovém případě dává velký smysl uchýlit se k... jednotlivé výpisy procesů pomocí nástrojů jako gcore v Unixu/Linuxu.

Tyto výpisy dat pro jednotlivé procesy jsou mnohem menší a lépe spravovatelné a umožňují vám zaměřit analýzu na konkrétní aplikace, jako je klient pro zasílání zpráv (např. Skype) nebo e-mailový klient (např. Thunderbird), kde je relativně snadné najít hesla v prostém textu, tokeny relací nebo kontaktní data prozkoumáním paměťových řetězců.

Z vývojářského hlediska tyto výpisy paměti pomáhají lokalizovat programovací chyby, úniky paměti nebo nekonzistentní stavy ve službě. Z bezpečnostního hlediska však problém nastává, když jsou tyto výpisy generovány rutinně a ukládány na místa přístupná ostatním uživatelům , ať už v samotném systému nebo na sdílených síťových prostředcích.

Pokud uživatel naplánuje například úkol cron Pravidelným zachycováním výpisů citlivých procesů a jejich ukládáním do globálně čitelného adresáře útočník otevírá obrovské dveře k odhalení kritických informací. V mnoha scénářích auditu analýza těchto souborů umožňuje útočníkovi obnovit přihlašovací údaje, seznamy kontaktů, historie komunikace a další soukromá data s relativně malým úsilím.

Proto je při jakémkoli seriózním auditu unixového systému vhodné věnovat několik minut kontrole, zda se generují výpisy (úplné nebo částečné), kde se ukládají, jaká mají oprávnění a zda existuje nějaký automatizovaný proces, který ponechává kopie paměti v dosahu neoprávněných uživatelů.

Postmortem analýza výpisů ve FreeBSD s kgdb

Ve světě BSD, a konkrétně ve FreeBSD, zahrnuje přístup k post-mortem analýze Povolit v systému výpisy chyb a nechat jádro zkompilované s ladicími symbolyToto se ovládá z konfiguračního adresáře jádra, obvykle v /usr/src/sys/<arq>/conf.

V odpovídajícím konfiguračním souboru lze generování symbolů povolit řádkem podobným tomuto:

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

Po úpravě konfigurace je nutné jádro znovu zkompilovat. Některé objekty budou regenerovány (například trap.o) kvůli změně v souborech sestavení. Cílem je získat jádro s stejný kód jako ten, který má problémy, ale s přidáním potřebných ladicích informacíJe vhodné porovnat staré a nové velikosti pomocí příkazu size aby se zajistilo, že v binárním souboru nedošlo k žádným neočekávaným změnám.

Jakmile je jádro se symboly nainstalováno, můžeme prozkoumat výpisy pomocí kgdb , jak je popsáno v oficiální dokumentaci. Ne všechny symboly mohou být úplné a některé funkce se mohou zobrazit bez čísel řádků nebo informací o argumentech, ale ve většině případů je úroveň detailů dostatečná k vysledování problému.

Neexistuje absolutní záruka, že analýza vyřeší všechny incidenty, ale v praxi tato strategie funguje docela dobře ve vysokém procentu scénářů , zejména když jsou výpisy chyb kombinovány s dobrým přehledem nedávných změn v systému.

Nejlepší postupy pro analýzu a dokumentaci chyb jádra

Bez ohledu na operační systém analýza výpisu jádra obvykle skončí odkazováním na technickou dokumentaci, znalostní báze, specializovaná fóra nebo dokonce samotný zdrojový kód jádra za účelem interpretace zpráv, chybových kódů a neznámých symbolů.

V Linuxu je velmi užitečné spoléhat se na oficiální strom zdrojového kódu, vestavěnou dokumentaci a komunitní zdroje. Mnoho chybových hlášení jádra lze vysledovat zpět k přesnému souboru, ze kterého pocházejí, což pomáhá pochopit kontext, ve kterém je konkrétní BUG() nebo WARN() spuštěna.

V systému Windows poskytuje dokumentace společnosti Microsoft, její znalostní báze (KB) a technická fóra podrobná vysvětlení kódů kontroly chyb, doporučení pro řešení problémů a známé vzorce chyb . Kombinace těchto informací se zprávami z příkazu !analyze -v umožňuje vytvořit rozumný plán pro zmírnění následků.

Skutečná hodnota výpisu stavu po havárii se projeví, když jsou všechny tyto informace porovnány s důkladným pochopením operačního systému a konkrétního prostředí, kde k selhání došlo . Teprve potom lze vyvinout trvalá řešení a především zabránit tomu, aby se stejný problém v budoucnu opakoval s vážnějšími následky.

Analýza výpisu jádra je v konečném důsledku směsicí vědy a řemesla: vyžaduje vhodné nástroje, předchozí konfiguraci (symboly, možnosti výpisu, bezpečné úložiště) a značné zkušenosti s čtením zásobníků, struktur a chybových kódů. Zvládnutí těchto technik nám umožňuje nejen ladit složité incidenty, ale také dramaticky zvýšit bezpečnost a odolnost systémů, které spravujeme.