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

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

Напомню, что в этой статье не приводится гарантированного способа снятия виртуализации, я просто хочу поделиться опытом анализа ВМ который позволяет более-менее понять что-то о работе ВМ и может быть полезен при анализе схожих реализаций. 

Применение Triton

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

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

Я начал смотреть, с какой стороны лучше попробовать применить Tenet и наткнулся на любимую директорию examples, а именно на пример dead_store_elimination. В этом примере в качестве исходного обфусцированного кода даже приводится фрагмент с обфускацией VMProtect, очень здорово. 

Не изобретая велосипед, я решил воспользоваться указанным примером, в котором, по сути, все сводится к применению метода simplify из TritonContext. Сразу вспоминается это:

При этом возникает такая же проблема, как и с Miasm - нужно как-то получить полный листинг обработчика инструкции ВМ. Наиболее доступным способом мне показалось воспользоваться трассой, снятой с исполнения кода обработчика. На тот момент у меня была трасса, снятая для инструмента Tenet (это инструмент для анализа трассы, о нем я расскажу при описании следующего этапа). К сожалению, в этой трассе нет самих дизассемблированных команд внутри обработчика, но были необходимые eip. Трасса для Tenet в виде текста выглядит так:

Таким образом, у нас есть значения eip (то есть адреса каждой выполненной в ходе работы анализируемого ПО инструкции). Если мы хотим получить трассу конкретного обработчика ВМ, очевидно, что нам надо читать значения в eip c того места, где eip равен адресу обработчика инструкции ВМ. Массив с адресами обработчиков мы нашли в начале первой части статьи. В анализируемом мною образце есть обработчик, который расположен по адресу 0x50260c. В качестве последней инструкции трассы работы обработчика возьмем инструкцию, предшествующую MAIN_LOOP (упоминается в первой части статьи, в моем случае MAIN_LOOP расположен по адресу 0x50281a). Таким образом, из трассы Tenet извлекаем такой участок:

esp=0x2f1f51c,eip=0x50260c,mr=0x2f1f4f0:0c265000	// начало трассы обработчика 0x50260c
edx=0x502621,eax=0x2d,eip=0x50260f
eip=0x502610
eax=0xf4,eip=0x502612,mr=0x4ccbdf:f4
edx=0x502608,eip=0x502615
eax=0xc2,eip=0x502617
esp=0x2f1f518,eip=0x502618,mw=0x2f1f518:82020000
esp=0x2f1f514,eip=0x50261d,mw=0x2f1f514:a2a1d06c
eip=0x503a1b
esi=0x4ccbe0,eip=0x503a1c
edx=0x5000c2,eip=0x503a20
edx=0x500000,eip=0x503a23
eax=0xc3,eip=0x503a25
eip=0x503a26
eax=0x3d,eip=0x503a28
edx=0x5000ff,eip=0x503a2a
esp=0x2f1f510,eip=0x503a2e,mr=0x2f1f518:82020000,mw=0x2f1f510:82020000
esp=0x2f1f4f0,eip=0x503a2f,mw=0x2f1f4f0:1cf5f102e0cb4c00e0f5f10210f5f10236fe7f08ff0050002ac44c003d000000
edx=0x5000fe,eip=0x503a31
eax=0x3c,eip=0x503a33
edx=0x50c4fe,eip=0x503a35
esp=0x2f1f4ec,eip=0x5030c5,mw=0x2f1f4ec:3a3a5000
edx=0x5031fe,eip=0x5030c7
edx=0x500001,eip=0x5030cb
ebx=0x87ffe0a,eip=0x5030cd
eip=0x5030cf
edx=0x500002,eip=0x5030d0
edx=0x500200,eip=0x5030d4
edx=0xf7ccccd8,eip=0x5030d7,mr=0x2f1f5e0:d8ccccf7
esp=0x2f1f4e8,eip=0x5030da,mr=0x2f1f4ec:3a3a5000,mw=0x2f1f4e8:3a3a5000
esp=0x2f1f4e4,eip=0x5034f9,mw=0x2f1f4e4:df305000
eip=0x5034fa
eip=0x5034fe
ebp=0x2f1f5e4,eip=0x503501
esp=0x2f1f4e0,eip=0x502759,mw=0x2f1f4e0:06355000
esp=0x2f1f4dc,eip=0x50275a,mw=0x2f1f4dc:06020000
eip=0x502760,mw=0x2f1f4dc:d610
eip=0x502763,mw=0x2f1f558:d8ccccf7
esp=0x2f1f4d8,eip=0x502764,mw=0x2f1f4d8:d8ccccf7
eip=0x502767,mw=0x2f1f4d8:d8ccccf7
esp=0x2f1f4d4,eip=0x50276c,mw=0x2f1f4d4:3d582af5
eip=0x502770,mw=0x2f1f4d4:d4f4
esp=0x2f1f51c,eip=0x502774	// конец трассы обработчика 0x50260c
eip=0x50281a				// eip указывает на MAIN_LOOP

Чтобы получить выполненные машинные команды в виде массива из последовательностей байт (так как пример Triton по упрощению кода работает именно с таким форматом), воспользуемся IDAPy:

import idautils
import idaapi
import idc


def GetInsnLen(ea):
	insn = ida_ua.insn_t()
	inslen = ida_ua.decode_insn(insn, ea)
	if inslen:
    		return inslen
	return 0

eips = '''0x50260c
0x50260f
0x502610
0x502612
0x502615
0x502617
0x502618
0x50261d
0x503a1b
0x503a1c
0x503a20
0x503a23
0x503a25
0x503a26
0x503a28
0x503a2a
0x503a2e
0x503a2f
0x503a31
0x503a33
0x503a35
0x5030c5
0x5030c7
0x5030cb
0x5030cd
0x5030cf
0x5030d0
0x5030d4
0x5030d7
0x5030da
0x5034f9
0x5034fa
0x5034fe
0x503501
0x502759
0x50275a
0x502760
0x502763
0x502764
0x502767
0x50276c
0x502770
0x502774'''


eips_list = eips.split('\n')
for i in range(len(eips_list)):
	eips_list[i] = int(eips_list[i], 16)
	print(idc.get_bytes(eips_list[i], GetInsnLen(eips_list[i])))

На выходе мы получаем каждую команду из трассы обработчика инструкции ВМ, чтобы далее передать эти команды в скрипт Triton. При этом все инструкции перехода (JMP, JZ, JNE и т.д.) нужно удалить, а инструкции вызова (CALL) заменить на PUSH (как будто на стек кладется адрес возврата). 

Результат далёк от успеха

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

Несмотря на то что чистую и доступную версию обработчика инструкции ВМ мы все-таки не получили, все равно у нас теперь есть листинг этого обработчика, можно попытаться посмотреть, что же в нем происходит (сделаем это на немного “упрощенной” версии, не зря же мы использовали скрипт из примеров Triton ?). 

Напомню, что в первой части статьи мы узнали, что esi является VM_EIP, то есть указателем на байт в байткоде. Акцентируя внимание на ключевых моментах листинга можно заметить, что в AL загружается значение из [ESI] (1),  далее с ним происходят какие-то преобразования (2), спустя ряд преобразований EAX используется как смещение (3), по которому записывается значение, полученное из [EBP] (4), при этом EBP также увеличивается на 4 (5):

0x50260c: xadd al, dl
0x50260f: mov al, byte ptr [esi]	// 1
0x502611: shl dl, 3
0x502614: xor al, bl			// 2
0x502616: pushfd
0x502617: push 0x6cd0a1a2
0x50261c: pushal
0x50261d: movzx dx, al
0x502621: sete dl
0x502624: inc al
0x502626: neg al
0x502628: dec dl
0x50262a: push dword ptr [esp + 4]
0x50262e: pushal
0x50262f: dec al
0x502631: push dword ptr [esp + 4]
0x502635: push 0x6cd0a1a2
0x50263a: xor bl, al
0x50263c: mov edx, dword ptr [ebp]		// 4
0x50263f: push dword ptr [esp]
0x502642: push dword ptr [esp + 4]
0x502646: push 0x6cd0a1a2
0x50264b: add ebp, 4				// 5
0x50264e: push dword ptr [esp + 4]
0x502652: push 0x6cd0a1a2
0x502657: pushfd
0x502658: mov word ptr [esp], 0x10d6
0x50265e: mov dword ptr [eax + edi], edx	// 3
0x502661: push edx
0x502662: mov dword ptr [esp], edx
0x502665: push 0xf52a583d
0x50266a: mov word ptr [esp], sp
0x50266e: lea esp, [esp + 0x48]

Посмотрев на указанные участки, можно предположить, что в указанном обработчике читается один операнд размером 1 байт, этот операнд используется как указатель на виртуальном стеке (VM_ESP), по которому кладется значение из [EBP].  Инструкцию можно записать примерно так: 

MOV VM_EIP:OP1, [EBP]

Таким образом, примерно стали ясны ключевые компоненты, применяемые при работе обработчика инструкции ВМ. Теперь стало понятнее, что именно нужно искать, чтобы понять, что делают остальные обработчики, поэтому я решил не пытаться с помощью Triton до конца снять обфускацию, а воспользоваться ручным анализом работы каждого обработчика, используя Tenet.

Анализ трассы с помощью Tenet и без помощи Tenet

Как уже было сказано выше, Tenet это инструмент для анализа трассы с помощью IDA. В репозитории подробно описано, как снимать трассу анализируемого ПО, я использовал Intel Pin, для него уже собран необходимый модуль.

В результате снятия трассы в нужном формате и передачи ее плагину Tenet мы получаем очень удобную возможность перемещаться в оба направления по трассе, внимательно отслеживая интересующие нас изменения:

Теперь, после того как мы немного разобрались в работе обработчиков инструкций ВМ, а также получили возможность удобно анализировать трассу, можно приступить к анализу каждого обработчика, чтобы разобраться в выполняемом байткоде.

Предварительно я также записал все выполненные инструкции виртуальной машины -
то есть снял трассу ВМ. Это можно сделать с помощью отладчика x64dbg или другими способами (например, тем же Pin). Если делать это через x64dbg, то нужно не забыть установить плагин ScyllaHide и выбрать профиль защиты от VMProtect. Это можно сделать, установив точку останова инструкции RET, которая совершает переход с обработчику инструкции ВМ (об этом подходе рассказывалось в первой части), и добавив запись в лог значения, лежащего на стеке (адрес обработчика очередной команды из байткода ВМ):

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

В итоге мы получим трассу ВМ, адреса в которой необходимо перевернуть (преобразовать из-за Little Endian):

Конечно, нам также нужно получить количество уникальных адресов, т.е. количество всех обработчиков, используемых в трассе, чтобы потом, например, отмечать, какие мы проанализировали и что именно в них происходит. Получилось 31, не очень много.

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

Конечно, хотелось бы еще увидеть конкретные значения операндов, но для этого нужно было реализовать декодирование, которое происходит в каждом обработчике, поэтому я решил пока посмотреть трассу в представленном виде.

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

Запись в память в моем примере реализовывается обработчиком 0x502b1c, вот пример участка трассы, где запись реализовывается 4 раза подряд:

Если посмотреть внутрь обработчика, то можно увидеть, что сама запись в память происходит при выполнении MOV [EAX], EDX. Значения обоих операндов берутся из [EBP+0] и [EBP+4] соответственно, которые заполняются на предыдущих командах ВМ (видно на трассе).

Tenet позволяет нам полистать каждое выполнение инструкции записи, поэтому мы можем увидеть, что же именно записывается. Например, в примере ниже после четырех вызовов записалась строка “kernel32.dll”:

Таким же образом записываются другие строки с названиями функций, например, CreateFileA или MapViewOfFile. Где-то ранее они, очевидно, расшифровываются. Так мы уже понимаем, какие функции WinAPI вредонос будет использовать и для чего.

Функция перехода характеризуется просто записью в ESI значения из [EBP+0], по которому также происходит запись при выполнении инструкций ВМ ранее. Переходы помогают нам найти циклы, то есть какие-то повторяющиеся операции вроде проверок, записей, расшифровки и т.д.:

Подсчет контрольной суммы происходит для выбранного участка памяти в цикле внутри обработчика инструкции ВМ с помощью арифметических операций (например, XOR или SHL, в анализируемом мною образце это обработчик по адресу 0x50288e).

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

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

То есть в этом разрыве проводилась проверка и распаковка кода с основным функционалом, после чего началась запись распакованного кода в секции .text и .data (инструкции записи теперь вызываются интервалом в 4-5 шагов и в значительно бОльшем объеме).

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

Также заметно, что само дизассемблированное и декомпилированное представления  в районе OEP и далее стали гораздо более читаемыми:

Теперь можно продолжить анализ исследуемого образца.

Заключение

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

Таким образом, при анализе работы ВМ мы использовали понемногу несколько инструментов, при этом если постараться, то скорее всего можно было бы решить задачу только одним из них.