Для дальнейшего понимания сути поста надо запомнить [...]]]> Пришлось мне тут анализировать один элементарный руткит, никак не срасталось у нашего анти-руткита кое-что с ним. Ерунда в принципе, бага не критичная, но разобраться все-таки стоило. В последнее время не часто выпадает возможность проанализировать что-либо, но тут повезло, можно немного отвлечься от процесса исследования/кодинга.

Для дальнейшего понимания сути поста надо запомнить то, что дата компиляции дроппера — 27 февраля 2011 года, т.е. сэмпл далеко не старый.

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

Вот такой код я обнаружил в драйвере:

char __cdecl IsDebug()
{
  UNICODE_STRING DestinationString; // [sp+4h] [bp-Ch]@4
  PVOID Object; // [sp+Ch] [bp-4h]@4
 
  if ( KdDebuggerEnabledAddr && *(_BYTE *)KdDebuggerEnabledAddr )
    return 1;
  RtlInitUnicodeString(&DestinationString, L"\\Driver\\NTICE");
  if ( !ObReferenceObjectByName(&DestinationString, 0x40u, 0, 0x1F01FFu, IoDriverObjectType, 0, 0, &Object) )
  {
    ObfDereferenceObject(Object);
    return 1;
  }
  return 0;
}

Способ, основанный на проверке переменной KdDebuggerEnabled, известен очень давно, однако, проверка на наличие в системе активного отладчика Soft(Win)Ice (наличие драйвера NTICE) — это что-то из ряда вон выходящее. Неужели авторы думают, что антивирусные лаборатории до сих пор используют этот устаревший инструмент?

Что ж, живы еще олдскул разработчики в родных селениях!

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

Прежде всего, необходимо внести в переменные окружения компьютера разработчика параметр _NT_KD_FILES, где значением этого параметра должен быть полный путь до специального map-файла, например, c:\driver.map.

Далее, необходимо создать сам map-файл по выбранному пути с указанным содержимым:

map
\??\C:\1\driver32.sys
C:\project_path\out\debug\driver32.sys

Во второй строке файла необходимо указать путь до драйвера на тестовой машине (например, на VmWare) так, как он указан в реестре данного сервиса. В третьей строке необходимо указать путь до файла на машине разработчика. Удобнее всего использовать путь до директории, в которой собирается chk-билд драйвера. Тогда каждый раз при загрузке драйвера будет загружена его новая версия.

В отладчике процесс загрузки драйвера с машины разработчика на тестовую машину выглядит примерно так:

kd> g
KD: Accessing ‘C:\project_path\out \debug\driver32.sys’ (\??\C:\1\driver32.sys)
File size 91K…………………………….
MmLoadSystemImage: Pulled \??\C:\1\driver32.sys from kd

Удачной отладки!

Одной из самых объемных и важных документаций для программистов является MSDN (Microsoft Developer [...]]]> Грамотная документация — залог здоровья и спокойствия программиста. Причем начинающего программиста, так как эксперт проблему решит намного быстрее. Да и не впервой ему — эксперту сталкиваться с плохой документацией, с программным кодом без комментариев и прочими неприятными вещами.

Одной из самых объемных и важных документаций для программистов является MSDN (Microsoft Developer Network). Для низкоуровневых программистов и программистов драйверов существует отдельная документация WDK (Windows Driver Kit), входящая в состав MSDN. В MSDN перечислены функции, параметры к ним, объяснения, примеры кода и многое другое.

Большая документация — сложный продукт. В любом сложном продукте есть недочеты, ошибки и недоработки. Встречаются они и в документации, ведь все мы люди, все мы ошибаемся. Недавно с такой ошибкой столкнулся и я.

Операционная система Windows предоставляет специальную функцию, которая позволяет отслеживать различные изменения в системном реестре указанного ключа. Она есть как в пользовательском пространстве (RegNotifyChangeKeyValue), так и в пространстве ядра (ZwNotifyChangeKey), там, где работает сама операционная система и драйверы. Этой функцией пользуются как антивирусные продукты, так и вредоносный код, который следит за изменениями своих вредоносных веток антивирусом (обычно это лечение веток реестра).

Прототип функции ZwNotifyChangeKey выглядит так:

NTSTATUS
ZwNotifyChangeKey(
  __in HANDLE  KeyHandle,
  __in_opt HANDLE  Event,
  __in_opt PIO_APC_ROUTINE  ApcRoutine,        // указатель на нашу функцию
  __in_opt PVOID  ApcContext,
  __out PIO_STATUS_BLOCK  IoStatusBlock,
  __in ULONG  CompletionFilter,
  __in BOOLEAN  WatchTree,
  __out_bcount_opt(BufferSize) PVOID  Buffer,
  __in ULONG  BufferSize,
  __in BOOLEAN  Asynchronous
  );

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

Функция должна быть определена так:

typedef VOID (NTAPI *PIO_APC_ROUTINE) ( IN PVOID ApcContext, IN PIO_STATUS_BLOCK IoStatusBlock, IN ULONG Reserved )

Не суть важно, что тут за параметры, главное — то, что у функции три аргумента. Это важно.

В одном из драйверов мне понадобилась эта функция. Я написал весь сопутствующий код, использовал функцию, скомпилировал драйвер, положил в нужное место и запустил. Система упала в BSOD. ‘Не в первый и не в последний раз’, — подумал я и начал проверять параметры функции. Все было идеально, все было правильно, а BSOD повторялся каждый раз.

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

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

typedef struct _WORK_QUEUE_ITEM {
    LIST_ENTRY List;
    PWORKER_THREAD_ROUTINE WorkerRoutine;        // указатель на нашу функцию
    __volatile PVOID Parameter;
} WORK_QUEUE_ITEM, *PWORK_QUEUE_ITEM;

Функция должна быть определена так:

typedef VOID (*PWORKER_THREAD_ROUTINE)( IN PVOID Parameter )

И она принимает всего один параметр. И это важно.

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

Ошибки бывают разные, но ошибки в документации дорогого стоят. До следующих ошибок, а они обязательно будут.

Оригинал

В режиме пользователя можно использовать функцию ExitWindowsEx (она ведет [...]]]> В некоторых ситуациях возникает потребность перезагрузить операционную систему прямо из ядра. Когда-то давно я был озадачен такой проблемой, так как существующие способы меня не устраивали по разным причинам. Пришлось копать, искать и спрашивать. В результате были найдены следующие варианты.

В режиме пользователя можно использовать функцию ExitWindowsEx (она ведет в NtShutdownSystem):

BOOL WINAPI ExitWindowsEx(
                                       __in UINT    uFlags,
                                       __in DWORD dwReason
);

Все достаточно подробно описано в MSDN и, конечно, не забываем про включенную Shutdown привилегию.

Давайте рассмотрим варианты, которые нам доступны из режима ядра. Один из них — это использование функции NtShutdownSystem. Конечно, она недокументированная. Реализация для Windows XP выглядит так (вот такой забавный switch, видимо из-за оптимизаций):

NTSTATUS __stdcall NtShutdownSystem(SHUTDOWN_ACTION Action)
{
        POWER_ACTION SystemAction;
 
        if ( Action )
        {
                if ( Action == 1 ) // ShutdownReboot
                {
                        SystemAction = 5; // PowerActionShutdownReset
                }
                else // ShutdownPowerOff
                {
                        if ( Action != 2 )
                                return STATUS_INVALID_PARAMETER;
                        SystemAction = 6; // PowerActionShutdownOff
                }
        }
        else // ShutdownNoReboot
        {
                SystemAction = 4; // PowerActionShutdown
        }
 
        return NtSetSystemPowerState(SystemAction, PowerSystemSleeping3, 0xC0000004u);
}

typedef enum _POWER_ACTION {
        PowerActionNone            = 0,
        PowerActionReserved,
        PowerActionSleep,
        PowerActionHibernate,
        PowerActionShutdown,
        PowerActionShutdownReset,
        PowerActionShutdownOff,
        PowerActionWarmEject
} POWER_ACTION, *PPOWER_ACTION;

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

Следующий вариант — это использовать функцию HalReturnToFirmware. Она также описана в MSDN.

VOID HalReturnToFirmware(IN FIRMWARE_REENTRY Routine);

На вход функция может принимать параметр HalRebootRoutine, что нам собственно и нужно. Честно говоря, меня смущает то, что написано в MSDN:

Requirements

Versions: Available in Microsoft Windows Server 2003 and Windows XP.

DLL: Requires Hal.dll.

Под рукой у меня нет Hal.dll от Windows 2000, так что проверить экспортируется ли она или нет, я не могу, а память меня подводит.

Третий вариант — это спровоцировать BSOD. Шучу, шучу, но близко к правде. Вызовем KeBugcheckEx с параметром POWER_FAILURE_SIMULATE. KeBugcheckEx — это обыкновенная обертка над KeBugcheck2:

int __stdcall KeBugCheck2(int BugCheckCode, )
{
 
        if ( BugCheckCode == POWER_FAILURE_SIMULATE )
        {
                KiScanBugCheckCallbackList();
                HalReturnToFirmware(3); // HalRebootRoutine
        }
}

Знакомая картина, но помнится мне, что на каких-то системах вместо перезагрузки я получал самый натуральный BSOD с POWER_FAILURE_SIMULATE. Однако поехали дальше.

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

WRITE_PORT_UCHAR( (PUCHAR )0x64, 0xFE ); // пишем RESET
                                         // в контроллер клавиатуры

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

Кто какие способы знает еще?

С:\path1\path2\path3>build -g BUILD: Compile and Link for x86 BUILD: Loading c:\winddk\6001\build.dat… BUILD: Computing Include file dependencies: BUILD: Start time: Fri Feb 06 [...]]]> Рано или поздно драйверописатель сталкивается с необходимостью использовать в своем проекте чужой код. Обычно, для сборки драйвера используется утилита BUILD, идущая в поставке WDK. Буквально недавно я столкнулся с очевидной проблемой данного инструмента:

С:\path1\path2\path3>build -g
BUILD: Compile and Link for x86
BUILD: Loading c:\winddk\6001\build.dat…
BUILD: Computing Include file dependencies:
BUILD: Start time: Fri Feb 06 15:50:51 2009
errors in directory С:\path1\path2\path3

Ignoring invalid directory prefix in SOURCES= entry: D:\somepath1\somepath2\somepath3\somepath4\somepath5\file.c

Поиск в гугле вывел меня на ветку форума OSR Online:

«Welcome to the wonderful world of BUILD. It can only deal with source code in the same or parent directory of the «sources» file. It cannot use source files from arbitrary locations.»

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

1. Чужой код должен быть реализован в виде статической библиотеки. У этого способа есть как очевидные плюсы, так и очевидные минусы. Одним из минусов я считаю то, что разработчику, который пишет код для вас, придется часто собирать эту самую библиотеку или это должна делать build-машина.
2. Использовать преимущества современных систем управления версиями. Проблема решается выкачиванием нужного проекта в директорию, которая доступна инструменту BUILD. Свою проблему я решил именно так. Конечно, не стоит забывать и о синхронизации выкаченных файлов.

Иногда на форумах появляются вопросы, в которых люди спрашивают можно ли управлять инструментом BUILD. В MSDN есть отдельный раздел, посвященный этой утилите: Win32 and COM Development -> Windows Driver Kit -> Driver Development Tools -> Tools for Building Drivers -> Build. Подраздел Build Utility Macros самый интересный.