Analýza výpisu pamäte a jadra v systémoch Windows a Unix

Informatec Digital » Zdroje » Analýza výpisu pamäte a jadra v systémoch Windows a Unix

Keď operačný systém prepadne alebo zlyhá, jediný spôsob, ako pochopiť, čo sa stalo, je vytvoriť výpis pamäte jadra a analyzovať ho . Tieto výpisy zachytávajú vnútorný stav systému v momente zlyhania a sú nevyhnutné na ladenie zložitých chýb, vyšetrovanie bezpečnostných incidentov alebo vykonávanie forenzných vyšetrovaní.

Aj keď to môže znieť veľmi „nízkoúrovňovo“, analýza výpisov pamäte nie je výhradne záležitosťou vývojárov jadra. Systémoví administrátori, technici podpory a dokonca aj bezpečnostní audítori z nej môžu profitovať, ak poznajú správne nástroje, rôzne typy výpisov a základné techniky interpretácie . Prevedieme vás tým všetkým v systémoch Windows, Unix/Linux a BSD pomocou nástrojov ako WinDbg, crash, kgdb a LiME.

Čo je to výpis pamäte jadra a prečo sa oplatí ho analyzovať?

Výpis pamäte jadra (často nazývaný výpis jadra pri havárii alebo jednoducho výpis pri havárii ) je súbor, ktorý obsahuje kópiu, buď úplnú alebo čiastočnú, pamäte v čase, keď systém utrpí kritickú chybu, ako je napríklad panika jadra v systémoch Unix/Linux alebo modrá obrazovka smrti (BSOD) v systéme Windows.

V praxi tento typ výpisu ukladá interné štruktúry jadra, zásobníky volaní, kontext procesov a načítané ovládače . Vďaka tomu je možné po katastrofe vykonať analýzu post mortem, ktorá je veľmi podobná ladeniu živého systému, ale bez tlaku z nutnosti dotýkať sa produkčného stroja počas jeho zlyhania.

Dôvody na hlboké skúmanie výpisov jadra sú rôzne: od ladenia zdanlivo náhodných chýb a občasných pádov až po skúmanie, či bol systém škodlivo manipulovaný alebo či pád mohol zanechať stopy citlivých informácií na disku.

Okrem úplných výpisov jadra existuje možnosť vytvorenia výpisov jednotlivých procesov (klasické výpisy jadra ), ktoré sú veľmi užitočné, keď chceme obmedziť problém na konkrétnu aplikáciu alebo skontrolovať vplyv na dôvernosť služby, ako je napríklad e-mailový alebo messagingový klient.

Typy výpisov pamäte v systéme Windows a ich užitočnosť

V systémoch Windows môže samotný operačný systém generovať rôzne typy výpisov, keď sa vyskytne chyba STOP. Každý typ obsahuje inú úroveň detailov, preto je dôležité vedieť, aký typ výpisu potrebujete v závislosti od problému a obmedzení miesta na disku.

Jedným z najbežnejších formátov v používateľských prostrediach a na mnohých serveroch je malý výpis pamäte (minidump)Je to ten, ktorý zaberá najmenej miesta a zvyčajne sa nachádza v %SystemRoot%\Minidumpso súbormi štýlu MiniMMDDYY-01.dmp.

Tento mini dump obsahuje veľmi špecifické, ale dôležité informácie: kód chyby STOP a jeho parametre , zoznam ovládačov načítaných v čase zlyhania, kontext procesora, ktorý sa zastavil (PRCB), kontexty príslušného procesu a vlákna (štruktúry EPROCESS a ETHREAD) a zásobník volaní režimu jadra daného vlákna.

Vďaka týmto základným štruktúram je aj s minidumpom často možné identifikovať, ktorý ovládač alebo modul spôsobuje pády, hoci nie vždy bude možné sledovať celú stopu, ak problém pochádza ďaleko od vlákna, ktoré bežalo v čase pádu, a dostupné kontextové informácie sú obmedzené.

Systém Windows dokáže tiež generovať výpisy pamäte jadra a oveľa väčšie úplné výpisy, ktoré obsahujú časti alebo celú fyzickú pamäť. Tieto sú obzvlášť užitočné pre nízkoúrovňovú analýzu, forenzné vyšetrovania a pokročilé ladenie ovládačov alebo samotného systému.

Konfigurácia a otvorenie výpisov pamäte v systéme Windows pomocou WinDbg a KD

Ak chcete využiť systémové výpisy v systéme Windows, prvým krokom je správne nakonfigurovať možnosti spustenia a obnovenia . V ovládacom paneli v rozšírených vlastnostiach systému si môžete vybrať typ výpisu, ktorý chcete vygenerovať v prípade zlyhania: napríklad „Malý výpis pamäte (256 KB)“ a cestu, kam sa uloží.

Systém tiež vyžaduje stránkovací súbor na zavádzacom zväzku s veľkosťou aspoň niekoľkých megabajtov na zápis výpisu. V moderných verziách systému Windows každé zlyhanie vytvorí nový súbor a v nakonfigurovanom priečinku sa uchováva história, čo umožňuje jednoduché prezeranie minulých incidentov.

Po vygenerovaní existuje niekoľko spôsobov, ako overiť správnosť výpisov. Klasickým nástrojom je Dumpchk.exe , ktorý umožňuje skontrolovať základnú integritu súboru a vytlačiť súhrnné informácie. Pre pokročilejšiu analýzu sa používajú nástroje na ladenie systému Windows vrátane WinDbg (grafické rozhranie) a KD (verzia pre príkazový riadok).

Po nainštalovaní ladiacieho balíka z webovej stránky spoločnosti Microsoft sa nástroje zvyčajne nachádzajú v priečinku, ako napríklad C:\Program Files\Debugging Tools for Windows . Odtiaľ môžete otvoriť príkazový riadok a načítať súbor s výpisom pomocou WinDbg alebo KD, pričom súbor zadáte pomocou parametra -z .

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

Cesta k symbolom môže ukazovať na server symbolov s lokálnym ukladaním do vyrovnávacej pamäte , napríklad:

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

Zatiaľ čo binárna cesta je zvyčajne niečo ako C:\Windows\I386 alebo priečinok, kam sme skopírovali spustiteľné súbory systému zodpovedajúce verzii, ktorá vygenerovala výpis. Toto je dôležité, pretože Minidumpy neobsahujú všetky binárne súbory, iba odkazy na ne, takže ladiaci program ich musí vedieť nájsť.

Základná analýza výpisu jadra v systéme Windows

Po načítaní výpisu pomocou WinDbg alebo KD je analýza výpisu jadra po havárii dosť podobná ladeniu po operácii. Prvý príkaz, ktorý spustí takmer každý, je `!analyze` , ktorý spustí automatickú analýzu a vygeneruje počiatočnú správu.

Príkaz !analyze -show ukazuje kód kontroly chýb a jeho parametreKým !analyze -v Vytvára oveľa podrobnejší výstup: podozrivý modul, zásobník volaní, kontextové informácie a v mnohých prípadoch aj návrhy možných príčin alebo diagnostických krokov.

Na doplnenie tejto analýzy príkaz .bugcheck opäť vypíše kód chyby a súvisiace parametre, ktoré je možné porovnať s referenčným kódom pre kontrolu chýb od spoločnosti Microsoft , aby sa zistil presný význam každej hodnoty a typické príčiny.

Príkaz lm N T (zoznam modulov) vám umožňuje vidieť Zoznam načítaných modulov s ich cestou, adresami a stavomToto pomáha potvrdiť, či sa ovládač identifikovaný automatickou analýzou skutočne nachádza v pamäti a akú má verziu. Tento zoznam je obzvlášť užitočný, keď máme podozrenie na ovládače alebo bezpečnostné komponenty tretích strán, ktoré interagujú s jadrom.

V prípade potreby môžeme zjednodušiť načítanie výpisov vytvorením dávkového súboru , ktorý prijme cestu k výpisu a spustí KD alebo WinDbg s príslušnými parametrami. Takto stačí napísať krátky príkaz, ktorý obsahuje iba umiestnenie súboru a skript sa postará o všetko ostatné.

Používanie WinDbg pre hlboké výpisy jadra

Pre výpisy pamäte v režime jadra ponúka WinDbg aj možnosť práce s viacerými súbormi a reláciami. Výpisy je možné otvoriť z príkazového riadku pomocou -z alebo z grafického rozhrania pomocou ponuky Súbor > Otvoriť výpis pamäte alebo klávesovej skratky Ctrl+D.

Ak je WinDbg už otvorený v pasívnom režime, jednoducho vyberte súbor v dialógovom okne „Otvoriť výpis z havárie“, zadajte cestu alebo prejdite na disk. Po načítaní môžete v určitých scenároch spustiť reláciu príkazom „g“ (Go) alebo priamo spustiť počiatočné príkazy analýzy.

Okrem klasickej !analyzeJe vhodné oboznámiť sa s sekcia s referenčnými pokynmi pre ladiaci príkazTáto časť popisuje všetky dostupné príkazy na čítanie vnútorných štruktúr, skúmanie pamäte, interpretáciu zásobníkov a mnoho ďalšieho. Mnohé z týchto techník sú použiteľné pre živé relácie aj offline výpisy.

WinDbg vám tiež umožňuje pracovať s viacero paralelných výpisovNa príkazovom riadku môžeme pridať viacero parametrov -z, za každým nasledovaným iným názvom súboru, alebo pridať nové ciele pomocou príkazu .opendumpLadenie viacerých cieľových umiestnení je užitočné na porovnávanie opakujúcich sa zlyhaní alebo reťazených incidentov.

V niektorých prostrediach sú pamäťové výpisy zabalené do súborov CAB, aby sa ušetrilo miesto alebo uľahčil prenos. WinDbg dokáže priamo otvoriť .cab s výpisom vo vnútri, pomocou -z aj s .opendumphoci bude čítať Extrahuje iba jeden z uložených súborov a neextrahuje ostatné súbory. to by mohlo ísť do toho istého balíka.

Výpisy z havárie v systémoch Unix a Linux: utilita, nástroje a požiadavky

V systémoch Unix a GNU/Linux je filozofia podobná, ale ekosystém nástrojov sa značne líši. Väčšina jadier podobných Unixu ponúka možnosť uložiť kópiu pamäte v prípade katastrofickej udalosti , čo je známe ako výpis jadra alebo výpis jadra pri havárii.

Hoci ich primárnym využitím zostáva vývoj jadra a ovládačov, tieto výpisy majú jasný bezpečnostný aspekt. Pád môže byť spôsobený programovacími chybami, ale aj neúspešnými škodlivými akciami, pokusmi o manipuláciu so systémovými komponentmi alebo nešikovne zneužitými súbehovými podmienkami.

V dobre nakonfigurovanom unixovom systéme sú denné pády nezvyčajné, ale keď k nim dôjde, je vhodné mať zavedenú infraštruktúru pre výpisy, ako napríklad Kdump, LKCD alebo iné riešenia , ktoré umožňujú zachytiť systémovú pamäť. Je však dôležité zvážiť diagnostickú hodnotu výpisu oproti riziku, že obsahuje vysoko citlivé údaje.

Jedným z najkomplexnejších a najpoužívanejších nástrojov pre tento typ analýzy v Linuxe je crash , pôvodne vyvinutý spoločnosťou Red Hat. Tento nástroj sa stal prakticky de facto štandardom na skúmanie výpisov jadra a tiež na analýzu bežiacich systémov.

Pád môže pôsobiť proti živej pamäti systému prostredníctvom /dev/mem alebo v Red Hat a odvodených distribúciách pomocou špecifického zariadenia /dev/crashNapriek tomu je bežnou praxou posielať do nástroja súbor s výpisom vygenerovaný mechanizmami, ako napríklad Kdump, súbor s výpisom údajov, Výpis z disku alebo architektúrne špecifické výpisy ako napríklad s390/s390x alebo xendump vo virtualizovaných prostrediach.

Úloha crash a dôležitosť vmlinux v Linuxe

Nástroj na prelomenie havárie bol čiastočne vytvorený na prekonanie obmedzení používania gdb priamo na /proc/kcoreOkrem iného môže byť prístup k tomuto pseudoobrazu pamäte obmedzený a navyše niektoré možnosti kompilácie jadra sťažujú správnu interpretáciu vnútorných štruktúr, ak máme iba komprimovaný spustiteľný binárny súbor.

Pre správne fungovanie funkcie crash sú potrebné dva kľúčové prvky: skompilovaný súbor vmlinux s ladiacimi symbolmi (zvyčajne s príznakmi ako -g) a samotný výpis jadra. Táto kombinácia umožňuje nástroju mapovať pamäťové adresy na funkcie, štruktúry a riadky kódu.

Je dôležité rozlišovať medzi vmlinux a vmlinuzNa väčšine systémov je viditeľný iba vmlinux, čo je komprimovaná, bootovateľná verzia jadra. Pád vyžaduje symbolicky dekomprimovaný vmlinux; bez neho pri pokuse o načítanie výpisu alebo /dev/mem Stretneme sa s chybami typu Nepodarilo sa nájsť spustené jadro – zadajte argument zoznamu názvov.

Hoci je možné manuálne extrahovať balík vmlinuz, tento proces nie je vždy jednoduchý a v praxi je často oveľa pohodlnejšie prekompilovať jadro, aby sa súčasne získali balíky vmlinux aj vmlinuz. V serióznych administrátorských prostrediach je vhodné udržiavať samostatný balík vmlinuz pre každú nasadenú verziu jadra, a to špeciálne pre tieto situácie.

Keď sú požiadavky splnené, spustenie nástroja crash s výpisom je relatívne jednoduché: zadáte príslušný súbor vmlinux a výpis a nástroj otvorí interaktívnu reláciu, z ktorej môžete preskúmať štruktúry jadra, zobraziť procesy, zobraziť zásobníky volaní a extrahovať forenzné informácie . Tí, ktorí sa chcú ponoriť hlbšie do problematiky, môžu nahliadnuť do špecializovanej dokumentácie, ako napríklad do známeho technického dokumentu o crash.

Obmedzenia /dev/mem a prvé prístupy v Linuxe

Predtým, ako sa uchýlili ku konkrétnym nástrojom, sa mnohí správcovia historicky pokúšali získať výpis pamäte. čítanie priamo zo zariadenia /dev/memTento prístup sa zdal jednoduchý: použiť nástroj ako výpis pamäte (ktorý vypíše dané zariadenie do STDOUT) alebo stiahne z dd if=/dev/mem of=volcado.mem.

Moderné jadrá však ponúkajú možnosti kompilácie, ako napríklad CONFIG_STRICT_DEVMEMktoré výrazne obmedzujú prístup z používateľského priestoru do /dev/memTypickým výsledkom je, že čítanie sa preruší po malom bloku (napr. 1 MB) alebo v najhoršom prípade môže chyba v tejto interakcii skončiť... jadro paniky okamžitý a reštart stroja.

Táto ochrana dáva z bezpečnostného hľadiska dokonalý zmysel, ale núti nás hľadať iné spôsoby, ako získať spoľahlivý a kompletný výpis bez toho, aby sme sa museli úplne spoliehať na generické zariadenia, ktoré už nie sú také dostupné ako predtým.

Súčasným trendom je preto spoliehať sa na špecifické moduly alebo integrované infraštruktúry pre výpisy z pamäte, namiesto jednoduchého pokusu o „zoškrabanie pamäte“ pomocou nástrojov používateľského priestoru, ktoré nie sú navrhnuté tak, aby koexistovali s modernými politikami ochrany jadra.

LiME Forensics: Extrakcia pamäte v Linuxe a Androide

Veľmi silnou alternatívou vo svete forenznej analýzy je LiME (Linux Memory Extractor) , modul jadra navrhnutý presne na zachytávanie volatilnej pamäte kontrolovaným spôsobom a bez obmedzení, ktoré ovplyvňujú /dev/mem. LiME beží v priestore jadra, takže môže pristupovať k RAM oveľa priamejšie.

LiME sa distribuuje so zdrojovým kódom a kompiluje sa s ním. používané hlavičky jadraProces kompilácie generuje modul .ko špecifické pre verziu jadra, do ktorej sa načíta. Po kompilácii to môžeme overiť pomocou nástrojov ako napríklad file aby sa zabezpečilo, že modul ELF zodpovedajúci našej architektúre bol správne vygenerovaný.

Ak chcete použiť LiME, jednoducho načítajte modul pomocou insmod z koreňového adresára a odovzdať mu príslušné možnosti, napríklad zadaním cieľ sieťového výpisu pomocou TCP a RAW formátu:

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

Súbežne na počítači, ktorý bude prijímať výpis, počúvame nakonfigurovaný port pomocou nástroja ako ncpresmerovanie výstupu do súboru:

nc <IP_origen> 4444 > volcado.mem

Po niekoľkých minútach, v závislosti od množstva pamäte RAM a výkonu siete, budeme mať súbor, ktorého veľkosť zodpovedá fyzickej pamäti zdrojového systému. Ide o kompletný výpis pamäte RAM, ktorý môžeme analyzovať pomocou forenzných nástrojov alebo dokonca pomocou reťazcov či iných nástrojov ako prvý krok k nájdeniu zaujímavých reťazcov.

Riziká úniku údajov z procesov a ich spracovania

Úplný výpis jadra je mimoriadne informatívny, ale môže byť aj prehnaný, keď nás zaujíma iba konkrétny proces. V takom prípade má veľký zmysel uchýliť sa k... jednotlivé výpisy procesov pomocou nástrojov ako gcore v Unixe/Linuxe.

Tieto výpisy pre jednotlivé procesy sú oveľa menšie a lepšie spravovateľné a umožňujú vám zamerať sa na analýzu konkrétnych aplikácií, ako je napríklad klient na odosielanie správ (napr. Skype) alebo e-mailový klient (napr. Thunderbird), kde je relatívne jednoduché nájsť heslá v otvorenom texte, tokeny relácií alebo kontaktné údaje preskúmaním reťazcov pamäte.

Z vývojového hľadiska tieto výpisy základných dát pomáhajú lokalizovať programovacie chyby, úniky pamäte alebo nekonzistentné stavy v službe. Z bezpečnostného hľadiska však problém nastáva, keď sa tieto výpisy generujú pravidelne a ukladajú na miestach prístupných iným používateľom , či už v samotnom systéme alebo na zdieľaných sieťových zdrojoch.

Ak si používateľ naplánuje napríklad úlohu cron Pravidelným zaznamenávaním výpisov citlivých procesov a ich ponechávaním v globálne čitateľnom adresári útočník otvára obrovské dvere k odhaleniu kritických informácií. V mnohých scenároch auditu analýza týchto súborov umožňuje útočníkovi obnoviť prihlasovacie údaje, zoznamy kontaktov, história komunikácie a ďalšie súkromné ​​údaje s relatívne malým úsilím.

Preto je pri každom serióznom audite unixového systému vhodné venovať niekoľko minút kontrole, či sa generujú výpisy (úplné alebo čiastočné), kde sú uložené, aké majú povolenia a či existuje nejaký automatizovaný proces, ktorý ponecháva kópie pamäte v dosahu neoprávnených používateľov.

Postmortem analýza výpisov vo FreeBSD s kgdb

Vo svete BSD, a konkrétne vo FreeBSD, prístup k analýze po smrti zahŕňa Povoliť výpisy z núdze v systéme a mať jadro skompilované s ladiacimi symbolmiToto sa ovláda z konfiguračného adresára jadra, zvyčajne v /usr/src/sys/<arq>/conf.

V príslušnom konfiguračnom súbore je možné povoliť generovanie symbolov pomocou riadku, ako je tento:

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

Po úprave konfigurácie je potrebné jadro prekompilovať. Niektoré objekty budú regenerované (ako napríklad trap.o) kvôli zmene v súboroch zostavenia. Cieľom je získať jadro s rovnaký kód ako ten, ktorý má problémy, ale s pridaním potrebných ladiacích informáciíOdporúča sa porovnať staré a nové rozmery pomocou príkazu size aby sa zabezpečilo, že v binárnom súbore nedošlo k žiadnym neočakávaným zmenám.

Po nainštalovaní jadra so symbolmi môžeme preskúmať výpisy pomocou kgdb , ako je popísané v oficiálnej dokumentácii. Nie všetky symboly nemusia byť úplné a niektoré funkcie sa môžu zobraziť bez čísel riadkov alebo informácií o argumentoch, ale vo väčšine prípadov je úroveň detailov dostatočná na vysledovanie problému.

Neexistuje absolútna záruka, že analýza vyrieši všetky incidenty, ale v praxi táto stratégia funguje pomerne dobre vo vysokom percente scenárov , najmä keď sú výpisy po havárii kombinované s dobrým prehľadom nedávnych zmien v systéme.

Najlepšie postupy pre analýzu a dokumentovanie chýb jadra

Bez ohľadu na operačný systém sa analýza výpisu jadra zvyčajne odvoláva na technickú dokumentáciu, znalostné bázy, špecializované fóra alebo dokonca samotný zdrojový kód jadra na interpretáciu správ, chybových kódov a neznámych symbolov.

V Linuxe je veľmi užitočné spoliehať sa na oficiálny strom zdrojového kódu, vstavanú dokumentáciu a komunitné zdroje. Mnohé chybové hlásenia jadra možno vysledovať späť k presnému súboru, z ktorého pochádzajú, čo pomáha pochopiť kontext, v ktorom sa spúšťa konkrétna funkcia BUG() alebo WARN().

V systéme Windows poskytuje dokumentácia spoločnosti Microsoft, jej znalostná databáza (KB) a technické fóra podrobné vysvetlenia kódov kontroly chýb, odporúčania na riešenie problémov a známe vzory chýb . Kombinácia týchto informácií so správami z príkazu !analyze -v umožňuje vyvinúť rozumný plán na zmiernenie problémov.

Skutočná hodnota výpisu po havárii sa ukáže, keď sa všetky tieto informácie porovnajú s dôkladným pochopením operačného systému a konkrétneho prostredia, v ktorom k zlyhaniu došlo . Iba potom je možné vyvinúť trvalé riešenia a predovšetkým zabrániť opakovaniu rovnakého problému v budúcnosti s vážnejšími následkami.

Analýza výpisu jadra je v konečnom dôsledku zmesou vedy a remeselného spracovania: vyžaduje si vhodné nástroje, predchádzajúcu konfiguráciu (symboly, možnosti výpisu, bezpečné úložisko) a značné skúsenosti s čítaním zásobníkov, štruktúr a chybových kódov. Zvládnutie týchto techník nám umožňuje nielen ladiť zložité incidenty, ale aj dramaticky zvýšiť bezpečnosť a odolnosť systémov, ktoré spravujeme.