- PVSM.RU - https://www.pvsm.ru -
Иногда при анализе какой-нибудь платной программы малвари случается так, что она не хочет нормально работать, если в памяти есть отладчик или включён отладочный режим Windows.
В таких ситуациях помогает использование виртуальной машины с подключённым к ней отладчиком (например, GDB или IDA). Это если программа не пытается «сломаться» и в виртуальной машине тоже.
Если вам повезло, и программа не против запуститься в виртуальной машине, то с помощью GDB можно походить по её внутренностям и даже сопоставить их с исходными текстами, если в бинарнике есть отладочная информация в формате DWARF.
Смотрим на ядро Windows через WinDbg и GDB
Если же программа собрана в Visual Studio, то показать отладочную информацию GDB не сможет. Про имена API-функций Windows в листинге тоже можно забыть. Здесь мог бы пригодиться WinDbg, но как им подключиться к виртуальной машине, если отладочный режим ОС нас не устраивает?
Вот было бы здорово, если бы в какой-нибудь виртуальной машине был бы интерфейс удалённой отладки, подобный тому, что использует GDB, — подумали мы и написали такой модуль для виртуальной машины QEMU. Всё выложено в виде исходников [1] и бинарников для Windows [2], так что каждый может попробовать его применить.
Про удалённую отладку с помощью WinDbg уже есть материал на хабре [3]. Там рассказывается как включить отладочный режим Windows и использовать его для удалённого подключения WinDbg. Отладчик подключается через виртуальный COM-порт, связанный с именованным каналом Windows.
Обычный порошок против отладочного сервера, встроенного в QEMU
В нашем случае QEMU без участия гостевой системы подключится к этому именованному каналу, чтобы выдавать отладчику информацию о происходящем внутри Windows. Сама операционная система не знает, что её отлаживают, поэтому отладка получается в некотором роде скрытой.
Чтобы запустить QEMU в таком режиме, понадобится ключ -windbg:
qemu-system-i386.exe -windbg pipe:windbg -hda disk.qcow2
После этого QEMU будет ждать подключения отладчика. Его нужно запустить такой командой:
windbg.exe -b -k com:pipe,baud=115200,port=\.pipewindbg,resets=0
Когда начнётся эмуляция, выбираем режим работы без отладочного модуля Windows:
Через некоторое время ОС инициализирует всё что нужно для работы отладчика, он остановит работу эмулятора и предложит вводить команды:
WinDbg сразу же пишет, что не найдена символьная информация: Symbol search path is: *** Invalid ***
Загрузить символьную информацию о системных библиотеках можно парой команд .symfix и .reload.
То же самое можно сделать и через меню File -> Symbol File Path..., где указать пути к временному каталогу и серверу Microsoft srv*d:tmp*http://msdl.microsoft.com/download/symbols
Теперь WinDbg будет знать названия внутренних структур и функций Windows и имена библиотечных функций. Они показываются в листингах, к ним можно привязывать точки останова и т.п.
После этого продолжим загрузку ОС командой g и запустим там нужные приложения, а потом сломаем их. Теперь если нажать Ctrl+Break в окне WinDbg, то эмуляция приостанавливается, а в отладчике включается командная строка, в которой можно делать всякие полезные вещи.
Например, команда !dlls покажет нам список модулей, загруженных в текущем процессе:
Понятие «текущий процесс» появляется при удалённой отладке. Ведь ОС постоянно переключает виртуальные адресные пространства, привязанные к задачам. Команда !dml_proc выводит список запущенных процессов:
Видно, что в системе работает приложение CrashMe (я взял его с сайта www.windbg.info [4]). Запущенного отладчика в системе оно не нашло.
Чтобы поотлаживать эту программу, переключимся в ее контекст с помощью команды .process. Её параметр — это адрес структуры EPROCESS, который указан в первой колонке вывода команды !dml_proc. Проверить, что всё получилось, можно командой !peb:
Чтобы отладка была комфортной, загрузим символьную информацию и укажем где хранятся исходные тексты этой программы. После этого командой bp можно создать точку останова:
.sympath+ E:QemuImagesCrashMedebug
.reload /user
.srcpath+ E:QemuImagesCrashMeCrashMe
bp CCrashMeDlg::OnBnClicked_CallingConvention
g
Теперь при нажатии кнопки «Test Calling Conventions» на форме приложения мы вывалимся в отладчик:
Дальше можно открыть файл с исходным текстом:
Проверить стек вызовов:
Или изучить локальные переменные:
Другая полезная возможность WinDbg — фильтры событий. Можно поставить прерывание работы на разные исключительные ситуации, на событие загрузки модуля или запуска приложения. Обычно сообщения о таких событиях посылает отладочный сервер в гостевой системе, а в WinDbg настраиваются фильтры для них в окне Debug->Event Filters:
Перехват событий и исключительных ситуаций мы пока не реализовывали никак.
Если с int 3 или делением на 0 довольно просто разобраться на уровне эмулятора, то для выявления создания процесса надо проделать намного больше работы.
Все остальные функции WinDbg должны хорошо работать для 32-битных систем, а 64-битными мы пока толком не занялись, сейчас готовим патчи, чтобы все эти функции были доступны всем пользователям QEMU по умолчанию.
Ссылки
Автор: Павел Довгалюк
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/254193
Ссылки в тексте:
[1] исходников: https://github.com/ispras/qemu/tree/windbg
[2] бинарников для Windows: https://github.com/ispras/qemu/releases
[3] хабре: https://habrahabr.ru/post/130213/
[4] www.windbg.info: http://www.windbg.info
[5] resources.infosecinstitute.com/kernel-debugging-qemu-windbg/#gref: http://resources.infosecinstitute.com/kernel-debugging-qemu-windbg/#gref
[6] habrahabr.ru/post/187522: https://habrahabr.ru/post/187522/
[7] www.windbg.info/doc/1-common-cmds.html: http://www.windbg.info/doc/1-common-cmds.html
[8] www.windbg.org: http://www.windbg.org/
[9] habrahabr.ru/company/jugru/blog/326454: https://habrahabr.ru/company/jugru/blog/326454/
[10] Источник: https://habrahabr.ru/post/327128/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.