Как снять дамп памяти linux

Обновлено: 06.07.2024

Средство dotnet-dump просто в использовании и не зависит от каких-либо отладчиков машинного кода. dotnet-dump работает на различных платформах Linux (например, Alpine или ARM32/ARM64), где традиционные средства отладки могут быть недоступны. Однако dotnet-dump фиксирует только управляемое состояние, поэтому его нельзя использовать для отладки в машинном коде. Дампы, собранные dotnet-dump , анализируются в среде с той же ОС и архитектурой, в которой был создан дамп. Средство dotnet-gcdump можно использовать в качестве альтернативного варианта, которое фиксирует только сведения о куче GC, но создает дампы, которые можно проанализировать в Windows.

Дампы ядра с помощью createdump

Вместо dotnet-dump , создающего только управляемые дампы, createdump рекомендуется для создания основных дампов в Linux, содержащих как собственные, так и управляемые данные. Другие средства, такие как gdb или gcore, можно также использовать для создания основных дампов, однако они могут не учитывать состояние, необходимое для управляемой отладки, что приводит к неизвестному типу или именам функций во время анализа.

<input-filename>

Параметры

-f|--name <output-filename>

Файл, в который записывается дамп. Значение по умолчанию — "/tmp/coredump.%p", где % p — это идентификатор целевого процесса.

-n|--normal

-h|--withheap

Создание минидампа с кучей (по умолчанию).

-t|--triage

Создание минидампа для рассмотрения.

-u|--full

Создайте полного дампа ядра.

-d|--diag

Для сбора дампов ядра требуется либо возможность SYS_PTRACE , либо createdump необходимо запустить с помощью sudo или su.

Анализ дампов в Linux

Как управляемые дампы, собранные с помощью dotnet-dump , так и дампы ядра, собранные с помощью createdump , можно проанализировать с помощью средства dotnet-dump , используя команду dotnet-dump analyze . dotnet dump требует, чтобы среда, в которой анализируется дамп, использовала ту же ОС и архитектуру, что и среда, в которой был записан дамп.

libmscordaccore.so
libcoreclr.so
dotnet (узел, используемый для запуска приложения)

После того как необходимые файлы будут доступны, можно загрузить дамп в LLDB, указав узел dotnet в качестве исполняемого файла для отладки:

После запуска LLDB может потребоваться использовать команду setsymbolserver , чтобы указать правильное расположение символов ( setsymbolserver -ms , чтобы использовать сервер символов корпорации Майкрософт, или setsymbolserver -directory <path> для указания локального пути). Собственные символы можно загрузить, запустив loadsymbols . На этом этапе для анализа дампа можно использовать команды SOS.

Содержание оперативной памяти является очень важной информацией при изучении предыдущих действий с машиной. Оперативная память может содержать как части самих исполняемых процессов, так и части удаленных файлов, пользовательских сессий, криптографических ключей. При современном распространении сложных систем защиты информации, основанных на криптовании восстановление их ключей становиться чуть-ли не одной из основных задач для исследования. В защищенных системах зачастую оперативная память это единственное место где могут сохраниться защитные ключи и другая временная, но очень важная информация.

Процесс получения информации, которая содержится в оперативной памяти состоит из двух этапов: изъятие содержимого оперативной памяти
и
анализ полученных во время изъятия данных.

Обращая внимание на первый этап стоит заметить, что изъятие оперативной памяти может быть выполнено с помощью ряда средств: непосредственный доступ к памяти с использованием специальных плат расширения, порта FireWire, и даже физическом изъятии запоминающего устройства оперативной памяти (потребует замораживания плат),

но в данном материале мы рассмотрим программные средства, которые позволяют изъять содержимое оперативной памяти защищенных машин путем так называемой «горячей» перезагрузки и запуска машины в Live-режиме.

Для выполнения этой задачи будем использовать специальный дистрибутив Ubuntu CyberPack (IRF) 1.0, состоящий из минимального набора компонент, а именно, только те, которые необходимы для изъятия данных из памяти. Соответственно отсутствует и графический интерфейс.

Использование такого подхода к изъятию содержимого оперативной памяти имеет ряд преимуществ и недостатков сравнительно с другими перечисленными выше средствами.
Плюсы:
— использование Live-дистрибутива позволяет проводить действие не зависимо от того какая операционная система установлена на исследуемой машине;
— отсутствуют затраты на приобретение дорогостоящих специальных устройств, кабелей, плат, и др.
Недостаток:
— содержимое оперативной памяти будет неполным — ее часть будет перезаписана данными, необходимыми для запуска Live-дистрибутива (приблизительно 125 Мб).

Для использования доступны специально собранные дистрибутивы для машин с памятью объемом до 3 Гб (і386) и свыше 3 Гб (amd64). С их помощью можно создать загрузочный CD/DVD-диск или загрузочный USB-диск.

Замечания:
— второго шанса система нам не дает — у нас есть только одна попытка. т. е. при повторной перезагрузке исследуемого компьютера большая вероятность того что мы уже не найдем необходимой информации. Отсюда следует что не надо перезагружать его несколько раз, экспериментировать, прицеливаться.
Необходимо заранее подготовится и знать как компьютер себя поведет после перезагрузки.
Большинство современных компьютеров позволяют прямо при старте указать откуда производить загрузку, но если этого нет, тогда необходимого настроить BIOS машины на загрузку с CD/DVD-привода или USB-привода/накопителя, после чего загрузить Live-дистрибутив с указанного устройства.

Перезагружаем компьютер.
ВАЖНО: перезагрузка ни в коем случае не должна быть холодной (путем нажатия кнопки «ресет» или выключение\включение питания), а именно — перезагрузка должна быть осуществлена средствами самой работающей системы (например нажатием кнопок Ctrl-Alt-Del или путем выбора пункта «перезагрузка» в системе)

После загрузки дистрибутива пользователю доступна привычная строка консоли Linux, и краткая информация для запуска модуля.

Замечание: Для дальнейших действий понадобиться примонтировать заранее подготовленный носитель (внешний жесткий диск, флеш-накопитель) с файловой системой ext2/3/4, в который будет сохраняться файл с содержимым оперативной памяти.

Далее следует примонтировать логический раздел накопителя к папке /tmp загруженной в Live-режиме операционной системы:

Все подготовительные шаги сделаны — можно переходить к изъятию содержимого оперативной памяти:

В результате мы получили содержимое оперативной памяти машины в файле «ram-image.mem» на накопителе. Теперь его можно обрабатывать в т.ч. извлекая части исполняемых процессов, удаленных файлов, информацию о пользовательских сессиях, криптографических ключах и многое другое.

P.S.
Также стоит обратить внимание что все современные системы используют в своей работе и swap-память (так называемый «файл подкачки»)
Файл подкачки – это своеобразное дополнение к оперативной памяти (которая занимается временным хранением данных для быстрой доставки их на обработку процессору) Вашего компьютера. Даже не столько дополнение, сколько её уширение или, можно сказать, продолжение. Дело в том, что когда не хватает оперативной памяти система может переносить данные из памяти на диск (так называемая дополнительная память), в котором соответственно также хранятся данные.
И для полной картины анализа памяти необходимо также получить и их.
Различные операционные системы используют разные способы их хранения.

В случае с Windows это обычно файлы в корне на системном диске С:
pagefile.sys для Win XP и Win 7 и достаточно просто скопировать файл

Для Linux — это отдельный раздел на носителе.
Например:
Команда sudo fdisk -l /dev/sda
покажет нам все разделы в системе
/dev/sda1 * 2048 78125055 39061504 83 Linux
/dev/sda2 78125056 117186559 19530752 82 Linux своп / Solaris
/dev/sda3 117186560 625141759 253977600 83 Linux
Исходя из чего мы видим что раздел подкачки находиться в /dev/sda2
Скопировать его можно также с помощию команды dd.
Например:
dd if=/dev/sda2 of=/media/<путь куда записать>/linux-swap.dd

Для MacOS необходимо скопировать все файлы из директории /private/var/vm/swapfile*

Обработка и анализ полученных результатов (как дампа оперативной памяти так и swap-памяти) может проводиться как в ручную с помощью например HEX-редактора, так и с помощью ряда программ о которых будет рассказано в следующий раз.

Первая задача в цифровой криминалистике — это сбор информации, конкретно — получение образов жестких дисков и оперативной памяти, а также, если это может помочь, дампов сетевых соединений. В этой статье мы посмотрим, что нужно сделать для получения всего этого на машинах с Linux, а заодно научимся и другим полезным навыкам.

Это новая часть цикла по форензике для новичков, в котором мы рассказываем о том, что такое цифровая форензика, разбираем наиболее популярные инструменты анализа, изучаем несколько кейсов на устройствах с Android и расследуем хищение денежных средств из системы ДБО на ноутбуке с Windows 10.

Предыдущие статьи цикла:

Есть много вариантов создания дампа содержимого жесткого диска или оперативной памяти. При этом можно использовать и нативные утилиты, входящие в состав дистрибутива, и сторонние программы — как со свободной лицензией, так и коммерческие. Я по возможности сосредоточусь на наиболее известных, максимально простых и рабочих инструментах.

Первым делом на «живые» системы я рекомендую ставить утилиту Auditd — с ее помощью можно получить детальные сведения об изменениях системы в режиме аудита.

Прежде всего нас будут интересовать такие события, как:

запуск и завершение работы системы (перезагрузка, остановка);
чтение/запись системных файлов и изменение прав доступа к ним;
инициация сетевого соединения и изменение сетевых настроек;
изменение информации о пользователе или группе;
изменение даты и времени;
установка, удаление, запуск и остановка программ и демонов;
выполнение системных вызовов.

Некоторые особенности форензики в Linux

В прошлой статье, которая была посвящена кейсу с хищением денежных средств в ДБО на Windows 10, мы по возможности использовали в качестве инструментария программы с графическим интерфейсом. Если не брать проприетарные решения, такие, к примеру, как EnCase Forensic или Belkasoft Evidence Center, то на Linux большинство рабочих утилит идет в режиме командной строки.

Использование тестовых команд существенно экономит время на манипуляции с софтом, но, с другой стороны, может оказаться слишком сложным для новичков. Однако форензикой новички обычно и не занимаются! 😀

Помимо отдельных утилит, есть целые дистрибутивы, предназначенные для цифровой криминалистики. Это прежде всего DEFT, CAINE, Sumuri PALADIN, Helix, ну и, конечно же, всем известный Kali Linux. Полный обзор дистрибутивов и тулкитов для форензики можно прочитать в статье «Тулкит для форензики. Выбираем дистрибутив и набор софта для криминалистического анализа».

Из литературы по форензике в Linux я бы в первую очередь порекомендовал едва ли не единственную полноценную книгу об этом. Ее написал Филип Полстра, а называется она Linux Forensics Paperback. Во вторую очередь — издание UNIX and Linux Forensic Analysis DVD Toolkit Криса Пога и других. Ну и в-третьих, Digital Forensics with Kali Linux.

Общий чек-лист проверки

Для поиска и сбора криминалистических доказательств мы первым делом создадим образы (дампы) следующих объектов наших систем:

оперативная память (системные и пользовательские процессы, демоны, возможно запущенный вредоносный код и так далее);
жесткий диск (посекторная копия HDD, включающая удаленные разделы, неразмеченные области диска, потертые файлы, скрытые файлы и директории и прочее);
сетевой стек (поднятые коннекты, открытые порты, «неизвестные» сервисы на портах, паразитный трафик).

В рамках самой операционной системы мы будем обращать особое внимание в первую очередь:

на список пользователей, группы, привилегии;
запущенные от имени root процессы;
задачи, запускаемые по расписанию (cron jobs);
файлы с установленным битом SUID и SGID;
состав файла /etc/sudoers;
скрытые файлы и директории;
файлы, открытые на чтение в системе;
сетевые интерфейсы, соединения, порты, таблицу маршрутизации;
логи iptables, fail2ban (Reports, Alarms, Alerts);
конфигурацию /etc/ssh/sshd_config ;
логи демона Syslog (проверим на типичные алерты);
состояние SELinux;
список загруженных модулей ядра.

Ну и в качестве дополнительной опции можно собрать контрольные суммы с основных системных файлов (к примеру, утилитой TripWire), а позже сравнить их с эталонными значениями в исходном дистрибутиве. Но этот процесс весьма нетривиален и требует большого запаса времени и нервных клеток. Поэтому подробности мы любезно опустим.

Поскольку железо, на котором крутится вся ферма, находится в надежном дата-центре, сразу отметается поиск артефактов, связанных с сетевой ФС (NFS), локально смонтированными устройствами и подключенными по USB девайсами.

WARNING

Всегда хорошо обдумывай, какое именно действие и для какой цели ты делаешь. Неправильное использование приведенных в тексте статьи программ может привести к потере информации (артефактов) или искажению полученных данных (криминалистических доказательств). Ни автор, ни редакция не несут ответственности за любой ущерб, причиненный при неправильном использовании материала данной статьи.

Снимаем образ HDD

Посекторную копию жесткого диска вполне можно снять, не прибегая к дополнительным утилитам. Мы будем использовать старую и проверенную в работе нативную тулзу dd. Она позволяет создавать точные побитовые копии — как целых дисков, так и отдельных разделов и даже просто файлов.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Возникла необходимость получить дамп РНР-процесса на Debian 9.

Рассмотрим механизм ядра, позволящий создать дамп, и настройку создания дампов в Linux.

Linux Core Dump

Ядро создаёт дамп памяти процесса, если он выполнил недопустимую операцию, и должен быть остановлен.

Для этого при выполнении такой операции ядро отправляет один из аварийных сигналов процессу, после чего процесс обрабатывает сигнал сам, или с помощью сторонних обработчиков, что запускает механизм ядра, который создаёт дамп.

Список таких сигналов задаётся в макросе SIG_KERNEL_COREDUMP_MASK :

Который срабывает в случае Fatal-ошибок, и вызывает do_coredump() :

Ну а сама do_coredump() создаёт дамп.

Сигналы и создание дампа

Проверим работу дампа.

Берём простой код на Си:

Собираем, и запускаем:

В окне с приложением проверяем:

Проверяем файл дампа:

-rw------- 1 setevoy setevoy 380928 Mar 10 11:24 coredump-make_dump.2714790 /tmp/coredump-sleep.2761144: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'sleep 100', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/sleep', platform: 'x86_64' Program terminated with signal SIGSEGV, Segmentation fault. 0 0x00007f50d566e27e in clock_nanosleep@GLIBC_2.2.5 () from /usr/lib/libc.so.6

kernel.core_pattern

Тут можно задать путь и имя файла, в который будет записан дамп, либо передать создание дампа внешнему обработчику, например systemd-coredump (рассмотрим ниже).

См. документацию Naming of core dump files тут>>>.

Из наиболее используемых опций тут:

%e executable filename (without path prefix)
%p PID of dumped process, as seen in the PID namespace in which the process resides
%t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)

Собственно файл /tmp/coredump-make_dump.2714790, который мы открыли в GDB, и состоит из kernel.core_pattern = /tmp/coredump-%e.%p :

limits.conf

Либо проверяем в рабочем окружении:

Лимиты конкретного процесса можно получить через его дескриптор в /proc :

fs.suid_dumpable

Иногда дамп может не создаваться, если процесс в процессе выполнения выполнил запрос на смену UID, например через вызов setuid() .

Определяется флагом fs.suid_dumpable :

Может принимать значение 0, 1 или 2, см. man proc:

systemd-coredump

На Arch Linux он используется по-умолчанию, на Debian 9 ставим из репозитория:

|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %e

Создаём дамп какого-то процесса:

coredumpctl

Mon 2020-03-09 20:10:16 EET 20882 0 0 11 present /home/admin/dump_test Tue 2020-03-10 09:04:14 EET 16786 1003 1003 11 present /usr/sbin/php-fpm7.4 Tue 2020-03-10 12:23:43 EET 27117 0 0 11 present /bin/sleep

В колонке SIG сразу видим код сигнала, с которым был убит процесс, в данном случае 11 == SIGSEGV .

Сами файлы дампов systemd-coredump сохраняет в /var/lib/systemd/coredump :

-rw-r----- 1 root root 25208 Mar 9 20:10 core.dump_test.0.6bb23c691d354e9dbf4382d109a5c1d4.20882.1583777416000000000000.lz4 -rw-r----- 1 root root 33962 Mar 10 12:23 core.sleep.0.6bb23c691d354e9dbf4382d109a5c1d4.27117.1583835823000000000000.lz4

Друзья, сегодня разберём некоторые инструменты для сбора артефактов со скомпрометированных Linux-систем и создадим дампы (образы) жёсткого диска, оперативной памяти, сетевого стека. В ход пойдут только самые известные, проверенные и простые для использования утилиты.

Общий чек-лист проверки

Собственно говоря, для поиска и сбора криминалистических доказательств мы для начала создадим образы (дампы) следующих объектов наших систем: — оперативная память (системные и пользовательские процессы, демоны, возможно, запущенный вредоносный код и т. д.); — жёсткий диск (посекторная копия HDD, включающая уделённые партиции, неразмеченные области диска, потёртые файлы, скрытые файлы и директории и т. д.); — сетевой стек (поднятые коннекты, открытые порты, «неизвестные» сервисы на портах, паразитный трафик).

В рамках самой операционной системы мы будем обращать особое внимание в первую очередь на: — список пользователей, группы, привилегии; — запущенные от имени root процессы; — задачи, запускаемые по расписанию (cron jobs); — файлы с установленным битом SUID и SGID; — состав файла /etc/sudoers; — скрытые файлы и директории; — файлы, открытые на чтение в системе; — сетевые интерфейсы, соединения, порты, таблицу маршрутизации; — логи iptables, fail2ban (Reports, Alarms, Alerts); — конфигурацию /etc/ssh/sshd_config; — логи демона Syslog на типичные алерты; — состояние SELinux; — список загруженных модулей ядра.

Снимаем образ HDD-диска

Посекторную копию жёсткого диска можно вполне снять, не прибегая к дополнительным утилитам. Мы будем использовать старую и проверенную в работе нативную тулзу dd. Она позволяет созвать точные копии "bit-by-bit" целых дисков, отдельных партиций и даже просто файлов.

Но первоначально запросим у системы полный список партиций с помощью команды fdisk:

Базовый синтаксис вызова dd выглядит так:

К примеру, для создания копии HDD с размером кластера 512 байт:

В процессе копирования HDD могут быть повреждённые сектора. Чтобы программа не запнулась об них, остановив свою работу, необходимо добавить дополнительный ключ noerror:

Однако мировые best practices рекомендуют нам использовать усовершенствованный вариант предыдущей утилиты под названием dcfldd. Эта тулза разработана в компьютерной судебной лаборатории DCFL (Defense Computer Forensics Laboratory) и имеет ряд опций, специально заточенных для снятия образа в целях криминалистического анализа. Так, под капотом у dcfldd имеется встроенная возможность хеширования (hashing) копируемых данных и функция проверки целостности данных (аутентификации). Помимо этого, отображается прогресс создания дампа, действия заносятся в лог-файл, а контрольные суммы (MD5) сохраняются в отдельный файл.

Пример выполнения команды:

Делаем дамп оперативной памяти (RAM)

Следующим шагом после снятия дампа HDD мы приступаем к формированию образа оперативной памяти. И, как в случае с жёстким диском, существует несколько способов решить эту задачу. Среди вариантов можно выбрать использование нативного модуля ядра с названием Linux Memory Extractor (LiME), скрипт Linux Memory Grabber, который не требует установки и который можно запускать, к примеру, с USB-носителя, и связку утилит lmap и pmem, являющихся частью пакета Rekall, которые я буду дальше использовать.

Пара слов о Rekall. Это отдельная ветка развития известного фреймворка Volatility Framework, написанная на Python и заточенная под особенности сбора данных из под LiveCD форензик-дистрибутивов.

Итак, чтобы подготовить тулзу к работе, переходим в каталог ../rekall/tools/linux/:

Грузим драйвер ядра pmem.ko в оперативную память:

Проверяем инициализацию драйвера следующей командой:

После этого драйвер создаёт файл-контейнер под наш будущий образ RAM:

Теперь с помощью всё той же утилиты dd создаём сам образ оперативной памяти системы:

Ну и после завершения работы выгружаем драйвер:

Ну, вот дело сделано!

Но это ещё не всё, во второй части статьи поговорим про сетевой трафик, смонтируем образы в исследовательскую систему и выполним анализ образа жёсткого диска. Следите за новостями!

Читайте также: