Mälutõmmise ja kerneli analüüs Windowsi ja Unixi süsteemides

Informatec Digital » Ressursid » Mälutõmmise ja kerneli analüüs Windowsi ja Unixi süsteemides

Kui operatsioonisüsteem satub paanikasse või krahhi, on ainus viis juhtunu mõistmiseks võtta kerneli mälutõmmis ja seda analüüsida . Need mälutõmmised jäädvustavad süsteemi sisemise oleku rikke hetkel ja on olulised keerukate vigade silumiseks, turvaintsidentide uurimiseks või kohtuekspertiisi tegemiseks.

Kuigi see võib tunduda väga "madala tasemega", ei ole mälutõmmiste analüüs ainult kerneli arendajate pärusmaa. Süsteemiadministraatorid, tugiinsenerid ja isegi turvaaudiitorid saavad sellest kasu, kui nad tunnevad õigeid tööriistu, erinevat tüüpi mälutõmmiseid ja põhilisi tõlgendamistehnikaid . Me juhendame teid kõiges selles Windowsi, Unixi/Linuxis ja BSD-s, kasutades selliseid tööriistu nagu WinDbg, crash, kgdb ja LiME.

Mis on kerneli mälutõmmis ja miks seda tasub analüüsida?

Kerneli mälutõmmis (sageli nimetatakse seda kerneli krahhitõmmiseks või lihtsalt krahhitõmmiseks ) on fail, mis sisaldab mälu täielikku või osalist koopiat ajal, mil süsteemis toimub kriitiline tõrge, näiteks kerneli paanika Unixis/Linuxis või sinine surmaekraan (BSOD) Windowsis.

Praktikas salvestab seda tüüpi mälutõmmis sisemised kerneli struktuurid, väljakutsete pinud, protsessi konteksti ja laaditud draiverid . Tänu sellele saab pärast katastroofi teha post mortem analüüsi, mis on väga sarnane reaalajas süsteemi silumisega, kuid ilma surveta puutuda rikke ajal tootmismasinat.

Kerneli prügimägede põhjaliku uurimise põhjused on mitmekesised: alates pealtnäha juhuslike vigade ja vahelduvate krahhide silumisest kuni uurimiseni, kas süsteemi on pahatahtlikult manipuleeritud või kas krahh võis kettale tundliku teabe jälgi jätta.

Lisaks täielikele põhiandmete prügimägedele on võimalik teha ka üksikute protsesside prügimägesid (klassikalised põhiandmete prügimäed ), mis on väga kasulikud, kui soovime probleemi piirata konkreetse rakendusega või kontrollida selle mõju teenuse, näiteks e-posti või sõnumside kliendi konfidentsiaalsusele.

Mälutõmmiste tüübid Windowsis ja nende kasulikkus

Windowsi süsteemides võib operatsioonisüsteem ise STOP-vea ilmnemisel genereerida erinevat tüüpi mälutõmmiseid. Igal tüübil on erinev detailsuse tase, seega on oluline teada, millist tüüpi mälutõmmist vajate, olenevalt probleemist ja kettaruumi piirangutest.

Üks levinumaid vorminguid kasutajakeskkondades ja paljudes serverites on väike mälutõmmis (minidump)See võtab kõige vähem ruumi ja asub tavaliselt %SystemRoot%\Minidump, stiilis failidega MiniKKPPAA-01.dmp.

See miniväljavõte sisaldab väga spetsiifilist, kuid olulist teavet: STOP-veakoodi ja selle parameetreid , tõrke ajal laaditud draiverite loendit, peatunud protsessori konteksti (PRCB), kaasatud protsessi ja lõime kontekste (EPROCESS ja ETHREAD struktuurid) ning selle lõime kerneli režiimi väljakutsete pinu.

Tänu neile põhistruktuuridele on isegi minidumpi abil sageli võimalik tuvastada, milline draiver või moodul krahhe põhjustab, kuigi kogu rada ei ole alati võimalik jälgida, kui probleem pärineb kaugelt krahhi ajal töötavast lõimest ja saadaolev kontekstiteave on piiratud.

Windows saab genereerida ka kerneli mälutõmmiseid ja palju suuremaid täistõmmiseid, mis sisaldavad kogu füüsilist mälu või selle osi. Need on eriti kasulikud madala taseme analüüsiks, kohtuekspertiisiks ja draiverite või süsteemi enda täpsemaks silumiseks.

Mälutõmmiste seadistamine ja avamine Windowsis WinDbg ja KD abil

Windowsi süsteemitõmmiste kasutamiseks on esimene samm käivitus- ja taastevalikute õige konfigureerimine . Juhtpaneeli täpsemate süsteemiomaduste alt saate valida tõrke korral genereeritava mälutõmmise tüübi: näiteks „Väike mälutõmmis (256 KB)” ja tee, kuhu see salvestatakse.

Süsteem vajab ka vähemalt mõne megabaidise suurusega lehekülgimisfaili alglaadimiskettal , et prügimäge kirjutada. Windowsi tänapäevastes versioonides loob iga krahh uue faili ja konfigureeritud kausta salvestatakse ajalugu, mis võimaldab varasemaid juhtumeid hõlpsalt üle vaadata.

Kui mälutõmmised on genereeritud, on nende õigsuse kontrollimiseks mitu võimalust. Klassikaline utiliit on Dumpchk.exe , mis võimaldab kontrollida faili põhilist terviklikkust ja printida kokkuvõtlikku teavet. Täpsemaks analüüsiks kasutatakse Windowsi silumistööriistu , sealhulgas WinDbg (graafiline liides) ja KD (käsurea versioon).

Pärast Microsofti veebisaidilt silumispaketi installimist asuvad tööriistad tavaliselt kaustas, näiteks C:\Program Files\Debugging Tools for Windows . Sealt saate avada käsuviiba ja laadida WinDbg või KD abil mälutõmmisefaili , määrates faili parameetriga -z .

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

Sümbolitee võib viidata sümboliserverile, millel on kohalik vahemälu , näiteks:

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

Kuigi binaartee on tavaliselt midagi sellist C:\Windows\I386 või kaust, kuhu oleme kopeerinud süsteemi käivitatavad failid, mis vastavad versioonile, mis genereeris prügimäe. See on oluline, sest Minidump-failid ei sisalda kõiki binaarfaile, ainult viiteid neile, seega peab silur suutma need leida.

Windowsi kerneli krahhi mälutõmmise põhianalüüs

Kui mälutõmmis on WinDbg või KD abil laaditud, on kerneli krahhi mälutõmmise analüüsimine üsna sarnane pärast surma tehtava veaotsingu seansiga. Esimene käsk, mida peaaegu kõik käivitavad, on `!analyze` , mis käivitab automaatse analüüsi ja genereerib esialgse aruande.

Käsk !analyze -show näitab veakontrolli kood ja selle parameetridKuigi !analyze -v See annab palju detailsema väljundi: kahtlase mooduli, väljakutsete pinu, kontekstuaalse teabe ja paljudel juhtudel ka soovitused võimalike põhjuste või diagnostiliste sammude kohta.

Selle analüüsi täiendamiseks prindib käsk .bugcheck uuesti veakoodi ja sellega seotud parameetrid, mida saab võrrelda Microsofti veakontrolli koodi viitega, et leida iga väärtuse täpne tähendus ja tüüpilised põhjused.

Käsk lm N T (moodulite loend) võimaldab teil näha Laaditud moodulite loend koos nende tee, aadresside ja olekugaSee aitab kinnitada, kas automaatse analüüsi abil tuvastatud draiver on tegelikult mälus ja milline on selle versioon. See loend on eriti kasulik, kui kahtlustame kolmanda osapoole draivereid või turvakomponente, mis kerneliga suhtlevad.

Soovi korral saame prügimägede laadimist lihtsustada, luues pakkfaili , mis saab prügimäe tee ja käivitab KD või WinDbg sobivate parameetritega. Nii peame kirjutama vaid lühikese käsu, mis sisaldab ainult faili asukohta, ja skript hoolitseb kõige muu eest.

WinDbg kasutamine sügavate kerneli prügimägede jaoks

Kerneli režiimi mälutõmmiste jaoks pakub WinDbg ka võimalust töötada mitme faili ja seansiga. Mälutõmmiseid saab avada käsurealt valikuga -z või graafilisest liidesest menüükäsuga Fail > Ava mälutõmmis või kiirklahvikombinatsiooniga Ctrl+D.

Kui WinDbg on juba passiivses režiimis avatud, valige lihtsalt fail dialoogiboksis „Ava krahhi mälutõmmis”, määrates tee või sirvides ketast. Pärast laadimist saate teatud olukordades seansi alustada käsuga „g” (Mine) või käivitada otse esialgsed analüüsikäsud.

Lisaks klassikale !analyzeSoovitav on tutvuda siluri käskude viiteosaSee kirjeldab kõiki saadaolevaid käske sisemiste struktuuride lugemiseks, mälu uurimiseks, pinude tõlgendamiseks ja paljuks muuks. Paljusid neist tehnikatest saab rakendada nii reaalajas seansside kui ka võrguühenduseta prügimägede puhul.

WinDbg võimaldab teil töötada ka mitu paralleelset prügimägeKäsureale saame lisada mitu -z parameetrit, millele järgneb igaühele erinev failinimi, või lisada uusi sihtmärke käsuga .opendumpMitme sihtkoha silumine on kasulik korduvate tõrgete või aheldatud intsidentide võrdlemiseks.

Mõnes keskkonnas pakitakse mälutõmmised CAB-failidesse ruumi kokkuhoiuks või edastamise hõlbustamiseks. WinDbg saab otse avada .cab koos sees oleva prügimäega, kasutades nii -z kui ka koos .opendumpkuigi ta loeb See ekstraheerib ainult ühe tühjendatud failidest ja ei ekstraheeri teisi faile. mis võiks samasse paketti minna.

Unixis ja Linuxis tehtud krahhitõmmised: utiliit, tööriistad ja nõuded

Unixi ja GNU/Linuxi süsteemides on filosoofia sarnane, kuid tööriistade ökosüsteem erineb märkimisväärselt. Enamik Unixi-laadseid kerneleid pakub võimalust salvestada mälu koopia katastroofilise sündmuse korral , mida tuntakse tuumatõmmisena või kerneli krahhitõmmisena.

Kuigi nende peamine kasutusala on endiselt kerneli ja draiverite arendamine, on neil selge turvalisuse aspekt. Krahhi võivad põhjustada programmeerimisvead, aga ka ebaõnnestunud pahatahtlikud toimingud, katsed süsteemikomponente manipuleerida või kohmakalt ära kasutatud võidujooksutingimused.

Hästi konfigureeritud Unixi süsteemis on igapäevased krahhid haruldased, kuid kui need siiski esinevad, on soovitatav omada mälutõmmise taristut, näiteks Kdump, LKCD või muid lahendusi , mis võimaldavad süsteemimälu hõivata. Siiski on oluline kaaluda nii mälutõmmise diagnostilist väärtust kui ka selle väga tundlike andmete sisaldamise ohtu.

Üks ulatuslikumaid ja laialdasemalt kasutatavaid tööriistu seda tüüpi analüüsiks Linuxis on crash , mille töötas algselt välja Red Hat. Sellest utiliidist on saanud praktiliselt de facto standard kerneli prügimägede uurimiseks ja ka töötavate süsteemide analüüsimiseks.

Krahh võib süsteemi reaalajas mälu vastu töötada järgmiste toimingute kaudu: /dev/mem või Red Hati ja tuletatud distributsioonides, kasutades konkreetset seadet /dev/crashSellegipoolest on tavaks tööriistale varustada mälutõmmise fail, mille on genereerinud sellised mehhanismid nagu Kdump, makedumpfile, Diskdump või arhitektuuripõhised prügimäed, näiteks s390/s390x või xendump virtualiseeritud keskkondades.

Krahhi roll ja vmlinuxi tähtsus Linuxis

Krahhi utiliit loodi osaliselt selleks, et ületada kasutamise piirangud gdb otse peal /proc/kcoreMuuhulgas võib juurdepääs sellele mälu pseudokujutisele olla piiratud ja lisaks raskendavad teatud kerneli kompileerimisvalikud sisemiste struktuuride korrektset tõlgendamist, kui meil on ainult tihendatud käivitatav binaarfail.

Selleks, et krahh korrektselt toimiks, on vaja kahte põhielementi: kompileeritud vmlinuxi faili silumissümbolitega (tavaliselt lippudega nagu -g) ja kerneli mälutõmmist ennast. See kombinatsioon võimaldab tööriistal kaardistada mäluaadressid funktsioonide, struktuuride ja koodiridadega.

Oluline on vahet teha vmlinux ja vmlinuzEnamikus süsteemides on nähtav ainult vmlinux, mis on kerneli tihendatud ja käivitatav versioon. Krahhi korral on vaja sümboolselt lahti pakitud vmlinuxit; ilma selleta, näiteks mälutõmmise laadimisel või /dev/mem Me kohtame tüüpi vigu Käivitatavat kerneli ei leitud — palun sisestage namelist argument.

Kuigi vmlinuzi on võimalik käsitsi lahti pakkida, pole see protsess alati lihtne ja praktikas on sageli palju mugavam kernel uuesti kompileerida, et saada korraga nii vmlinux kui ka vmlinuz. Tõsistes administratiivkeskkondades on hea tava hallata iga juurutatud kerneli versiooni jaoks eraldi vmlinuz paketti just selliste olukordade jaoks.

Kui nõuded on täidetud, on krahhi käivitamine mälutõmmise vastu suhteliselt lihtne: määrate sobiva vmlinuxi ja mälutõmmise faili ning tööriist avab interaktiivse seansi, mille kaudu saate uurida kerneli struktuure, loetleda protsesse, vaadata väljakutsete pinu ja ammutada kohtuekspertiisi teavet . Need, kes soovivad süveneda, saavad tutvuda spetsiaalse dokumentatsiooniga, näiteks tuntud krahhide tehnilise valge raamatuga.

/dev/mem piirangud ja esimesed lähenemisviisid Linuxis

Enne konkreetsete tööriistade kasutamist on paljud administraatorid ajalooliselt püüdnud mälutõmmist hankida. otse seadmest lugemine /dev/memSee lähenemisviis tundus lihtne: kasutage tööriista nagu mälutõmmis (mis saadab seadme standardväljundisse) või tõmbab selle välja dd if=/dev/mem of=volcado.mem.

Kuid tänapäevased tuumad pakuvad kompileerimisvõimalusi, näiteks CONFIG_STRICT_DEVMEMmis piirab oluliselt juurdepääsu kasutajaruumist /dev/memTüüpiline tulemus on see, et lugemine katkeb pärast väikest plokki (nt 1 MB) või halvimal juhul võib selle interaktsiooni viga lõppeda ... tuuma paanika kohene ja masina taaskäivitamine.

See kaitse on turvalisuse seisukohast täiesti mõistlik, kuid see sunnib meid otsima teisi viise usaldusväärse ja täieliku prügimäe saamiseks, ilma et peaksime täielikult lootma geneerilistele seadmetele, mis pole enam nii ligipääsetavad kui varem.

Seega on praegune trend toetuda spetsiifilistele moodulitele või integreeritud krahhitõmmiste infrastruktuurile, selle asemel, et lihtsalt proovida mälu "kraapida" kasutajaruumi tööriistadega, mis ei ole loodud kaasaegsete kerneli kaitsepoliitikatega koos eksisteerima.

LiME kohtuekspertiis: mälu ekstraheerimine Linuxis ja Androidis

Kohtuekspertiisi maailmas on väga võimas alternatiiv LiME (Linux Memory Extractor) , kerneli moodul, mis on loodud täpselt volatiilse mälu kontrollitud viisil ja ilma /dev/mem mõjutavate piiranguteta jäädvustamiseks. LiME töötab kerneli ruumis, seega pääseb see RAM-ile palju otsesemalt ligi.

LiME levitatakse koos lähtekoodiga ja kompileeritakse selle vastu. kasutusel olevad kerneli päisedKompileerimisprotsess genereerib mooduli .ko spetsiifiline kerneli versioonile, kuhu see laaditakse. Pärast kompileerimist saame seda kontrollida selliste tööriistadega nagu file et veenduda meie arhitektuurile vastava ELF-mooduli korrektses genereerimises.

LiME kasutamiseks laadige moodul lihtsalt insmod root'ilt ja edastage sellele sobivad valikud, näiteks määrates a võrgu prügimäe sihtkoht TCP ja toorvormingu abil:

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

Paralleelselt kuulame prügimäe vastuvõtval masinal konfigureeritud porti, kasutades sellist tööriista nagu ncväljundi ümbersuunamine faili:

nc <IP_origen> 4444 > volcado.mem

Mõne minuti pärast, olenevalt muutmälu hulgast ja võrgu jõudlusest, on meil fail, mille suurus vastab lähtekoodisüsteemi füüsilisele mälule. See on täielik muutmälu mälutõmmis, mida saame analüüsida kohtuekspertiisi tööriistade või isegi stringide või muude utiliitidega esimese sammuna huvitavate stringide leidmiseks.

Protsessi prügimäed ja andmetega kokkupuute riskid

Täielik kerneli mälutõmmis on äärmiselt informatiivne, kuid see võib olla ka liigne, kui meid huvitab ainult konkreetne protsess. Sellisel juhul on väga mõistlik pöörduda ... poole. üksikute protsesside prügimäed kasutades selliseid tööriistu nagu gcore Unixis/Linuxis.

Need protsessipõhised prügimäed on palju väiksemad ja paremini hallatavad ning võimaldavad teil oma analüüsi keskenduda konkreetsetele rakendustele, näiteks sõnumsidekliendile (nt Skype) või e-posti kliendile (nt Thunderbird), kus on mälustringide uurimise abil suhteliselt lihtne leida lihtteksti paroole, seansi märke või kontaktandmeid .

Arenduse seisukohast aitavad need põhimäluprügimähised leida programmeerimisvigu, mälulekkeid või teenuse ebajärjekindlaid olekuid. Turvalisuse seisukohast tekib probleem aga siis, kui neid mäluprügimähkleid genereeritakse rutiinselt ja salvestatakse teistele kasutajatele ligipääsetavatesse kohtadesse kas süsteemis endas või jagatud võrguressurssides.

Kui kasutaja näiteks ajastab ülesande cron Tundlike protsesside perioodiliste andmete jäädvustamise ja nende globaalselt loetavasse kataloogi jätmisega avab ründaja tohutu ukse kriitilise teabe avalikustamiseks. Paljudes auditistsenaariumides võimaldab nende failide analüüsimine ründajal taastada volitused, kontaktide nimekirjad, suhtlusajalugu ja muud privaatsed andmed suhteliselt väikese pingutusega.

Seetõttu on iga tõsise Unixi süsteemi auditi puhul soovitatav pühendada paar minutit sellele, et kontrollida, kas mälutõmmiseid (täielikke või osalisi) genereeritakse, kus neid hoitakse, millised õigused neil on ja kas on olemas automatiseeritud protsess, mis jätab mälukoopiad volitamata kasutajate kätte.

FreeBSD-s tehtud prügimägede lahkamine kgdb abil

BSD maailmas ja eriti FreeBSD-s hõlmab post mortem analüüsi lähenemisviis järgmist: Luba süsteemis krahhitõmmised ja lase kernelil kompileerida silumissümbolitegaSeda juhitakse kerneli konfiguratsioonikataloogist, mis tavaliselt asub /usr/src/sys/<arq>/conf.

Vastavas konfiguratsioonifailis saab sümbolite genereerimise lubada sellise reaga:

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

Pärast konfiguratsiooni muutmist tuleb kernel uuesti kompileerida. Mõned objektid genereeritakse uuesti (näiteks trap.o) ehitusfailide muutmise tõttu. Eesmärk on saada kernel, millel on sama kood kui see, millel on probleeme, aga lisades vajaliku silumisteabeSoovitav on võrrelda vanu ja uusi suurusi käsuga size veendumaks, et binaarfailis pole toimunud ootamatuid muutusi.

Kui sümbolitega kernel on installitud, saame prügimägesid kgdb abil uurida , nagu ametlikus dokumentatsioonis kirjeldatud. Kõik sümbolid ei pruugi olla täielikud ja mõned funktsioonid võivad ilmuda ilma reanumbrite või argumentideta, kuid enamasti on detailsuse tase probleemi jälgimiseks piisav.

Puudub absoluutne garantii, et analüüs lahendab kõik intsidendid, kuid praktikas toimib see strateegia üsna hästi suure osa stsenaariumide puhul , eriti kui krahhi mälutõmmised on kombineeritud süsteemi hiljutiste muudatuste põhjaliku ülevaatega.

Kerneli vigade analüüsimise ja dokumenteerimise parimad tavad

Olenemata operatsioonisüsteemist, viitab kerneli prügimäe analüüs tavaliselt tehnilisele dokumentatsioonile, teadmusbaasidele, spetsialiseeritud foorumitele või isegi kerneli lähtekoodile endale, et tõlgendada teateid, veakoode ja tundmatuid sümboleid.

Linuxis on väga kasulik toetuda ametlikule lähtekoodipuule, sisseehitatud dokumentatsioonile ja kogukonna ressurssidele. Paljude kerneli veateadete päritolu saab jälgida täpse failini, mis aitab mõista konteksti, milles konkreetne BUG() või WARN() käivitub.

Windowsis pakuvad Microsofti dokumentatsioon, selle teadmusbaas (KB) ja tehnilised foorumid üksikasjalikke selgitusi veakontrolli koodide, tõrkeotsingu soovituste ja teadaolevate veamustrite kohta . Selle teabe kombineerimine !analyze -v aruannetega võimaldab välja töötada mõistliku leevendusplaani.

Krahhi mälutõmmise tõeline väärtus ilmneb siis, kui kogu see teave on võrreldud operatsioonisüsteemi ja konkreetse keskkonna, kus tõrge tekkis, kindla arusaamaga . Alles siis saab välja töötada püsivaid lahendusi ja ennekõike vältida sama probleemi kordumist tulevikus koos tõsisemate tagajärgedega.

Kerneli mälutõmmise analüüs on lõppkokkuvõttes teaduse ja meisterlikkuse segu: see nõuab sobivaid tööriistu, eelnevat konfigureerimist (sümbolid, mälutõmmise valikud, turvaline salvestusruum) ja palju kogemusi pinude, struktuuride ja veakoodide lugemisel. Nende tehnikate valdamine võimaldab meil mitte ainult keerulisi intsidente siluda, vaid ka oluliselt suurendada hallatavate süsteemide turvalisust ja vastupidavust.