Управление устройствами в Windows. Управление драйверами устройства Управление сервисами и драйверами windows

Введение

Здесь описывается программирование служб
в ОС Windows (я также буду употреблять термин
"сервис",что равносильно термину "служба"),
приводится пример использования для
загрузки драйверов или руткитов.

Сервисы

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

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

SC_HANDLE OpenSCManager(LPCTSTR lpMachineName, LPCTSTR
lpDatabaseName, DWORD dwDesiredAccess);

LPCTSTR lpMachineName - указатель на строку,
завершающуюся нулём, указывающую на имя
локального компьютера. Этот параметр
можно установить в NULL.

LPCTSTR lpDatabaseName- указатель на строку,
завершающуюся нулём, содержащая в себе имя
открываемой базы данных.Этот параметр
также слудует установить в NULL.

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

SC_MANAGER_ALL_ACCESS - стандартные права доступа к БД.
SC_MANAGER_CONNECT - разрешает соединяться с БД SCM.
SC_MANAGER_CREATE_SERVICE- разрешает создание новых
сервисов.

Создав связь с БД SCM,вы можете управлять
сервисами.

Функция OpenService служит для получения
описателя службы. Учтите, что эта функция не
создаёт службу, для создания службы служит
CreateService, а открывает уже созданную ранее
службу.

SC_HANDLE OpenService(SC_HANDLE hSCManager, LPCTSTR
lpServiceName, DWORD dwDesiredAccess);

SC_HANDLE hSCManager - указатель, возвращенный
функцией OpenSCManager.

LPCTSTR lpServiceName - имя открываемого сервиса.

DWORD dwDesiredAccess- права с которыми мы можем
открыть службу. Вот некоторые из них:

SERVICE_ALL_ACCESS- это стандартные права доступа.
SERVICE_START-разрешает запуск работы сервиса.
SERVICE_STOP-разрешает остановку работы сервиса.

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

Эта функция нужна для создания сервиса (службы).

SC_HANDLE CreateService(SC_HANDLE hSCManager, LPCTSTR
lpServiceName, LPCTSTR lpDisplayName, DWORD dwDesiredAccess, DWORD dwServiceType,
DWORD dwStartType, DWORD dwErrorControl, LPCTSTR lpBinaryPathName, LPCTSTR
lpLoadOrderGroup, LPDWORD lpdwTagId, LPCTSTR lpDependencies, LPCTSTR
lpServiceStartName, LPCTSTR lpPassword);

Первый параметр (hSCManager) указывает на
указатель, возвращенный функцией OpenSCManager.
Следующие два параметра указывают на
строки, содержащие имя создаваемой службы и
имя, которое будет использовано
пользовательским интерфейсом. Следующий
параметр содержит в себе флаги,
определяющие права доступа к службе. Здесь
используются те же флаги, что и в функции
OpenService. В большинстве случаев понадобится
установка этого флага в SERVICE_ALL_ACCESS. Параметр
dwServiceType определяет тип создаваемого
сервиса. В данном случае нужно установить
его в SERVICE_KERNEL_DRIVER, что в свою очередь
означает, что сервис будет управлять
драйвером уровня ядра. Другие же значения
означают, что это будет драйвер файловой
системы и т.д. Параметр dwStartType очень важен, т.к
определяет способ старта службы. В нашем
случае его следует установить в
SERVICE_BOOT_START или SERVICE_AUTO_START, что означает
практически одно и тоже - запуск службы во
время запуска самой операционной системы.
Параметр dwErrorControl указывает на способ
обработки возникающих ошибок, в нашем
случае его следует установить в SERVICE_ERROR_NORMAL.
Следующий параметр - lpBinaryPathName - указатель на
завершающуюся нулём строку, указывающую на
полный путь к драйверу (в нашем случае
руткиту), которым будет управлять служба.
Следующие пать параметров следует
установить в NULL, т.к. они не важны в данном
случае.

Для запуска службы существует функция
StartService.

BOOL StartService(SC_HANDLE hService, DWORD
dwNumServiceArgs, LPCTSTR *lpServiceArgVectors);

SC_HANDLE hService - указатель службы, возвращённый
функцией CreateService или OpenService. Параметр
dwNumServiceArgs содержит в себе число параметров,
указанных в масиве lpServiceArgVectors. В этом
массиве указываются параметры, которые
будут переданы службе. Учтите, что сервисы
драйверов не используют этот параметр,
поэтому два последних параметра в нашем
случае нужно установить в NULL. Если функция
выполнилась успешно, то она возвращает
ненулевое значение. Функции для остановки
службы нет, но ее можно легко написать с
использованием функции ControlService:

BOOL ControlService(SC_HANDLE hService, DWORD dwControl,
LPSERVICE_STATUS lpServiceStatus);

Параметр dwControl содержит флаги, с помощью
которых вы задаёте, что нужно сделать со
службой. Если вам нужно остановить работу
службы, то можете установить её в
SERVICE_CONTROL_STOP. С помощью этой функции можно и
более удобно останавливать и запускать
службу. Например для паузы работы сервиса,
установите параметр dwControl в SERVICE_CONTROL_PAUSE, а
для продолжения работы в SERVICE_CONTROL_CONTINUE.
Параметр lpServiceStatus - указатель на структуру
SERVICE_STATUS, куда заносится текущий статус
службы. Установите его в NULL, если вам не
важен текущий статус работы службы. Эта
функция возвращает ненулевое значение при
успешном выполнении.

Я перечислил все необходимые функции для
загрузки руткитов (драйверов).Для закрытия
структуры DT SCM используйте функцию
CloseServiceHandle. Она принимает единственный
параметр - DT SCM, т.е. описание, возвращённое
функцией OpenSCManager.

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

#define rootkitname "myrootkit" //
задаём имя нашего руткита
BOOL StopRootkit(SC_HANDLE hService) // Объявляем
функции остановки и старта работы службы
BOOL StartRootkit(SC_HANDLE hService)//
int main()
{
SC_HANDLE hManager,hService; // описатели
SCM базы и службы
LPVTSTR rootkpath="C:\myrootkit.sys"; //
полный путь к нашему руткиту

hManager=OpenSCManager(NULL,NULL,SC_MANAGER_ALL_ACCESS); // создаём
связь с БД SCM

if (hManager) // если всё в порядке
{

hService=CreateService(hManager, rootkitname,rootkitname,SERVICE_ALL_ACCESS,
SERVICE_KERNEL_DRIVER, SERVICE_BOOT_START,SERVICE_ERROR_NORMAL, \rootkpath,
NULL,NULL,NULL, NULL,NULL,NULL); // создаём
службу, управляющую нашим руткитом

if (hService) // всё в порядке?
{
StartService(hService,NULL,NULL); // запускаем
созданную службу, тем самым запуская наш
руткит
}

if (StopRootkit(hService)) // если
остановка прошла успешно,
{
StartRootkit(hService);// то заново
запускаем её
};
CloseServiceHandle(hManager); // закрываем
DT SCM (БД SCM).
}
BOOL StopRootkit(SC_HANDLE hService)
{
BOOL ok=true;
if (hService)
{
ok=ControlService(hService,SERVICE_CONROL_STOP,NULL); // вызываем
функцию ControlService с флагом SERVCE_CONTROL_STOP, тем
if (!ok) // самым останавливая
работу сервиса
{
ok=false;
};
};
return ok;
}

BOOL StartRootkit(SC_HANDLE hService)
{
BOOL ok=true;
if (hService)
{
ok=ControlService(hService,SERVICE_CONTROL_START,NULL); // вызываем
функцию ControlService с флагом SERVCE_CONTROL_START, тем
if (!ok) //с амым запуская службу
{
ok=false;
};
};
return ok;
}

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

Советую вам прочитать в книге Свена
Шрайбера ("Недокументированные
возможности Windows 2000") раздел, посвящённый
программированию драйверов. Также
рекомендую цикл статей от Four-F, посвященный
созданию драйверов в Windows NT. Посмотрите
статью от Ms-Rem,"Перехват API функций в Windows NT
(часть 3).Нулевое кольцо". И не проходите
мимо rootkit.com .

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

Прежде всего посмотрим текущий порядок запуска системы с помощью программы LoadOrder от Sysinternals. Программа покажет нам, что и в каком порядке загружается при запуске операционной системы.

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

Драйверы

В качестве подопытного возьмем драйвер Microsoft ACPI (Advanced Configuration and Power Interface), который отвечает за обнаружение аппаратного обеспечения и управление питанием. Задача ACPI - обеспечить взаимодействие между операционной системой и аппаратным обеспечением, поэтому драйвер ACPI загружается в самом начале.

Программа Loadorder предоставляет довольно ограниченную информацию о порядке загрузки, поэтому за более точными данными идем в реестр. У каждого драйвера и Windows-сервиса есть свой раздел в ветви реестра HKLM\SYSTEM\CurrentControlSet\Services. Названы разделы по имени драйвера\сервиса, соответственно нам нужен раздел ACPI.

За порядок загрузки драйвера отвечают три параметра реестра. Основной параметр Start - определяет тип запуска драйвера. Вот правила, по которым драйверы устанавливают значение своего параметра Start:

Драйверы, которые должны загружаться системным загрузчиком при запуске операционной системы, указывают значение Start равное 0 (запуск при загрузке системы). Пример - драйверы системных шин и драйвер файловой системы, используемый при загрузке системы;
Драйвер, который не требуется непосредственно для загрузки системы, указывает в Start значение, равное 1 (запуск системой). Пример - стандартный драйвер видеокарты (VgaSave);
Драйвер, не обязательный для загрузки системы, устанавливает значение Start равным 2 (автозапуск). Пример - драйвер многосетевого UNC-npoвайдера (Multiple UNC Provider, MUP), поддерживающий UNC-имена удаленных ресурсов (типа \\Computer\Share);
Драйверы, не обязательные для работы операционной системы (например, драйверы сетевых адаптеров), указывают значение Start равным 3 (запуск по требованию).

Также драйверы устройств могут использовать параметры Group и Tag для контроля порядка своей загрузки при запуске системы. Параметр Group драйверы\сервисы используют, чтобы указать группу, к которой они принадлежат, а порядок загрузки групп определяется параметром List, находящимся в разделе HKLM\SYSTEM\ CurrentControlSet\Control\ServiceGroupOrder\.

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

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

Посмотрев на порядок загрузки, можно подумать что сначала загружаются драйверы с меньшими значениями Tag, потом - с большими, но это не совсем так. Приоритет значений параметров Tag в рамках группы определяется в разделе HKLM\SYSTEM\CurrentControlSet\Control\GroupOrderList.

Для примера откроем двоичный параметр Boot Bus Extender, который соответствует одноименной группе, к которой относится и драйвер ACPI. Параметр представляет из себя набор двойных слов (по 4 байта каждое). Первое слово (выделено красным) задает общую длину переменной (количество двойных слов), в нашем примере 06. Остальные двойные слова как раз и являются тэгами. Драйверу ACPI соответствует тэг, равный 01 (выделен зеленым).

Приоритетность тега определяется не значением тега, а его положением : чем выше расположен тэг, тем выше его приоритет в группе, и тем выше приоритет драйвера, которому этот тэг соответствует. А поскольку 01 выше остальных тегов, то и драйвер ACPI загружается первым в группе.

Сервисы

Порядок загрузки Windows-сервисов несколько отличается от порядка загрузки драйверов. В качестве примера возьмем сервис aвтоматического обновления (wuauserv). Он не особо критичен для работы системы и поэтому грузится в последнюю очередь.

Опять идем в реестр. Параметры запуска сервиса находятся в разделе HKLM\SYSTEM\CurrentControlSet\Services\wuauserv. Я выделил два основных параметра, отвечающих за порядок загрузки данного сервиса.

Windows-сервисы запускаются диспетчером управления сервисами (Service Control Manager, SCM) в соответствии со значением параметра Start . Параметр этот для сервисов может принимать следующие значения:

Авто запуск (2) - сервис запускается автоматически, сразу после запуска основного SCM-процесса Services.exe;
Запуск по требованию (3) - сервис запускается при необходимости, по требованию какого либо сервиса или программы;
Отключено (4) - сервис отключен и не запускается ни при каких условиях.

Значения 0 (запуск при загрузке системы) и 1 (запуск системой) для сервисов не могут быть указаны, только для драйверов устройств.

Кроме того, начиная с Windows Vista\Server 2008 для сервисов появился еще один режим запуска - отложенный автозапуск. Отвечает за него параметр DelayedAutoStart = 1, который который указывает SCM произвести автоматический старт данного сервиса с задержкой.SCM запускает службы, для которых выбран отложенный запуск, после загрузки сервисов, отмеченных для автозапуска.

Режимом запуска сервисов можно управлять не только из реестра, но и в графическом режиме, из консоли Службы (Services).

Так же как и драйверы, Windows-сервисы могут использовать параметр Group в своем разделе реестра, чтобы указать группу, к которой они принадлежат. Сейчас, для наглядности, возьмем наш сервис wuauserv, находящийся в самом конце списка загрузки. С помощью ключа Group поместим его в группу Event Log, перезагрузимся и посмотрим порядок загрузки в Loadorder. Как видите, порядок изменился и wuauserv поднялся с последнего места, загрузившись сразу после своего одногруппника - службы eventlog. Правда порядок размещения внутри группы изменить уже не получится, т.к. Tag для сервисов не используется.

И еще один параметр, который косвенно влияет на порядок загрузки сервисов - DependOnService . Он указывает, от каких сервисов зависит данный сервис. Соответственно сервис не загружается, пока не будут загружены сервисы, перечисленные в DependOnService.

Зависимости работают следующим образом - если сервисы находятся в одной группе, то зависимый сервис перемещается в конец списка и запускается после сервисов, от которых зависит. Если же группы разные, то сервис просто не запустится, а SCM выдаст ошибку.

Более наглядно это показано в оснастке Службы, где на вкладке Зависимости (Dependency) указаны как сервисы, от которых зависит данный сервис, так и сервисы, зависящие от него.

Порядок загрузки драйверов и сервисов в Windows

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

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

Драйверы

В качестве подопытного возьмем драйвер Microsoft ACPI (Advanced Configuration and Power Interface), который отвечает за обнаружение аппаратного обеспечения и управление питанием. Задача ACPI - обеспечить взаимодействие между операционной системой и аппаратным обеспечением, поэтому драйвер ACPI загружается в самом начале.

Драйверы, которые должны загружаться системным загрузчиком при запуске операционной системы , указывают значение Start равное 0 (запуск при загрузке системы ). Пример - драйверы системных шин и драйвер файловой системы, используемый при загрузке системы;
Драйвер, который не требуется непосредственно для загрузки системы , указывает в Start значение, равное 1 (запуск системой ). Пример - стандартный драйвер видеокарты (VgaSave);
Драйвер, не обязательный для загрузки системы , устанавливает значение Start равным 2 (автозапуск ). Пример - драйвер многосетевого UNC-npoвайдера (Multiple UNC Provider, MUP), поддерживающий UNC-имена удаленных ресурсов (типа );
Драйверы, не обязательные для работы операционной системы (например, драйверы сетевых адаптеров), указывают значение Start равным 3 (запуск по требованию ).

Также драйверы устройств могут использовать параметры Group и Tag для контроля порядка своей загрузки при запуске системы. Параметр Group драйверы\сервисы используют, чтобы указать группу, к которой они принадлежат, а порядок загрузки групп определяется параметром List , находящимся в разделе HKLM\SYSTEM\ CurrentControlSet\Control\ServiceGroupOrder\.

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

Приоритетность тега определяется не значением тега, а его положением: чем выше расположен тэг, тем выше его приоритет в группе, и тем выше приоритет драйвера, которому этот тэг соответствует. А поскольку 01 выше остальных тегов, то и драйвер ACPI загружается первым в группе.

Сервисы

Кроме того, начиная с Windows Vista\Server 2008 для сервисов появился еще один режим запуска - отложенный автозапуск. Отвечает за него параметр DelayedAutoStart = 1 , который который указывает SCM произвести автоматический старт данного сервиса с задержкой. SCM запускает службы, для которых выбран отложенный запуск, после загрузки сервисов, отмеченных для автозапуска.

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

Категория ~ Технические советы – Игорь (Администратор)

Примечание : Несмотря на то, что на сайте нет четкого заявления о совместимости с 64-разрядными версиями Windows, программа вполне отлично себя чувствовала в 64-битной Windows 7.

Интерфейс ServiWin сделан достаточно просто и удобно. Вы можете переключаться между списками драйверов и сервисов системы (меню иконок - первые две), а так же настраивать отображение и порядок следования 16 возможных колонок. Кроме того, утилита позволяет экспортировать данные в html и открывать соответствующие ключи реестра для драйверов или служб. Щелкнув правой кнопкой мыши на драйвере или сервисе, появится контекстное меню, которое позволяет не только управлять состоянием, но осуществлять поиск в Google, что несомненно пригодится тем, кому необходимо разобраться с происходящем на компьютере. Так же у вас имеется возможность определять тип запуска драйвера (отключено, автоматически и т.д.). На самом деле, это достаточно редкая функция. В основном, утилиты данного класса позволяют только лишь просматривать список драйверов.

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

Примечание : Конечно, вы можете создать резервную копию диска или Windows, и после этого вносить изменения. Однако, все равно проявляйте осторожность, так как отключение таких драйверов, как, например, клавиатуры, может сыграть с вами злую шутку.

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

Устройства и драйверы для них делятся на две категории: с поддержкой PnP и без. Для большинства PnP-устройств драйвер есть на CD с Windows Server 2003. При установке нового устройства система автоматически находит для него драйвер и выделяет для него ресурсы (запросы на прерывание IRQ и каналы прямого доступа к памяти DNA). В случае если системе не удается найти подходящий драйве, она запросит его у пользователя, а устройство в консоли Диспетчер задач будет помечено восклицательным знаком в желтом треугольнике. Если системе вообще не удается определить тип устройства, тогда запрос на драйвер не выдается, а устройство помечается знаком вопроса в желтом треугольнике как неизвестное.

Для обновления конфигурации устройств служит оснастка Диспетчер устройств. Ее можно использовать в двух видах: с деревом устройств, с деревом ресурсов для устройств (настраивать ресурсы вручную не рекомендуется). Оснастку Диспетчер устройств для редактирования конфигурации можно использовать только на локальном компьютере, на удаленном компьютере она работает в режиме только для чтения. Для получения подробной сводки об устройствах и драйверах, можно использовать утилиту командной строки DriverQuery.

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

Начиная с Windows 2000 драйвера для устройств имеют цифровую подпись, которая показывает, что файл не был изменен в процессе использования. Некоторые драйвера могут не иметь цифровой подписи. В случае если драйвер не подписан, можно настроить три варианта действия системы: Пропускать (устанавливать драйвер, даже если нет подписи. Доступен только для администратора), Предупреждать (спрашивать у пользователя устанавливать ли драйвер), Блокировать (не устанавливает драйвера без цифровой подписи).

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

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