Дамп пам'яті та аналіз ядра в системах Windows та Unix

Інформатек Діджитал » Ресурси » Дамп пам'яті та аналіз ядра в системах Windows та Unix

Коли операційна система панікує або дає аварійний збій, єдиний спосіб зрозуміти, що сталося, це... дамп пам'яті ядра та подальший аналізЦі дампи фіксують внутрішній стан системи на момент збою та є сировиною для налагодження складних помилок, розслідування інцидентів безпеки або проведення судово-медичних експертиз.

Хоча це може здатися дуже «низькорівневим», аналіз дампа пам'яті не є виключною справою розробників ядра. Системні адміністратори, інженери підтримки та навіть аудитори безпеки можуть отримати від нього користь, якщо знають основи. відповідні інструменти, типи дампів та основні методи інтерпретаціїМи розглянемо весь цей шлях у Windows, Unix/Linux та BSD, використовуючи такі інструменти, як WinDbg, crash, kgdb та LiME.

Що таке дамп пам'яті ядра та чому його варто аналізувати?

Дамп пам'яті ядра (часто його називають Аварійний дамп ядра або просто аварійний дамп) — це файл, що містить копію, повну або часткову, пам'яті на момент критичного збою системи, такого як ядро паніки в Unix/Linux або синій екран смерті (BSOD) у Windows.

На практиці, дамп такого типу економить внутрішні структури ядра, стеки викликів, контекст процесу та завантажені драйвериЗавдяки цьому після катастрофи можна провести аналіз "посмертно", дуже схожий на налагодження робочої системи, але без тиску необхідності торкатися виробничої машини, коли вона виходить з ладу.

Причини для глибокого вивчення дампів ядра різноманітні: від налагодження, здавалося б, випадкових помилок та періодичних збоїв...навіть розслідування того, чи була система зловмисно маніпульована, чи збій міг залишити сліди конфіденційної інформації на диску.

Окрім повних дампів ядра, існує можливість вилучення дампів окремих процесів (класичний відвали керна), які дуже корисні, коли нам потрібно обмежити проблему певним застосуванням або переглянути вплив на конфіденційність послуги як-от клієнт електронної пошти або обміну повідомленнями.

Типи дампів пам'яті в Windows та їхня корисність

У системах Windows сама операційна система може генерувати різні типи дампів, коли виникає помилка STOP. Кожен тип має різний рівень деталізації, тому важливо знати, які з них використовувати. Який тип дампа нам потрібен, виходячи з проблеми та обмежень дискового простору?.

Один з найпоширеніших форматів у середовищах користувачів та на багатьох серверах – це малий дамп пам'яті (мінідамп)Це той, який займає найменше місця і зазвичай розташований у %SystemRoot%\Minidump, з файлами стилю МініММДДРР-01.dmp.

Цей міні-дамп містить дуже конкретну, але важливу інформацію: Код помилки STOP та її параметри, список драйверів, завантажених на момент збою, контекст процесора, що зупинився (PRCB), контексти процесу та потоку, що брали участь (структури EPROCESS та ETHREAD) та стек викликів режиму ядра цього потоку.

Завдяки цим базовим структурам, навіть за допомогою міні-дампа часто можна визначити, який драйвер або модуль спричиняє збої, хоча не завжди можна простежити всю проблему, якщо вона виникла далеко від потоку, який працював на момент збою. Доступна контекстуальна інформація обмежена.

Windows також може створювати дампи пам'яті ядра та набагато більші повні дампи, що містять частини або всю фізичну пам'ять. Вони особливо корисні в низькорівневий аналіз, судово-медичні розслідування та розширене налагодження драйверів або самої системи.

Налаштування та відкриття дампів пам'яті у Windows за допомогою WinDbg та KD

Щоб скористатися перевагами дампів у Windows, перш за все потрібно правильно налаштувати параметри. запуск та відновленняНа Панелі керування, в розширених властивостях системи, ви можете вибрати тип дампа, який потрібно створити у разі збою: наприклад, «Малий дамп пам’яті (256 КБ)» та шлях, де він буде збережений.

Системі також потрібна файл підкачки на завантажувальному томі розміром щонайменше кілька мегабайт для запису дампа. У сучасних версіях Windows кожен збій створює новий файл, а історія зберігається в налаштованій папці, що дозволяє легко переглядати минулі інциденти.

Після створення дампів існує кілька способів перевірити їх правильність. Один із класичних інструментів – це Dumpchk.exeщо дозволяє перевірити базову цілісність файлу та роздрукувати зведену інформацію. Для більш поглибленого аналізу використовуються такі методи: Інструменти налагодження для Windowsякі включають WinDbg (графічний інтерфейс) та KD (версія з командного рядка).

Після встановлення пакета налагодження з веб-сайту Microsoft, інструменти зазвичай знаходяться в папці типу C:\Program Files\Засоби налагодження для 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або з графічного інтерфейсу, використовуючи меню Файл > Відкрити дамп пам'яті чи комбінацію клавіш Ctrl + D.

Якщо WinDbg вже відкрито в пасивному режимі, просто виберіть файл у діалоговому вікні «Відкрити дамп аварійного завершення», вказавши шлях або переглянувши диск. Після завантаження ми можемо розпочати сеанс за допомогою команди g (Перейти) у певних сценаріях або безпосередньо запускати перші команди аналізу.

Крім класичних !analyzeБажано ознайомитися з розділ довідки про команди налагоджувачаТут описано всі доступні команди для читання внутрішніх структур, дослідження пам'яті, інтерпретації стеків та багато іншого. Багато з цих методів застосовні як до живих сесій, так і до автономних дампів.

WinDbg також дозволяє працювати з кілька паралельних дампівМи можемо додати кілька параметрів -z у командному рядку, кожен з яких має бути окремим іменем файлу, або додати нові цілі за допомогою команди .opendumpНалагодження кількох пунктів призначення корисне для порівняння повторюваних збоїв або ланцюгових інцидентів.

У деяких середовищах дампи пам'яті упаковуються в CAB-файли для економії місця або полегшення передачі. WinDbg може безпосередньо відкривати .cab з дампом всередині, як з використанням -z, так і з .opendumpхоча він читатиме Він витягне лише один із завантажених файлів і не витягне інші файли. що може йти в одному пакеті.

Збір даних про збій в Unix та Linux: утиліта, інструменти та вимоги

У системах Unix та GNU/Linux філософія схожа, але екосистема інструментів значно відрізняється. Більшість ядер, подібних до Unix, пропонують можливість зберегти копію пам'яті, коли трапляється катастрофічна подія, що ми знаємо як відвал ядра або дамп аварійного завершення роботи ядра.

Хоча їх основним призначенням залишається розробка ядра та драйверів, ці дампи мають чіткий аспект безпеки. Збій може бути спричинений помилки програмування, а також зловмисні дії невдалі спроби маніпулювати системними компонентами або невміле використання умов гонки.

У добре налаштованій системі Unix щоденні збої не є поширеним явищем, але коли вони трапляються, доцільно мати резервний план. інфраструктура для дампінгу, така як Kdump, LKCD або інші рішення що дозволяють захоплювати системну пам'ять. Однак необхідно зважити як діагностичну цінність дампа, так і ризик його вмісту висококонфіденційних даних.

Одним із найповніших та найпоширеніших інструментів для такого типу аналізу в Linux є аваріяСпочатку розроблена Red Hat, ця утиліта стала фактичним стандартом для перевірки дампів ядра та аналізу запущених систем.

Збій може працювати проти живої пам'яті системи через /dev/mem або, у Red Hat та похідних дистрибутивах, використовуючи певний пристрій /dev/crashНавіть попри це, поширеною практикою є передача інструменту файлу дампа, згенерованого такими механізмами, як Kdump, makedumpfile, Дамп диска або дампи, специфічні для архітектури, такі як s390/s390x або xendump у віртуалізованих середовищах.

Роль аварії та важливість vmlinux у Linux

Утиліту crash було створено, частково, для подолання обмежень використання gdb безпосередньо на /proc/kcoreСеред іншого, доступ до цього псевдообразу пам'яті може бути обмежений, а також, деякі параметри компіляції ядра ускладнюють правильну інтерпретацію внутрішніх структур, якщо у нас є лише стиснутий виконуваний бінарний файл.

Для коректної роботи аварії необхідні два ключові елементи: vmlinux-файл, скомпільований із символами налагодження (зазвичай з прапорцями, такими як -g) та сам дамп ядра. Ця комбінація дозволяє інструменту зіставляти адреси пам'яті з функціями, структурами та рядками коду.

Важливо розрізняти vmlinux та vmlinuzНа більшості систем видно лише vmlinux, який є стиснутою завантажувальною версією ядра. Для збою потрібен символічно розпакований vmlinux; без нього, під час спроби завантажити дамп або /dev/mem Ми зіткнемося з помилками типу не вдалося знайти завантажене ядро ​​— будь ласка, введіть аргумент списку імен.

Хоча розпакувати vmlinuz вручну можливо, цей процес не завжди тривіальний і на практиці зазвичай набагато зручніший. Перекомпілюйте ядро, щоб отримати як vmlinux, так і vmlinuz паралельно. У серйозних адміністративних середовищах гарною практикою є підтримка vmlinux, що відповідає кожній версії ядра, розгорнутій саме для цих випадків.

Після виконання вимог, збій дампу є відносно простим: ви вказуєте відповідний vmlinux та файл дампу, і інструмент відкриває інтерактивний сеанс, з якого ви можете переглядати структури ядра, перераховувати процеси, переглядати стеки викликів та витягувати судово-медичну інформаціюТі, хто бажає заглибитися ще глибше, можуть звернутися до спеціалізованої документації, такої як відомий технічний огляд аварій.

Обмеження /dev/mem та перші підходи в Linux

Перш ніж вдаватися до певних інструментів, багато адміністраторів традиційно намагалися отримати дамп пам'яті. читання безпосередньо з пристрою /dev/memЦей підхід здавався простим: використовувати такий інструмент, як memdump (що виводить дані пристрою на STDOUT) або витягує їх з dd if=/dev/mem of=volcado.mem.

Однак, сучасні ядра пропонують такі варіанти компіляції, як CONFIG_STRICT_DEVMEMякі суттєво обмежують доступ з простору користувача до /dev/memТиповим результатом є те, що читання переривається після невеликого блоку (наприклад, 1 МБ) або, в найгіршому випадку, помилка в цій взаємодії може призвести до ядро паніки негайний та перезапуск машини.

Цей захист має сенс з точки зору безпеки, але він змушує нас шукати Інші способи отримання надійного та повного дампа не покладаючись повністю на універсальні пристрої, які вже не такі доступні, як раніше.

Отже, сучасна тенденція полягає в тому, щоб покладатися на певні модулі або інтегровані інфраструктури аварійного дампа, замість того, щоб просто намагатися "очищати пам'ять" за допомогою інструментів простору користувача, які не призначені для співіснування із сучасними політиками захисту ядра.

LiME Forensics: Вилучення даних з пам'яті в Linux та Android

Дуже потужною альтернативою у світі криміналістики є LiME (вилучувач пам'яті Linux)LiME — це модуль ядра, спеціально розроблений для контрольованого захоплення енергозалежної пам'яті без обмежень, що впливають на /dev/mem. LiME працює в просторі ядра, тому він може набагато пряміше звертатися до оперативної пам'яті.

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 в Unix/Linux.

Ці дампи для кожного процесу набагато менші та зручніші для керування, і дозволяють зосередити аналіз на конкретних програмах, таких як клієнт обміну повідомленнями (наприклад, Skype) або поштовий клієнт (наприклад, Thunderbird), де відносно легко знайти паролі у звичайному тексті, токени сеансу або контактні дані якщо досліджуються рядки пам'яті.

З точки зору розробки, ці основні дампи допомагають знаходити помилки програмування, витоки пам'яті або невідповідні стани в сервісі. Але з точки зору безпеки проблема виникає, коли Дампи генеруються регулярно та зберігаються в місцях, доступних іншим користувачам.або на самій системі, або на спільних мережевих ресурсах.

Якщо користувач планує, наприклад, завдання cron Періодично захоплюючи дампи конфіденційних процесів та залишаючи їх у глобально доступному для читання каталозі, зловмисник відкриває величезні двері для розкриття критичної інформації. У багатьох сценаріях аудиту аналіз цих файлів дозволяє зловмиснику відновити облікові дані, списки контактів, історія спілкування та інші особисті дані з відносно невеликими зусиллями.

Тому під час будь-якого серйозного аудиту Unix-системи доцільно присвятити кілька хвилин перевірці того, чи генеруються дампи (повні чи часткові), де вони зберігаються, які у них є дозволи та чи є якісь. автоматизований процес, який залишає копії пам'яті доступними для неавторизованих користувачів.

Посмертний аналіз дампів у FreeBSD за допомогою kgdb

У світі BSD, і зокрема у FreeBSD, підхід до аналізу після смерті включає Увімкнути аварійні дампи в системі та скомпілювати ядро ​​з символами налагодженняЦе контролюється з каталогу конфігурації ядра, зазвичай у /usr/src/sys/<arq>/conf.

У відповідному файлі конфігурації генерацію символів можна ввімкнути за допомогою такого рядка:

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

Після зміни конфігурації ядро ​​необхідно перекомпілювати. Деякі об'єкти будуть перегенеровані (наприклад trap.o) через зміну у файлах збірки. Мета полягає в тому, щоб отримати ядро ​​з той самий код, що й у проблемному коді, але з додаванням необхідної інформації для налагодженняБажано порівняти старі та нові розміри за допомогою команди size щоб переконатися, що у двійковому файлі не відбулося неочікуваних змін.

Після встановлення ядра за допомогою символів ми можемо переглянути дампи за допомогою kgdb як описано в офіційній документації. Не всі символи можуть бути повними, а деякі функції можуть відображатися без номерів рядків або інформації про аргументи, але в більшості випадків рівень деталізації достатній для виявлення проблеми.

Немає абсолютної гарантії, що аналіз вирішить усі інциденти, але на практиці... Ця стратегія досить добре працює у високому відсотку сценаріївособливо коли аварійні дампи поєднуються з гарним оглядом останніх змін у системі.

Найкращі практики аналізу та документування помилок ядра

Незалежно від операційної системи, аналіз дампа ядра зазвичай призводить до технічна документація, бази знань, спеціалізовані форуми або навіть сам вихідний код ядра інтерпретувати повідомлення, коди помилок та незнайомі символи.

У Linux дуже корисно покладатися на офіційне дерево вихідного коду, вбудовану документацію та ресурси спільноти. Багато повідомлень про помилки ядра можна простежити до точного файлу, з якого вони походять, що допомагає зрозуміти проблему. контекст, у якому спрацьовує BUG() або WARN() визначається.

У Windows документація Microsoft, база знань (KB) та технічні форуми містять детальні пояснення коди перевірки помилок, рекомендації щодо вирішення проблем та відомі шаблони помилокПоєднуючи цю інформацію зі звітами !analyze -v, можна скласти розумний план пом'якшення наслідків.

Справжня цінність аварійного дампа проявляється, коли вся ця інформація зіставляється з ґрунтовне знання операційної системи та конкретного середовища, де стався збійТільки таким чином можна запропонувати довгострокові рішення та, перш за все, запобігти повторенню тієї ж проблеми в майбутньому з більш серйозними наслідками.

Аналіз дампу пам'яті ядра, зрештою, є поєднанням науки та ремесла: він вимагає відповідних інструментів, попереднього налаштування (символи, параметри дампу, безпечне сховище) та значного досвіду читання стеків, структур та кодів помилок. Оволодіння цими методами дозволяє не лише налагоджувати складні інциденти, але й різко підвищити рівень безпеки та стійкості систем, якими ми керуємо.