Генерация COM vtable в IDA

Генерация COM vtable в IDA 🐍

В процессе разбора одного из вариантов Snake Keylogger нужно было разобраться, какие managed-методы нативный модуль вызывает через COM-интерфейсы. Это означает, что нам нужно было вручную насоздавать какое-то количество структур. И еще нам бы хотелось видеть сигнатуру каждого метода, а их много.

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

• OLE/COM Object Viewer (oleview)
• MIDL компилятор (midl.exe, входит в Visual Studio Build Tools)
• IDA

📂 Воспользуемся OLE/COM Object Viewer (oleview), чтобы открыть mscorlib.tlb и найти интересующие нас интерфейсы. Путь к нему:

C:\Program Files (x86)\Windows Kits\10\bin\<версия>\x86\oleview.exe
Code language: YAML (yaml)

В mscorlib.tlb находятся COM-описания базовых managed-интерфейсов. Этот файл обычно лежит в каталоге:

C:\Windows\Microsoft.NET\Framework\<Версия>\mscorlib.tlb
Code language: YAML (yaml)

Открыв файл, мы видим его IDL — Interface Definition Language (скриншот 1).

🫱 Далее находим в дереве oleview нужные нам интерфейсы (например, _AppDomain). Выгружаем их IDL и по примеру IDL для mscorlib (скриншот 1) собираем свой (скриншот 2). Пример минимального IDL представлен на скриншоте 3 (количество методов урезано).

На этом шаге нужно немного почистить файл:

1️⃣ Форварднуть интерфейсы, определить value-типы. Интерфейсы можно форвардить, так как указатель на них всегда одинакового размера. Но value-типы требуется определить полностью, иначе будет ошибка unsatisfied forward declaration. Мы обойдемся заглушками: для сигнатур методов этого достаточно.

2️⃣ Отредактировать объявления функций.

На скриншоте 4 мы видим, как объявлен COM-метод GetEvents_2. Это вариант перегрузки метода GetEvents. Нас интересует атрибут custom, который говорит, что этот метод — реализация .NET-метода Assembly.GetEvents и calling convention (_stdcall). Если мы оставим все так, как в сыром IDL, компилятор будет ругаться, потому что:

1️⃣ В IDL не пишут _stdcall: это появится в сгенерированном .h.

2️⃣ Атрибуты метода (включая custom(…)) должны быть только в квадратных скобках перед возвращаемым типом метода (в нашем случае — HRESULT).

Поэтому меняем содержимое на следующее:
[custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, "GetEvents")] HRESULT GetEvents_2([in] BindingFlags bindingAttr, [out, retval] SAFEARRAY(_EventInfo*)* pRetVal);

Далее воспользуемся командой для сборки:

midl /h appdomain.h appdomain.idl

👍 Если вы все сделали правильно и сборка прошла успешно, вывод будет выглядеть так, как на скриншоте 5.

Теперь у нас есть готовый хедер, который мы отправим в IDA. Но сначала в хедер-файл добавим инклюды (до содержимого appdomain.h), чтобы IDA clang знал все имена и не ругался на атрибуты или макросы (скриншот 6):

После этого загружаем файл в IDA: File → Load file → Parse C header file…

IDA использует встроенный clang для преобразования C-заголовков в базу типов IDA. Соответственно, в Options → Compiler нужно указать include-пути, чтобы clang видел стандартные заголовки (пути к стандартным хедерам Windows SDK). Обычно это выглядит так:

-target x86_64-pc-win32
-x c++
-std=c++11
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\ucrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\um"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\shared"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\winrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\cppwinrt"
Code language: plaintext (plaintext)

После в Local Types появятся методы _AppDomain, _Type и другие (скриншот 7).

👀 На скриншоте 8 мы видим вызовы двух методов интерфейса _Type. Делаем encr_resource указателем на структуру _Type (ее vtable мы видели на скриншоте 7) и понимаем, какие методы вызываются (скриншот 9). Все аргументы схлопнулись под правильной сигнатурой, которую нам не нужно прописывать вручную.

#tip #malware #reverse
@ptescalator