Анализа меморије и језгра на Windows и Unix системима

Информатек Дигитал » Средства » Анализа меморије и језгра на Windows и Unix системима

Када оперативни систем паничи или се спектакуларно сруши, једини начин да се разуме шта се догодило је да... дамп меморије језгра и накнадна анализаОви дампови бележе унутрашње стање система у тренутку квара и представљају сировину за отклањање сложених грешака, истраживање безбедносних инцидената или спровођење форензичких испитивања.

Иако може звучати веома „нискониво“, анализа дампа меморије није искључиво домена програмера кернела. Систем администратори, инжењери подршке, па чак и безбедносни ревизори могу имати користи од ње ако познају основе. одговарајући алати, врсте дампа и основне технике интерпретацијеПокрићемо цео овај пут у Windows-у, Unix/Linux-у и BSD-у, користећи алате као што су WinDbg, crash, kgdb и LiME.

Шта је дамп меморије језгра и зашто га вреди анализирати?

Дамп меморије језгра (често назван Дамп за слом језгра или једноставно дамп за слом система) је датотека која садржи копију, потпуну или делимичну, меморије у тренутку када систем претрпи критични квар, као што је кернел паниц у Јуниксу/Линуксу или плави екран смрти (BSOD) у Виндоусу.

У пракси, дамп ове врсте штеди унутрашње структуре језгра, стекови позива, контекст процеса и учитани драјвериЗахваљујући томе, након катастрофе може се извршити „пост-мортем“ анализа, веома слично отклањању грешака у живом систему, али без притиска додиривања производне машине док она отказује.

Разлози за дубинско истраживање дампова кернела су различити: од отклањање грешака од наизглед случајних грешака и повремених падова...чак и истраживање да ли је систем злонамерно манипулисан или да ли је пад система можда оставио трагове осетљивих информација на диску.

Поред комплетних дампова језгра, постоји могућност издвајања дампова појединачних процеса (класични изводи основних података), који су веома корисни када желимо да се проблем ограничи на одређену апликацију или да се прегледа утицај на поверљивост услуге као што је клијент за е-пошту или размену порука.

Врсте меморијских дампова у оперативном систему Windows и њихова корисност

На Windows системима, сам оперативни систем може да генерише различите врсте дампова када се догоди STOP грешка. Сваки тип укључује различит ниво детаља, тако да је кључно знати које користити. Која врста дампа нам је потребна на основу проблема и ограничења простора на диску?.

Један од најчешћих формата у корисничким окружењима и многим серверима је мали дамп меморије (минидамп)То је она која заузима најмање простора и обично се налази у %SystemRoot%\Minidump, са датотекама у стилу MiniMMDDYY-01.dmp.

Овај мини дамп садржи веома специфичне, али важне информације: Код грешке STOP и његови параметри, листа драјвера учитаних у тренутку квара, контекст процесора који је заустављен (PRCB), контексти процеса и укључене нити (структуре EPROCESS и ETHREAD) и стек позива у режиму језгра те нити.

Захваљујући овим основним структурама, чак и са мини-дампом је често могуће идентификовати који драјвер или модул узрокује падове система, иако неће увек бити могуће пратити цео проблем ако он потиче далеко од нити која је била покренута у тренутку пада система. Доступне контекстуалне информације су ограничене.

Виндоус такође може да генерише дампове меморије језгра и много веће комплетне дампове који садрже делове или целу физичку меморију. Ово је посебно корисно у анализа ниског нивоа, форензичка истраживања и напредно отклањање грешака у драјверима или самом систему.

Конфигуришите и отворите дампове меморије у оперативном систему Windows помоћу програма WinDbg и KD

Да бисте искористили предности дампова у оперативном систему Windows, прво је да правилно конфигуришете опције. покретање и опоравакИз контролне табле, у напредним системским својствима, можете изабрати врсту дампа који желите да генеришете у случају квара: на пример, „Мали дамп меморије (256 KB)“ и путању где ће бити сачуван.

Систему је такође потребан датотека страничне меморије на боот диску величине најмање неколико мегабајта да би се написао дамп. У модерним верзијама оперативног система Windows, сваки пад система креира нову датотеку, а историја се чува у конфигурисаној фасцикли, што омогућава лак преглед прошлих инцидената.

Једном генерисани, постоји неколико начина да се потврди да су дампови исправни. Један класичан алат је Датотека Dumpchk.exeшто вам омогућава да проверите основни интегритет датотеке и одштампате резиме информација. За напреднију анализу користе се следећи: Алати за отклањање грешака за Windowsкоји укључују WinDbg (графички интерфејс) и KD (верзија за командну линију).

Након инсталирања пакета за отклањање грешака са Мајкрософтове веб странице, алати се обично налазе у фасцикли као што је C:\Program Files\Dubbing Tools for WindowsОдатле можемо отворити командну линију и учитати дамп са WinDbg или KD користећи параметр -z да бисте навели датотеку:

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

Путања симбола може указивати на сервер симбола са локалним кешом, на пример:

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

Иако је бинарна путања обично нешто попут C:\Windows\I386 или фасциклу у коју смо копирали системске извршне датотеке које одговарају верзији која је генерисала дамп. Ово је важно јер Мини-дампови не укључују све бинарне датотеке, само референце на њих, тако да дебагер мора бити у стању да их пронађе.

Основна анализа дампа кернела у систему Windows

Када се дамп учита помоћу WinDbg-а или KD-а, анализа дампа језгра након пада система је прилично слична сесији отклањања грешака након смрти. Прва команда коју скоро сви покрећу је анализирај, што покреће аутоматску анализу и генерише почетни извештај.

Команда !analyze -show показати код за проверу грешака и његови параметриДок !analyze -v Производи много детаљнији излаз: сумњиви модул, стек позива, контекстуалне информације и, у многим случајевима, предлоге о могућим узроцима или дијагностичким корацима.

Да би се допунила та анализа, команда .провера грешака Поново штампа код грешке и повезане параметре, који се затим могу упоредити са референца кода за проверу грешака од компаније Microsoft да бисте сазнали тачно значење сваке вредности и типичне узроке.

Команда lm N T (листа модула) вам омогућава да видите Листа учитаних модула са њиховом путањом, адресама и статусомОво помаже да се потврди да ли се драјвер који је идентификовала аутоматизована анализа заиста налази у меморији и која је његова верзија. Ова листа је посебно корисна када сумњамо на драјвере или безбедносне компоненте трећих страна које интерагују са језгром.

По жељи, можемо поједноставити процес утовара креирањем пакетна датотека Добија путању до дампа и покреће KD или WinDbg са одговарајућим параметрима. На овај начин, потребно је само да напишете кратку команду која укључује локацију датотеке, а скрипта се брине о свему осталом.

Коришћење WinDbg-а за дубоке дампове језгра

За дампове меморије у режиму језгра, WinDbg такође нуди могућност рада са више датотека и сесија. Дампови се могу отворити из командне линије помоћу -zили из графичког интерфејса, користећи мени Датотека > Отвори извод меморије или пречицу на тастатури Цтрл + Д.

Ако је WinDbg већ отворен у пасивном режиму, једноставно изаберите датотеку у дијалошком оквиру „Отвори дамп грешке“, наводећи путању или прегледајући диск. Након учитавања, можемо покренути сесију командом г (Иди) у одређеним сценаријима или директно покренути прве команде за анализу.

Поред класичног !analyzeПрепоручљиво је упознати се са одељак са референцама за команде за отклањање грешакаОвде су описане све доступне команде за читање унутрашњих структура, испитивање меморије, тумачење стекова и још много тога. Многе од ових техника су применљиве и на сесије уживо и на офлајн дампове.

WinDbg вам такође омогућава рад са више паралелних дамповаМожемо додати више параметара -z у командној линији, сваки праћен различитим именом датотеке, или додати нове циљеве помоћу команде .opendumpОтклањање грешака на више одредишта је корисно за поређење понављајућих кварова или уланчаних инцидената.

У неким окружењима, дампови меморије се пакују у CAB датотеке ради уштеде простора или олакшавања преноса. WinDbg може директно да отвори .cab са дампом унутра, и користећи -z и са .opendumpиако ће читати Издвојиће само једну од копираних датотека и неће издвојити друге датотеке. то би могло да иде у исти пакет.

Изводи за избацивање система из система у Јуниксу и Линуксу: услужни програми, алати и захтеви

У Јуниксу и ГНУ/Линукс системима, филозофија је слична, али се екосистем алата знатно разликује. Већина Јуникс-сличних језгара нуди могућност сачувајте копију меморије када се догоди катастрофални догађај, оно што знамо као извод основног садржаја или дамп језгра при крешу.

Иако је њихова примарна употреба развој језгра и драјвера, ови дампови имају јасан безбедносни аспект. Пад система може бити узрокован... програмске грешке, али и злонамерне радње неуспешни покушаји манипулације системским компонентама или неспретно искоришћени услови трке.

У добро конфигурисаном Јуникс систему, свакодневни падови система нису чести, али када се догоде, паметно је имати резервни план. инфраструктура за одлагање података као што су Kdump, LKCD или друга решења који омогућавају снимање системске меморије. Међутим, потребно је проценити и дијагностичку вредност дампа и ризик да он садржи веома осетљиве податке.

Један од најкомплетнијих и најраспрострањенијих алата за ову врсту анализе у Линуксу је сударПрвобитно развијен од стране Ред Хет-а, овај услужни програм је постао де факто стандард за испитивање дампова кернела и анализу покренутих система.

Пад система може да утиче на живу меморију система кроз /dev/mem или, у Red Hat-у и деривативним дистрибуцијама, коришћењем одређеног уређаја /dev/crashУпркос томе, уобичајена је пракса да се алату дода датотека за избацивање података коју генеришу механизми као што су Кдумп, makedumpfile, Дамп диска или архитектурно специфичне дампове као што су s390/s390x или xendump у виртуелизованим окружењима.

Улога пада програма и значај vmlinux-а у Линуксу

Услужни програм за сузбијање грешака је делимично креиран да би се превазишла ограничења коришћења gdb директно на /proc/kcoreИзмеђу осталог, приступ тој псеудо-слици меморије може бити ограничен, а поред тога, одређене опције компајлирања језгра отежавају правилно тумачење унутрашњих структура ако имамо само компресовани извршни бинарни фајл.

Да би систем крешања исправно функционисао, неопходна су два кључна елемента: ​​a vmlinux датотека компајлирана са симболима за дебаговање (обично са заставицама попут -g) и самим дампом језгра. Ова комбинација омогућава алату да мапира меморијске адресе на функције, структуре и линије кода.

Важно је разликовати vmlinux и vmlinuzНа већини система, видљив је само vmlinux, што је компресована, покретна верзија језгра. За пад система потребан је симболички декомпресовани vmlinux; без њега, при покушају учитавања дампа или /dev/mem Наићи ћемо на грешке типа Не могу да пронађем покренуто језгро — унесите аргумент листе имена.

Иако је могуће ручно декомпресовати vmlinuz, процес није увек тривијалан и, у пракси, обично је много практичнији. Поново компајлирајте језгро да бисте добили и vmlinux и vmlinuz паралелно. У озбиљним административним окружењима, добра је пракса одржавати vmlinux који одговара свакој верзији језгра имплементираној управо за ове случајеве.

Када се испуне захтеви, рушење дампа је релативно једноставно: наведете одговарајући vmlinux и дамп датотеку, а алат отвара интерактивну сесију из које можете прегледати структуре језгра, навести процесе, прегледати стекове позива и издвојити форензичке информацијеОни који желе да се још дубље позабаве могу консултовати специјализовану документацију, као што је добро познати технички извештај о падовима система.

Ограничења /dev/mem и први приступи у Линуксу

Пре него што су прибегли одређеним алатима, многи администратори су историјски покушавали да добију дамп меморије. читање директно са уређаја /dev/memОвај приступ је изгледао једноставно: користите алат као што је мемдамп (што пребацује тај уређај на STDOUT) или извлачи из dd if=/dev/mem of=volcado.mem.

Међутим, модерна језгра нуде опције компајлирања као што су CONFIG_STRICT_DEVMEMкоји озбиљно ограничавају приступ из корисничког простора до /dev/memТипичан резултат је да се читање прекида након малог блока (нпр. 1 MB) или, у најгорем случају, грешка у тој интеракцији може завршити кернел паниц тренутно и поновно покретање машине.

Ова заштита је сасвим разумљива са становишта безбедности, али нас тера да тражимо Други начини за добијање поузданог и комплетног дампа без потпуног ослањања на генеричке уређаје који више нису толико доступни као раније.

Стога је тренутни тренд ослањање на специфичне модуле или интегрисане инфраструктуре за прикупљање података о паду система, уместо једноставног покушаја „стругања меморије“ алатима корисничког простора који нису дизајнирани да коегзистирају са модерним политикама заштите језгра.

LiME Forensics: Екстракција меморије у Linux-у и Android-у

Веома моћна алтернатива у свету форензике је LiME (Linux екстрактор меморије)LiME је модул језгра дизајниран посебно за контролисано хватање испарљиве меморије и без ограничења која утичу на /dev/mem. LiME ради у простору језгра, тако да може много директније да приступи RAM меморији.

LiME се дистрибуира са својим изворним кодом и компајлира се у односу на заглавља кернела у употребиПроцес компајлирања генерише модул .ko специфично за верзију језгра у коју ће бити учитано. Након компајлирања, можемо га проверити алатима као што су file како би се осигурало да је ELF модул који одговара нашој архитектури исправно генерисан.

Да бисте користили LiME, једноставно учитајте модул са insmod из корена и проследите му одговарајуће опције, на пример, навођењем одредиште мрежног дампа користећи TCP и сирови формат:

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

Паралелно, на машини која ће примити дамп, слушамо на конфигурисаном порту користећи алатку као што је ncпреусмеравање излаза у датотеку:

nc <IP_origen> 4444 > volcado.mem

После неколико минута, у зависности од количине РАМ меморије и перформанси мреже, имаћемо датотеку чија величина одговара физичкој меморији изворног система. Ово је комплетан дамп РАМ-а који можемо анализирати форензичким алатима или чак помоћу стрингова или других услужних програма као први корак ка проналажењу занимљивих ланаца.

Ризици од избацивања података процеса и излагања подацима

Комплетан дамп језгра је изузетно информативан, али може бити и претеран када нас занима само одређени процес. У том случају, има смисла прибећи... појединачне дампове процеса користећи алате попут gcore у Јуниксу/Линуксу.

Ови дампови по процесу су много мањи и лакши за управљање и омогућавају вам да фокусирате анализу на одређене апликације као што су клијент за размену порука (на пример, Skype) или клијент за е-пошту (као што је Thunderbird), где је релативно лако пронаћи лозинке у обичном тексту, токенима сесије или контакт подацима ако се истраже меморијски низови.

Са становишта развоја, ови основни дампови помажу у лоцирању програмских грешака, цурења меморије или недоследних стања у сервису. Али са становишта безбедности, проблем настаје када Дампови се генеришу рутински и чувају на локацијама доступним другим корисницима.било на самом систему или на дељеним мрежним ресурсима.

Ако корисник закаже, на пример, задатак cron Периодичним снимањем дампова осетљивих процеса и њиховим остављањем у глобално читљивом директоријуму, нападач отвара огромна врата за откривање критичних информација. У многим сценаријима ревизије, анализа ових датотека омогућава нападачу да се опорави акредитиви, листе контаката, историја комуникације и други приватни подаци са релативно малим напором.

Стога, у свакој озбиљној ревизији Јуникс система, препоручљиво је посветити неколико минута провери да ли се генеришу дампови (потпуни или делимични), где се чувају, које дозволе имају и да ли их има. аутоматизовани процес који оставља копије меморије доступним неовлашћеним корисницима.

Постмортална анализа дампова у FreeBSD-у са kgdb

У BSD свету, а посебно у FreeBSD-у, приступ анализи након смрти укључује Омогућите изводе из система и компајлирајте језгро са симболима за дебаговањеОво се контролише из директоријума за конфигурацију језгра, обично у /usr/src/sys/<arq>/conf.

У одговарајућој конфигурационој датотеци, генерисање симбола може се омогућити линијом попут ове:

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

Након измене конфигурације, језгро мора бити поново компајлирано. Неки објекти ће бити регенерисани (као што су trap.o) због промене у датотекама за изградњу. Циљ је добити језгро са исти код као онај који има проблема, али са додавањем потребних информација за отклањање грешакаПрепоручљиво је упоредити старе и нове величине помоћу команде size како би се осигурало да није било неочекиваних промена у бинарном фајлу.

Када се кернел инсталира помоћу симбола, сада можемо да прегледамо дампове помоћу кгдб као што је описано у званичној документацији. Нису сви симболи комплетни, а неке функције се могу појавити без бројева линија или информација о аргументима, али у већини случајева ниво детаља је довољан да се проблем пронађе.

Не постоји апсолутна гаранција да ће анализа решити све инциденте, али у пракси, Ова стратегија прилично добро функционише у великом проценту сценаријапосебно када се извештаји о паду система комбинују са добрим прегледом недавних системских промена.

Најбоље праксе за анализу и документовање грешака језгра

Без обзира на оперативни систем, анализа дампа језгра обично на крају доводи до техничка документација, базе знања, специјализовани форуми или чак сам изворни код језгра да тумачи поруке, кодове грешака и непознате симболе.

У Линуксу је веома корисно ослонити се на званично стабло изворног кода, уграђену документацију и ресурсе заједнице. Многе поруке о грешкама у језгру могу се пратити до тачне датотеке из које потичу, што помаже у разумевању проблема. контекст у коме се активира BUG() или WARN() одређена.

У оперативном систему Windows, Microsoft документација, његова база знања (KB) и технички форуми пружају детаљна објашњења о кодови за проверу грешака, препоруке за решавање и познати обрасци грешакаКомбиновањем тих информација са извештајима !analyze -v, могуће је направити разуман план за ублажавање.

Права вредност извештаја о паду система појављује се када се све те информације упореде са солидно познавање оперативног система и специфичног окружења у којем је дошло до квараСамо на тај начин могу се предложити трајна решења и, пре свега, спречити да се исти проблем понови у будућности са озбиљнијим последицама.

Анализа дампа меморије језгра је, у крајњој линији, мешавина науке и вештине: захтева одговарајуће алате, претходну конфигурацију (симболе, опције дампа, безбедно складиштење) и доста искуства у читању стекова, структура и кодова грешака. Савладавање ових техника вам омогућава не само да отклањате грешке у сложеним инцидентима, већ и да драстично повећамо ниво безбедности и отпорности система којима управљамо.