Статья Снятие образа RAM памяти с windows и linux
Приветствую)
Речь в этой теме пойдет о снятии слепков оперативной памяти.
Зачем вообще нам нужен дамп оперативки? Да затем что там можно найти много интереснейших и неожиданных вещей)
Каких? Да разных))) Например ключики от криптоконтейнеров, различные сообщения из чатов и соцсетей, посещенные страницы в инете и вообще море системной информации.
Мы рассмотрим пару вариантов поучения дампа)
Для начала Windows
Вариант 1
Используем бесплатную программу от компании Belkasoft «Belkasoft Live RAM Capture»
Скачать еe можно на оф. сайте, заполняем не большую форму и ссылка приходит к Вам на электронную почту.
Что можно сказать об этой программе, работает быстро и просто, не требует установки.
Запускаем исполняемый файл, выбираем путь куда будет сохранен образ и жмем capture
Вариант 2
FTK Imager
Тоже довольно шустрая программулина, в отличии от первой требует установки.
Скачивается так же как и предыдущая, приходит ссылка на электронную почту. Скачиваем, установка проходит буквально в пару кликов.
После запуска жмем File>CaptureMemory
Точно так же выбираем путь и кликакем Capture Memory
Через несколько минут слепок будет готов)
Linux
Для линукса я использовал только одну программу, имя ей LiME
Это инструмент командной строки
и все, в папке будет создан файл image.lime это и есть наш дамп)
Это далеко не все способы получения RAM памяти, есть дистрибутив имеется возможность получения дампа с помощью порта FireWire, так же возможно физическое изьятие ОЗУ с замораживанием платы.
Для исследования содержимого оперативной памяти есть огромное количество утилит, как для линукс систем, так и для windows
На этом я думаю пока что все)
Источник
Получаем образ оперативной памяти
Содержание оперативной памяти является очень важной информацией при изучении предыдущих действий с машиной. Оперативная память может содержать как части самих исполняемых процессов, так и части удаленных файлов, пользовательских сессий, криптографических ключей. При современном распространении сложных систем защиты информации, основанных на криптовании восстановление их ключей становиться чуть-ли не одной из основных задач для исследования. В защищенных системах зачастую оперативная память это единственное место где могут сохраниться защитные ключи и другая временная, но очень важная информация.
Процесс получения информации, которая содержится в оперативной памяти состоит из двух этапов: изъятие содержимого оперативной памяти
и
анализ полученных во время изъятия данных.
Обращая внимание на первый этап стоит заметить, что изъятие оперативной памяти может быть выполнено с помощью ряда средств: непосредственный доступ к памяти с использованием специальных плат расширения, порта 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, и краткая информация для запуска модуля. 
Подготовка к работе программы fmem заключается в выполнении следующих команд:
$ sudo -s
# cd /opt (переход в папку где находиться программа);
# ./run-fmem.sh (скрипт запуска модуля съема памяти);
Замечание: Для дальнейших действий понадобиться примонтировать заранее подготовленный носитель (внешний жесткий диск, флеш-накопитель) с файловой системой ext2/3/4, в который будет сохраняться файл с содержимым оперативной памяти.
Для того, что бы узнать какой идентификатор присоединенному носителю присвоила система, необходимо после его подключения к компьютеру ввести следующую команду:
# dmesg | tail (Команда выводит на экран информацию буфера сообщений ядра. Нас будет интересовать последняя запись.)
Как например вот это:
[16091.995428] sd 9:0:0:0: Attached scsi generic sg2 type 0
[16091.995996] sd 9:0:0:0: [sdb] 32096120 512-byte logical blocks: (16.4 GB/15.3 GiB)
[16091.998192] sd 9:0:0:0: [sdb] Write Protect is off
[16091.998205] sd 9:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[16091.999433] sd 9:0:0:0: [sdb] No Caching mode page found
[16091.999447] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[16092.003486] sd 9:0:0:0: [sdb] No Caching mode page found
[16092.003495] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[16092.004251] sdb: sdb1
(где «sdb» — присвоенное обозначение физического накопителя, а «sdb1» — присвоенное обозначение логического раздела накопителя).
Далее следует примонтировать логический раздел накопителя к папке /tmp загруженной в Live-режиме операционной системы:
# mount /dev/sdb1 /tmp
(где
«mount» — команда монтирования устройства
«/dev/sdb1» — адрес файла логического раздела присоединенного накопителя
«/tmp» — папка в которую необходимо подключить накопитель).
Все подготовительные шаги сделаны — можно переходить к изъятию содержимого оперативной памяти:
# dd if=/dev/fmem of=/tmp/ram-image.mem bs=1K count=`head -1 /proc/meminfo | awk ‘
(где
«dd» — команда создания образа
«if=/dev/fmem» — источник данных, а именно оперативная память
«of=/tmp/ram-image.mem» — запись в файл «ram-image.mem» в папку «/tmp»
«bs=1K» — размер блока информации — 1 Кб
«count=`head -1 /proc/meminfo | awk ‘
И ждем…
В результате удачного выполнения команды, мы получим сообщение похожее на это:
521453568 bytes (521 MB) copied, 158.405 s, 3.3 MB/s
(где
«521453568 bytes (521 MB) copied» — объем скопированной информации
«158.405 s» — время в течении которого проводилась операция
«3.3 MB/s» — скорость при которой проводилась операция)
В результате мы получили содержимое оперативной памяти машины в файле «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
В данной статей мы рассмотрим метод удаленного получения образа памяти при помощи LiME в системе на базе CentOS 6.5 x64.
Автор: Дэн Кэбен (Dan Caban)
Раньше образ памяти в системах на базе ОС Linux можно было получить напрямую (при помощи утилиты dd) из файлов псевдоустройств, таких как /dev/mem и /dev/kmem. В последних версиях ядра доступ к этим устройствам стал ограничен и/или полностью исключен. Чтобы исследователи и системные администраторы могли получить неограниченный доступ, были разработаны загружаемые модули, которые, к примеру, доступны в проектах fmem и LiME (Linux Memory Extractor).
В данной статей мы рассмотрим метод удаленного получения образа памяти при помощи LiME в системе на базе CentOS 6.5 x64.
LiME – загружаемый модуль ядра (Loadable Kernel Module, LKM). Загружаемые модули обычно разрабатываются с целью расширения функционала ядра. Модуль можно добавить, используя учетную запись с привилегиями суперпользователя. При установке модуля следует быть осторожным, поскольку некорректная его установка несет потенциальные риски для целевой системы. С другой стороны, LiME обладает рядом несомненных преимуществ:
- Скомпилированный модуль довольно небольшого размера.
- Процедура установки не требует перезагрузки.
- Модуль легко добавляется или удаляется.
- Полученный дамп памяти можно скачать удаленно без записи на локальный диск целевой системы.
- Дамп памяти совместим с фреймворком Volatility.
Подготовка к работе
Поскольку LiME распространяется в виде исходных текстов, для начала необходимо его скомпилировать. Всю доступную информацию можно легко найти в интернете, но перед этим рекомендую вам поискать скомпилированные версии модуля или скомпилировать и протестировать его на виртуальной машине.
В любом случае для начала необходимо узнать версию ядра на целевой машине.
]$ uname -a
Linux localhost.localdomain 2.6.32-431.5.1.el6.x86_64 #1 SMP
Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Скомпилированные версии LiME-модулей можно взять в Linux Forensics Tools Repository at Cert.org (этот ресурс заслуживает доверия). Там хранятся RPM-репозитарии аналитических утилит для Red Hat Enterprise Linux, CentOS и Fedora.
Чтобы найти скомпилированный модуль для определенной версии ядра и операционной системы зайдите на Cert и найдите «repoview» для целевой операционной системы
Рисунок 1: Раздел с репозитариями для CentOS
Далее зайдите в раздел «applications/forensics tools» и откройте документацию для «lime-kernel-objects».
На момент написания статьи в репозитарии были скомпилированные версии для следующих версий ядер (под ОС CentOS 6 / RHEL 6):
2.6.32-71
2.6.32-71.14.1
2.6.32-71.18.1
2.6.32-71.24.1
2.6.32-71.29.1
2.6.32-71.7.1
2.6.32-131.0.15
2.6.32-220
2.6.32-279
2.6.32-358.0.1
2.6.32-358.11.1
2.6.32-358.14.1
2.6.32-358.18.1
2.6.32-358.2.1
2.6.32-358.23.2
2.6.32-358.6.1
2.6.32-431
2.6.32-431.1.2.0.1
2.6.32-431.3.1
Оказалось, что под мою версию ядра еще не существует скомпилированных модулей. Придется сделать чуть больше телодвижений.
Я установил на виртуальной машине CentOS 6.5 x64 с последней версией ядра (2.6.32-431.5.1.el6.x86_64).
]$ yum update
[root@vmtest
После обновления ядра перезагружаем виртуальную машину.
Теперь нам нужны соответствующие заголовки и исходники ядра, а также утилиты для компиляции.
]$ yum install gcc gcc-c++ kernel-headers kernel-source
Теперь мы готовы к загрузке и компиляции модуля LiME!
]# mkdir lime; cd lime
[root@vmtest lime]# wget https://lime-forensics.googlecode.com/files/lime-forensics-1.1-r17.tar.gz
[root@vmtest lime]# tar -xzvf lime-forensics-1.1-r17.tar.gz
[root@vmtest lime]# cd src
[root@vmtest src]# make
….
make -C /lib/modules/2.6.32-431.5.1.el6.x86_64/build M=/root/lime/src modules
…
[root@vmtest src]# ls lime*.ko
lime-2.6.32-431.5.1.el6.x86_64.ko
После компиляции модуля загрузим его на виртуальной машине и выгрузим память в локальный файл. Настройки модуля выглядят следующим образом:
]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko «path=/root/mem.img format=lime»
Образ памяти будет выгружен в файл /root/mem.img, а формат «lime» совместим с фреймворком volatility.
Я проверил параметры созданного образа (на соответствие размера и объема памяти, выделенного под виртуальную машину, а также на корректность содержимого образа).
]# ls -lah /root/mem.img
-r—r—r—. 1 root root 1.0G Mar 9 08:11 /root/mem.img
[root@vmtest
]# strings /root/mem.img | head -n 3
EMiL
root (hd0,0)
kernel /vmlinuz-2.6.32-431.5.1.el6.x86_64 ro root=/dev/mapper/vg_livecd-lv_root rd_NO_LUKS
Удаляем модуль ядра при помощи простой команды:
Получение образа через интернет
После успешных тестов вернемся к нашей первоначальной задаче: захвату памяти на сервере с ОС CentOS и загрузке полученного образа через интернет. Я загрузил модуль на подконтрольный мне сервер, а затем скачал его через протокол HTTP:
LiME позволяет не только записывать образы на локальный диск. Вместо этого мы можем создать TCP-сервис при помощи аргумента path=tcp:4444.
]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko «path=tcp:4444 format=lime»
Если, к примеру, мы находимся внутри клиентской сети или порт 4444 доступен через интернет, при помощи netcat я могу соединиться с сервером и скачать образ памяти на свой компьютер.
]# nc target.server.com 4444 > /home/dan/evidence/evidence.lime.img
Поскольку целевой сервер находится в интернете, на котором установлен фаервол, к процессу получения образа следует подходить более творчески.
Помните, как я загружал модуль на целевой сервер через HTTP (80-й порт)? Это означает, что файервол разрешает исходящие TCP-соединения через этот порт.
Я могу установить сервер netcat, который будет доступен через интернет при помощи конфигурирования файервола так, чтобы трафик с этого порта передавался на мой локальный LAN-адрес. Вы можете сделать то же самое при помощи большинства роутеров и функции проброса портов (port forwarding).
Шаг 1: настраиваем netcat сервер на нашей машине, чтобы он прослушивал 80-й порт.
]# nc –l 80 > /home/dan/evidence/evidence.lime.img
Шаг 2: Запускаем модуль LiME и конфигурируем его на ожидание TCP-соединений на 4444 порту.
]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko «path=tcp:4444 format=lime»
Сейчас на целевом сервере я могу использовать локальное соединение netcat, связанное с удаленным соединением к моему компьютеру через 80-й порт (где 60.70.80.90 – условный адрес моей машины).
Шаг 3: Создаем цепочку для передачи образа памяти на мою машину.
]# nc localhost 4444 | nc 60.70.80.90 80
Теперь, когда образ оказался на моей машине, можно начать его анализ.
Ниже показана наглядная схема процесса передачи образа:
Рисунок 2: Схема передачи образа памяти на удаленный хост
Анализ памяти при помощи Volatility
В Volatility есть множество профилей для парсинга дампов памяти, но эти конфигурации в основном полезны при анализе образов взятых в ОС Windows. Чтобы выполнить анализ дампа взятого из Линукса, мы должны создать новый профиль, в точности соответствующий операционной системе, версии ядра и архитектуре. Вернемся в виртуальной машине для того, чтобы собрать всю необходимую информацию для создания профиля. Нам потребуется:
- отладочные символы (System.map*)
- Необходим доступ к тестовой виртуальной машине с той же самой архитектурой, версией ядра и операционной системой.
- информация о структурах данных ядра (vtypes)
- Необходимы исходники volatility и утилиты для компиляции файлов ядра на той же самой архитектуре, версии ядра и операционной системе.
Для начала создадим папку, в которую будем складировать все необходимые файлы.
mkdir -p volatility-profile/boot/
mkdir -p volatility-profile/volatility/tools/linux/
Теперь скопируем отладочные символы, находящиеся в CentOS в директории /boot/. Необходимо найти файл System.map*, соответствующий версии ядра, которая была запущена во время получения дампа памяти (2.6.32-431.5.1.el6.x86_64).
]# cd /boot/
[root@vmtest boot]# ls -lah System.map*
-rw-r—r—. 1 root root 2.5M Feb 11 20:07 System.map-2.6.32-431.5.1.el6.x86_64
-rw-r—r—. 1 root root 2.5M Nov 21 22:40 System.map-2.6.32-431.el6.x86_64
Копируем соответствующий файл System.map в ранее созданную папку.
[root@vmtest boot]# cp System.map-2.6.32-431.5.1.el6.x86_64
/volatility-profile/boot/ Одно из требований при компиляции файлов ядра (vtypes) – наличие библиотеки libdwarf. В других операционных системах ее можно получить при помощи apt-get или yum. В CentOS 6.5 необходимо скомпилировать исходники, взятые из Fedora Project. Остальные пакеты, необходимые для компиляции, должны быть установлены во время компиляции LiME (см. Раздел «Подготовка к работе»).
[root@vmtest boot]# cd
]# mkdir libdwarf
[root@vmtest libdwarf]# cd libdwarf/
[root@vmtest libdwarf]# wget http://pkgs.fedoraproject.org/repo/pkgs/libdwarf/libdwarf-20140208.tar.gz
/4dc74e08a82fa1d3cab6ca6b9610761e/libdwarf-20140208.tar.gz
[root@vmtest libdwarf]# tar -xzvf libdwarf-20140208.tar.gz
[root@vmtest dwarf-20140208]# cd dwarf-20140208/
[root@vmtest dwarf-20140208]#./configure
[root@vmtest dwarf-20140208]# make
[root@vmtest dwarfdump]# cd dwarfdump
[root@vmtest dwarfdump]# make install
Копируем исходники Volatility и скомпилировать структуры ядра.
[root@vmtest dwarfdump]# cd
]# mkdir volatility
[root@vmtest
]# cd volatility
[root@vmtest volatility]# cd volatility
[root@vmtest volatility]# wget https://volatility.googlecode.com/files/volatility-2.3.1.tar.gz
[root@vmtest volatility]# tar -xzvf volatility-2.3.1.tar.gz
[root@vmtest volatility]# cd volatility-2.3.1/tools/linux/
[root@vmtest linux]# make
После успешной компиляции скопируем получившийся файл (module.dwarf) в папку профиля.
[root@vmtest linux]# cp module.dwarf
Запаковываем оба файла в ZIP-архив (согласно требованиям Volatility).
[root@vmtest linux]# cd
/volatility-profile/
[root@vmtest volatility-profile]# zip CentOS-6.5-2.6.32-431.5.1.el6.x86_64.zip
boot/System.map-2.6.32-431.5.1.el6.x86_64 volatility/tools/linux/module.dwarf
adding: boot/System.map-2.6.32-431.5.1.el6.x86_64 (deflated 80%)
adding: volatility/tools/linux/module.dwarf (deflated 90%)
Полученный архив на своей машине можно было бы скопировать в стандартную папку, предназначенную для хранения профилей, однако чтобы избежать их потери во время обновлений, я создал отдельную директорию и сослался на нее во время запуска volatility.
Далее видим, что Volatility распознал новую директорию для плагинов.
dan@investigativelaptop evidence]# vol.py —plugins=/home/dan/.volatility/profiles/ —info | grep -i profile | grep -i linux
Volatility Foundation Volatility Framework 2.3.1
LinuxCentOS-6_5-2_6_32-431_5_1_el6_x86_64x64 — A Profile for Linux CentOS-6.5-2.6.32-431.5.1.el6.x86_64 x64
Запускаем плагины с префиксом linux, которые идут в составе Volatility, для выполнения анализа памяти.
Источник
