3.4 Продвинутое общение
Рассмотренный нами в предыдущей главе метод общения драйвера с внешним миром, конечно, прост и понятен, но что делать, если задача требует не просто считать\записать данные, а произвести несколько более сложные действия, например, передать управляющие команды, обеспечить диалог драйвер-приложение или выполнить что-либо ещё специфическое для данного драйвера? Можно, конечно, при желании все организовать через ReadFile\WriteFile, но есть более универсальное решение - функция http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx. Для примера, рассмотрим следующие функции:| Код | Procedure CapsLockOn;assembler;
asm
mov ax,0edh
out 60h,ax
mov ax,4
out 60h,ax
end;
function InPort(port:word):byte;assembler;stdcall;
asm
mov dx,port
in al,dx
mov Result,al
end; |
| Код | const
IOCTRL_CODE_MESSAGE_RUN_ROUTINE_1 = (1 shl 3) or METHOD_NEITHER;
IOCTRL_CODE_MESSAGE_RUN_ROUTINE_2 = (2 shl 3) or METHOD_NEITHER;
...
procedure IoControlDriver_CapsOn;
var
bytesret:cardinal;
p:pointer;
i:integer;
begin
p:=@i;
Integer(p^):=Integer(@CapsLockOn);
DeviceIoControl(hDevice,IOCTRL_CODE_MESSAGE_RUN_ROUTINE_1,
p,4,
nil,0,bytesret,nil);
...
end;
procedure IoControlDriver_KbPortIn;
var
bytesret:cardinal;
p:pointer;
i:integer;
w:integer;
begin
p:=@i;
Integer(p^):=Integer(@InPort);
w:=0;
DeviceIoControl(hDevice,IOCTRL_CODE_MESSAGE_RUN_ROUTINE_2,
p,4,
@w,4,bytesret,nil);
// После этого вызова bytesret содержит количество возвращенных байт,
// w - возвращенное значение:
...
end; |
Расшифровка полей управляющего слова следующая:
1. Поле DeviceType определяет тип объекта-устройства, которому предназначен запрос. Это тот самый тип устройства, который передается функции IoCreateDevice()
при создании устройства.
2. Поле Function идентифицирует конкретные действия, которые должно предпринять устройство при получении запроса. Значения поля Function должны быть уникальны внутри устройства.
3. Поле Method указывает метод передачи буферов данных. Для задания этого поля можно использовать константы:
METHOD_BUFFERED = 0;
METHOD_IN_DIRECT = 1;
METHOD_OUT_DIRECT = 2;
METHOD_NEITHER = 3;
4. Поле Access указывает тип доступа, который должен был быть запрошен (и предоставлен) при открытии объекта-файла, для которого передается данный код Управления вводом/выводом. Возможные значения: FILE_ANY_ACCESS = $0000, FILE_READ_ACCESS = $0001 и FILE_WRITE_ACCESS = $0002.
Для нас самое важное значение имеют биты 0-2 (в которых указывается метод передачи буфера) и 3-12 (в которых указывается передаваемый код управления драйвером). Остальные байты можно формировать по желанию и необходимости, в нашем случае такой необходимости нет.
Теперь рассмотрим обработку этого запроса со стороны драйвера:
Для начала необходимо назначить функцию-обработчик данного запроса. Это выполняется, как обычно, в DriverEntry:
| Код | ...
DriverObject^.MajorFunction[IRP_MJ_DEVICE_CONTROL]:=DeviceIOControlDispatch;
... |
| Код | const
IOCTRL_RUN_ROUTINE_1 = (1 shl 3) or 3;
IOCTRL_RUN_ROUTINE_2 = (2 shl 3) or 3;
type
TUserRoutine1 = procedure;
TUserRoutine2 = function (port:word):byte;stdcall;
...
function DeviceIOControlDispatch(
const DeviceObject : PDEVICE_OBJECT;
const Irp : PIRP) : NTSTATUS; stdcall;
var
pIrp : PIO_STACK_LOCATION;
iBuffer:pointer;
inputBufLength:ULONG;
outputBufLength:ULONG;
FunctionCode:ULONG;
RetStr:ANSI_STRING;
RetCode:integer;
begin
pIrp := Irp^.Tail.Overlay.IRPStruct2.IRPUnion2.CurrentStackLocation;
inputBufLength := pIrp^.Parameters.DeviceIoControl.InputBufferLength;
outputBufLength := pIrp^.Parameters.DeviceIoControl.OutputBufferLength;
iBuffer:=pIrp^.Parameters.DeviceIoControl.Type3InputBuffer;
FunctionCode := pIrp^.Parameters.DeviceIoControl.IoControlCode;
case FunctionCode of
IOCTRL_RUN_ROUTINE_1:
begin
...
TUserRoutine1(iBuffer^);
end;
IOCTRL_RUN_ROUTINE_2:
begin
...
RetCode:=TUserRoutine2(iBuffer^)($60);
RtlMoveMemory(Irp^.UserBuffer,@RetCode,4);
...
end;
end;
IRP.IoStatus.Status:=STATUS_SUCCESS;
IRP.IoStatus.Information:=4;
IoCompleteRequest(IRP,IO_NO_INCREMENT);
Result:=STATUS_SUCCESS;
end; |
4. Из жизни
Предыдущая глава была посвящена решению проблем, выдуманных нами фактически на пустом месте. Это не сильно интересно, поэтому в данной главе я хотел бы разобрать пару примеров, основа которых была мной написана для реальных проектов. Надеюсь, они помогут в более быстром освоении темы. Оба примера будут рассмотрены, естественно, на языке Delphi, но если кому интересно - то в соответствующих папках в архиве можно найти и C++ - варианты этих драйверов, которые собираются из-под DDKXP.
4.1 Пример №1: Перехват клавиатуры
Рассмотрим частный пример распространенной проблемы глобального перехвата клавиатуры - отлов сочетания CAD. В операционных системах семейства NT это сочетание является единственным, которое не отлавливается из user-mode (исключение составляет способ отлова через MSGINA.dll, но он обладает своими недостатками), поэтому я и взял его для примера, но в принципе данный подход применим для отлова любого требуемого сочетания клавиш. Основной идеей является установка драйвера-фильтра клавиатуры верхнего уровня. Что такое драйвер-фильтр и чем верхний уровень отличается от нижнего я объяснять не буду, об этом можно почитать в соответствующих источниках, но суть сводится к тому, что мы "посадим" наш драйвер поверх устройства основного драйвера клавиатуры, оставляя всю рутинную работу по работе с портами ввода-вывода и первичной обработке результатов ему, а сами будем только фильтровать запросы, проходящие между режимом пользователя и этим драйвером. Данный пример был написан мною по мотивам и на основе широко известного примера Ctrl2Cap, но с некоторыми изменениями, на которых я остановлюсь подробнее. Исходный код драйвера находится в прилагающемся архиве в папке под названием KbdIntcpt.
Итак, рассмотрим функцию DriverEntry: первым делом мы создаем объект "устройство", как было показано ранее, с помощью функций IoCreateDevice и IoCreateSymbolicLink. | Код | ...
DriverObject^.DriverUnload := DriverUnload;
RtlInitUnicodeString(deviceNameUnicodeString, NT_DEVICE_NAME);
Status := IoCreateDevice(DriverObject,sizeof (DEVICE_EXTENSION),
@deviceNameUnicodeString,FILE_DEVICE_UNKNOWN,
0,false,deviceObject);
RtlInitUnicodeString(deviceLinkUnicodeString, DOS_DEVICE_NAME);
Status:=IoCreateSymbolicLink(@deviceLinkUnicodeString,@deviceNameUnicodeString);
... |
| Код | extension := PDEVICE_EXTENSION(deviceObject^.DeviceExtension);
extension^.DriverObject := DriverObject;
RtlInitUnicodeString(kbdname,'\Device\KeyboardClass0');
Status := IoAttachDevice(deviceObject, @kbdname,extension^.DeviceObject);
if (extension^.DeviceObject<>nil)and(NT_SUCCESS(Status)) then
begin
deviceObject^.Flags := deviceObject^.Flags or DO_BUFFERED_IO;
deviceObject^.Flags := deviceObject^.Flags and (not DO_DEVICE_INITIALIZING);
end; |
Затем идёт кусок кода по созданию объекта-евента:| Код | const
EVENT_NAME = '\BaseNamedObjects\'+DRIVER_NAME+'Event';
var
UnloadEvent : PKEVENT = nil;
UnloadEventHandle : THandle = 0;
EventName : UNICODE_STRING;
...
RtlInitUnicodeString(EventName, EVENT_NAME);
UnloadEvent := IoCreateNotificationEvent(@EventName, @UnloadEventHandle); |
| Код | for i:=0 to IRP_MJ_MAXIMUM_FUNCTION do
DriverObject^.MajorFunction[i] := DriverDispatchGeneral;
DriverObject^.MajorFunction[IRP_MJ_READ] := DriverRead;
DriverObject^.MajorFunction[IRP_MJ_CREATE] := DriverCreate;
DriverObject^.MajorFunction[IRP_MJ_CLOSE] := DriverClose; |
| Код | procedure DriverUnload(const DriverObject : PDRIVER_OBJECT); stdcall;
var
deviceLinkUnicodeString : UNICODE_STRING;
extension : PDEVICE_EXTENSION;
begin
UnloadProcess:=true;
extension := DriverObject.DeviceObject^.DeviceExtension;
...
KeWaitForSingleObject(UnloadEvent,Executive,KernelMode,false,nil);
ZwClose(UnloadEventHandle);
...
RtlInitUnicodeString(deviceLinkUnicodeString, DOS_DEVICE_NAME);
IoDeleteSymbolicLink(@deviceLinkUnicodeString);
IoDetachDevice(extension^.DeviceObject);
IoDeleteDevice(DriverObject.DeviceObject);
...
end; |
| Код | Var
UnloadProcess : boolean = false;
...
function ReadCompleteCallback(const DeviceObject : PDEVICE_OBJECT;
const Irp : PIRP;
const Context : PVoid) : NTSTATUS; stdcall;
var
...
begin
...
// Помечаем IRP как ожидающий завершения, если требуется
if (Irp^.PendingReturned) then IoMarkIrpPending(Irp);
KeSetEvent(UnloadEvent, 0, false);
Result:=Irp^.IoStatus.Status;
end;
function DriverRead(const DeviceObject : PDEVICE_OBJECT;
const Irp : PIRP) : NTSTATUS; stdcall;
var
current_irp_stack : PIO_STACK_LOCATION;
next_irp_stack : PIO_STACK_LOCATION;
begin
...
current_irp_stack := IoGetCurrentIrpStackLocation(Irp);
next_irp_stack := IoGetNextIrpStackLocation(Irp);
next_irp_stack^ := current_irp_stack^;
KeClearEvent(UnloadEvent);
if not UnloadProcess then IoSetCompletionRoutine(Irp, ReadCompleteCallback, DeviceObject, true, true, true);
Result:=IoCallDriver(PDEVICE_EXTENSION(DeviceObject^.DeviceExtension)^.DeviceObject,
Irp);
end; |
а) Дело в том, что в обработке драйвера клавиатуры всегда находится как минимум один IRP-пакет, поэтому когда мы присоединяемся в цепочку фильтров - то неизбежно пропустим тот пакет, который уже сидит в обработке, потому что на него еще не была установлена наша функция возврата. Фактически это означает что первое после загрузки драйвера нажатие клавиши не будет отловлено.
б) Опять же, благодаря тому, что в обработке всегда наличествует как минимум один пакет, в момент выгрузки драйвера в этом пакете сидит привязанная к нему наша callback-функция ReadCompleteCallback (если, конечно, между загрузкой и выгрузкой драйвера происходили нажатия клавиш, что должно было привести к вызову IoSetCompletionRoutine) и если мы выгрузимся до того, как драйвер клавиатуры вызовет эту функцию, мы неизбежно получим BSOD. Для того, чтобы этого избежать - я и использовал евент, сигнализирующий о получении очередного пакета и не дающий выгрузиться драйверу, если он не сработал. Этой же цели служит булевская переменная UnloadProcess, которая не дает установить процедуру завершения, если пошел процесс выгрузки драйвера. Но все это приводит к небольшому неудобству - при выгрузке драйвера необходимо нажать клавишу. Упомянутый мной пример Ctrl2Cap этот момент обходит другим способом - он для своей установки\выгрузки требует перезагрузки компьютера, кому интересно - может погуглить и посмотреть, как это реализовано.
в) Ну и еще один достаточно тонкий момент, который не относится именно к данному драйверу, но который я впервые испытал на своей шкуре именно в этом месте, поэтому упомяну здесь. Дело в том, что callback-функция ReadCompleteCallback вызывается на уровне http://www.books.everonit.ru/PogrammingSistemSecurity/Glava%202/Index26.htm, в то время как остальной код драйвера по умолчанию работает на самом низкоприоритетном уровне PASSIVE_LEVEL. Это различие аукнулось тем, что попытка записи в лог-файл внутри этой функции приводила к BSOD, потому что работа с файлами производится тоже на уровне PASSIVE_LEVEL. Поэтому при разработке механизмов взаимодействия рекомендую не забывать о таких вещах, как приоритет выполнения.
Ну а что же собственно выполняет функция ReadCompleteCallback? Её код выглядит следующим образом:| Код | Const
// Коды отлавливаемых клавиш
VK_CONTROL = $1D;
VK_ALT = $38;
VK_DELETE = $53;
// Константа для работы с KEYBOARD_INPUT_DATA
KEY_BREAK = 1;
var
CtrlAlt : array [0..1] of boolean = (false,false);
...
function IsKeyDown(pKeyData:Pointer;const Key:byte):boolean;
begin
Result:=(KEYBOARD_INPUT_DATA(pKeyData^).MakeCode = Key) and
((KEYBOARD_INPUT_DATA(pKeyData^).Flags and KEY_BREAK) = 0);
end;
function IsKeyUp(pKeyData:Pointer;const Key:byte):boolean;
begin
Result:=(KEYBOARD_INPUT_DATA(pKeyData^).MakeCode = Key) and
((KEYBOARD_INPUT_DATA(pKeyData^).Flags and KEY_BREAK) > 0);
end;
function ReadCompleteCallback(const DeviceObject : PDEVICE_OBJECT;
const Irp : PIRP;
const Context : PVoid) : NTSTATUS; stdcall;
var
KeyData : PKEYBOARD_INPUT_DATA;
num_keys, i : integer;
begin
...
if NT_SUCCESS(Irp^.IoStatus.Status) then
begin
KeyData:=Irp^.AssociatedIrp.SystemBuffer;
num_keys := integer((Irp^.IoStatus.Information div sizeof(KEYBOARD_INPUT_DATA)));
for i:=0 to num_keys-1 do
begin
if IsKeyDown (Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_CONTROL) then CtrlAlt[0]:=true
else if IsKeyUp(Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_CONTROL) then CtrlAlt[0]:=false;
if IsKeyDown (Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_ALT) then CtrlAlt[1]:=true
else if IsKeyUp(Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_ALT) then CtrlAlt[1]:=false;
if (IsKeyDown(Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_DELETE) or
IsKeyUp (Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),VK_DELETE)) and (CtrlAlt[0] and CtrlAlt[1]) then
begin
RtlZeroMemory(Pointer(Cardinal(KeyData)+i*SizeOf(KEYBOARD_INPUT_DATA)),sizeof(KEYBOARD_INPUT_DATA));
{$IFDEF __DEBUG__}
DbgPrint(DRIVER_NAME+' : ' + 'Ctrl+Alt+Delete Key Sequence Is Blocked!!!');
{$ENDIF}
end;
end;
end;
// Помечаем IRP как ожидающий завершения, если требуется
if (Irp^.PendingReturned) then IoMarkIrpPending(Irp);
KeSetEvent(UnloadEvent, 0, false);
Result:=Irp^.IoStatus.Status;
end; |
4.2 Пример №2: Перехват системных функций ядра
Ну и еще один пример, который я хотел бы рассмотреть - это пример осуществления перехвата функций ядра на примере функции http://msdn.microsoft.com/en-us/library/ms801001.aspx для обеспечения "невидимости" требуемого файла\папки. Делается это путем модификации системной таблицы служебных дескрипторов (SSDT). Данный метод зачастую называют "грязным", но иногда приходится прибегать и к таким способам, благо из режима ядра это разрешено. Этот пример тоже был написан под большим влиянием найденного в сети драйвера, осуществляющего какую-то работу с таблицей дескрипторов, но, к сожалению, я уже не помню что это был за драйвер, поэтому авторство идеи оставляю за "неизвестным героем". Исходный код находится в прилагающемся архиве в папке под названием FileHider и полный код я приводить здесь не буду, просто поясню основные моменты.
Итак, хук устанавливается в функции DriverEntry с помощью экспортируемой недокументированной глобальной переменной http://he4dev.e1.bmstu.ru/HookSysCall/ (со скачиваемыми примерами рекомендую проявлять осторожность - антивирус ругается на скомпилированные файлы, принимая rootkit-технологии за зверьё). Тонким моментом здесь является использование бита WP системного регистра cr0 при установке\снятии хука. Этот бит управляет защитой от записи системных страниц памяти. Если у вас на машине стоит физической памяти больше 256 Мб (WinXP) или 128 Мб (Win2k), тогда данный код никак не влияет на функциональность (т.е. если его убрать - никаких отличий не найти). Но! Если на машине стоит памяти меньше чем указано - тогда система осуществляет защиту системных страниц памяти от записи и при попытке что-то записать в область системного кода будет генерироваться исключение и это вызовет BSOD (подробнее об этом можно прочитать в журнале Хакер, глава "http://www.xakep.ru/post/40549/default.asp"). Именно для того, чтобы это учесть, и сделан сброс бита WP перед записью в область системного кода - тогда системные страницы с любом случае будут доступны для модификации.
После установки хука - остальное дело техники. Все запросы, благодаря наличию в SSDT адреса нашей функции, перенаправляются ей, затем она тут же вызывает оригинальную системную процедуру по сохраненному указателю, а возвращаемый результат анализирует на предмет соответствия требуемым условиям. В примере я сделал проверку по соответствии имени файла\папки определенному шаблону, а также закомментировал проверку по атрибутам файла. Анализ осуществляется путем перебора всего списка элементов типа http://msdn.microsoft.com/en-us/library/ms791526.aspx, который возвращается оригнальной функцией ZwQueryDirectoryFile. В случае выполнения условий проверки - проверяемый элемент удаляется из списка путем перенаправления указателя предыдущего элемента списка на следующий. При завершении работы драйвера - в функции DriverUnload адрес оригинальной процедуры возвращается на место :
Конечно, для того, чтобы полностью "спрятать" требуемый файл - просто перехвата ZwQueryDirectoryFile недостаточно, даже если спрятать папку таким образом - в неё все равно можно будет зайти путем ввода команды "cd". Но это уже вопрос наращивания функциональности.
5. Заключение
Данная статья не охватывает многие и многие аспекты темы разработки драйверов. Например, не были рассмотрены вопросы обмена с реальными устройствами, не приведено примеров работы с файловой системой на низком уровне, даже не рассмотрен вопрос построения inf-файлов, необходимых для полноценной установки устройства в систему, или других узкоспециализированных моментов. Но и не в этом её цель. Целью является дать дополнительный импульс для тех, кто хочет осилить эту необъятную тему, с тем, чтобы дальше можно было двигаться самостоятельно, дать начальные познания при помощи привычной "среды", а также дать своеобразные "направляющие" для правильного составления конкретных вопросов на соответствующих форумах. Если не получилось - прошу строго не судить
P.S. Выражаю огромную благодарность http://vingrad.ru/@Snowy за помощь в подготовке и оформлении статьи. |
! очень познавательно! и с меня +
)
) свой первый драйвер на основе исходников уважаемого ama_kid.