Linux process memory dump

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Script that dumps running process memory from Linux systems using /proc.

fuhry/linux-memory-dumper

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This is a script which dumps as much allocated memory as possible from a running Linux system. The primary target is user data, which is arguably the most difficult thing to get from a Linux box these days that is relevant to a forensic investigation.

By parsing /proc/[pid]/maps and dumping the regions described in there from /proc/[pid]/mem.

No! However, the success rate is significantly more limited when you run it as an unprivileged user. I still managed to pull quite a bit of information out running it under my normal unprivileged account.

For a forensics class, and generally because there’s a lack of memory dumping utilities for Linux these days since /dev/mem was deprecated.

My tool is not a replacement for /dev/mem. It dumps allocated memory from currently running user-space processes. The following are not dumped (this is not an exhaustive list):

• Unallocated pages
• Kernel threads
• I/O cache memory
• Files mapped with mmap()
• processes which restrict the use of ptrace(2)

It is also not a one-stop magical forensic report generator. If you think otherwise, consider a different career. Alongside the use of this tool you should be collecting lots more information from the system, the specifics of which are outside the scope of this document.

This script collects its list of PIDs at start-up, and then scans through each one. The process takes a while. By the time it makes it to a given process it may have died, and by the time it finishes new processes may have spawned. Since the goal of this script is to collect data from longer-running processes such as web browsers and editors, I don’t consider this a huge issue. Any competent forensic examiner uses this script alongside other techniques such as disk imaging anyway.

It’s slow as balls right now, I think because access to /proc is slow on my system, which is pretty up-to-date (kernel 3.8.4) probably because the kernel generates maps files and such on the fly.

It probably will not obtain dm-crypt encryption keys, as those are likely to be stored in the memory of kernel threads, but those can easily be obtained (if you have root) with «dmsetup table —showkeys».

Everything about this script is also based on virtual memory addresses, not physical. This will complicate the process of verifying results. Memory imaging in general is, in my opinion, very difficult to verify because RAM by its very nature is constantly changing, and it is impossible to image a box’s memory without changing it in some way. Thus, the ability of this tool’s output to stand up in court is questionable.

This tool is not intended to image every byte on the box, and is incapable of doing so. This applies in particular to free (unallocated) and I/O cache memory.

The good folks on /r/netsec have proposed compiling your kernel with CONFIG_GRKERNSEC_PROC, CONFIG_GRKERNSEC_PROC_MEMMAP, and CONFIG_GRKERNSEC_HARDEN_PTRACE.

I’ve written this utility in good faith. It’s open source, you can see exactly how it gathers its data, and you can go back to the Linux kernel docs or even the kernel source to examine its behavior. All this said, I cannot and will not be held liable for any inaccurate results returned by this tool, nor is any warranty provided (please see the license below).

Also, if you are a forensic examiner, please do not exclude the possibility that a smart enemy/target has modified their kernel to lie about memory regions or lie in /proc/[pid]/mem. It’s pretty easy to do.

Copyright (c) 2013 Dan Fuhry (dan@fuhry.com)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the «Software»), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED «AS IS», WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

About

Script that dumps running process memory from Linux systems using /proc.

Источник

Core dump (Русский)

Состояние перевода: На этой странице представлен перевод статьи Core dump. Дата последней синхронизации: 15 февраля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Дамп памяти (core dump) — это файл, в который записывается адресное пространство (память) процесса при его нештатном завершении. Дампы ядра могут создаваться по требованию (например, отладчиком) или автоматически при завершении процесса. Дампы памяти создаются ядром при сбое программы и могут быть переданы вспомогательной программе (например, systemd-coredump(8) ) для дальнейшей обработки. Дамп памяти обычно не используется обычным пользователем, но может быть передан разработчикам по их запросу, которым будет очень полезно иметь снимок состояния программы на момент сбоя, особенно если сбой трудно воспроизвести.

Отключение автоматических дампов памяти

Пользователи могут захотеть отключить автоматические дампы памяти по нескольким причинам:

• Производительность: создание дампа для процессов, занимающих много памяти, может привести к трате системных ресурсов и задержке очистки памяти.
• Дисковое пространство: дампы процессов, занимающих много памяти, могут занимать место на диске, равное, а то и большее, чем объём памяти процесса, если их не сжимать.
• Безопасность: хотя дампы обычно может читать только root, они могут содержать конфиденциальные данные (например, пароли или криптографические ключи), которые записываются на диск после сбоя.

Используя sysctl

Можно использовать sysctl, чтобы изменить kernel.core_pattern для отключения дампов. Создайте файл:

kernel.core_pattern=/dev/null

Для немедленного применения изменений используйте команду sysctl :

# sysctl -p /etc/sysctl.d/50-coredump.conf

Используя systemd

Поведение systemd по умолчанию определено в файле /usr/lib/sysctl.d/50-coredump.conf , который прописывает kernel.core_pattern для вызова systemd-coredump . Он сохраняет дампы ядра для всех процессов в /var/lib/systemd/coredump . Поведение systemd-coredump можно переопределить, создав в /etc/systemd/coredump.conf.d/ файл ( coredump.conf(5) § DESCRIPTION ,, [1]):

/etc/systemd/coredump.conf.d/custom.conf

Примечание: Не забудьте прописать имя секции [Coredump] , иначе опция будет проигнорирована.

Одного этого метода обычно достаточно для отключения записи дампов, если в системе нет других программ, включающих автоматические дампы, но дамп памяти всё равно генерируется в памяти и systemd-coredump всё равно запускается.

Используя PAM limits

Максимальный размер дампа памяти для пользователей, вошедших в систему через PAM, задаётся в файле limits.conf. Установка нулевого значения полностью отключает дампы памяти. [2]

Используя ulimit

Командные оболочки вроде bash и zsh имеют встроенную команду ulimit, которую можно использовать для просмотра или изменения ограничений на ресурсы оболочки и запускаемых ею процессов. Подробнее смотрите bash(1) § SHELL BUILTIN COMMANDS или zshbuiltins(1) .

Отключение дампов памяти в текущей командной оболочке:

Создание дампа памяти

Чтобы сгенерировать дамп памяти произвольного процесса, сначала установите пакет gdb . Затем найдите PID запущенного процесса, например, с помощью pgrep:

Подключитесь отладчиком к этому процессу:

И затем в отладчике выполните:

(gdb) generate-core-file Saved corefile core.2071 (gdb) quit

Теперь у вас есть дамп памяти в файле core.2071 .

Куда они попадают?

sysctl kernel.core_pattern определяет, куда отправляются автоматические дампы памяти. По умолчанию их принимает systemd-coredump, который настраивается через файл /etc/systemd/coredump.conf . По умолчанию он записывает дампы в /var/lib/systemd/coredump (опция Storage=external ), сжимая их с помощью zstd (опция Compress=yes ). Кроме того, можно настроить различные ограничения на размер хранилища.

Примечание: Значение по умолчанию для kernel.core_pattern задаётся в файле /usr/lib/sysctl.d/50-coredump.conf . Этот файл может быть замаскирован или переопределён для использования другого значения в соответствии с обычными правилами sysctl.d(5) .

Чтобы получить дамп памяти из журнала, смотрите coredumpctl(1) .

Изучение дампа памяти

Команда coredumpctl покажет список сохранённых дампов, среди которых можно найти нужный:

Для поиска нужного дампа можно использовать PID, имя исполняемого файла, путь к исполняемому файлу или предикат journalctl (подробнее: coredumpctl(1) и journalctl(1) ). Просмотр подробностей о дампах ядра:

# coredumpctl info соответствие 

Обратите внимание на строку «Signal», она поможет определить причину сбоя. Для более глубокого анализа вы можете изучить backtrace с помощью gdb:

# coredumpctl gdb соответствие 

После запуска gdb можно использовать команду bt для получения backtrace:

Если отладочные символы нужны, но не найдены, можно попробовать получить их, как описано в статье Отладка/Трассировка.

Удаление дампов памяти

Файлы дампов памяти, хранящиеся в /var/lib/systemd/coredump/ , будут автоматически очищаться командой systemd-tmpfiles —clean , которая запускается ежедневно с помощью systemd-tmpfiles-clean.timer . Дампы памяти настроены на хранение не менее 3 дней, смотрите systemd-tmpfiles —cat-config .

Смотрите также

• american fuzzy lop — Инструмент для автоматизированного тестирования ядра и программ
• Filesystem fuzzing — Статья LWN о тестировании файловых систем на наличие ошибок

Источник