Пишем драйвер для КолибриОС

From KolibriOS wiki
Jump to navigation Jump to search

ПРЕДУПРЕЖДЕНИЕ: Данная статья устарела и нуждается в обновлении/переписывании. Сейчас ядро использует для драйверов формат PE вместо MS COFF.

Вступление

Предупреждение 1. Прежде чем писать драйвер, хорошо подумайте, нельзя ли обойтись средствами прикладных API, в частности, функций работы с оборудованием 46 и 62. Во-первых, от ошибки в кривом приложении пострадает только это кривое приложение, а кривой драйвер способен без особого труда обрушить всю систему. Во-вторых, для приложений можно вылавливать баги в отладчике MTDBG, обладающем определёнными возможностями, а для драйверов этот путь закрыт (разве что встроенный отладчик эмулятора Bochs, но он заведомо непригоден для отладки с реальным железом), так что единственным средством остаётся отладочный вывод на доску отладки BOARD со всеми недостатками.

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

Предупреждение 2. Драйвера, естественно, тесно связаны с ядром. А в ядро КолибриОС вносятся изменения несколько раз в неделю. Разумеется, большинство изменений никак не касается драйверной подсистемы, но иногда добавляются/исчезают/изменяются важные системные функции, экспортируемые драйверам. Поэтому если вы возьмёте и скомпилируете прилагаемый к статье код, то, возможно, он прямо в таком виде работать не будет. Так что внимательно читайте текст - я постараюсь выделить по возможности все причины неработоспособности в будущем и требуемые модификации. Прилагаемый к статье код рассчитан на ревизию {{#svn_rev:450}}, последнюю на момент написания этих строк (в дистрибутиве 0.6.5.0 работать в таком виде не будет).

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

Описание работы с драйверной подсистемой

Драйверная подсистема позволяет загружать драйвера в формате PE и работать с ними. Для загрузки драйверов в ядре придусмотрено 2 сисфункции 68.16 и 68.21 а для управления драйвером сисфункция 68.17. Драйвер должен иметь экспортируемую функцию START, которая должна возвращать хандлер стуктуры драйвера в случае успеха, и ноль в случае, если драйвер не загружен. Для работы с ядром драйверу нужно импортировать некоторые функции ядра, которые экспортируются ядром как core.dll.

Драйвер

Специально для желающих написать свой драйвер предоставляется каркас драйвера. Он находится в svn-репозитории вместе с ядром, точнее, в папке {{#svn:/kernel/trunk/drivers|svn://kolibrios.org/kernel/trunk/drivers}}. Ну что же, давайте посмотрим ({{#svn:/kernel/trunk/drivers/sceletone.asm|sceletone.asm из #450|450}}):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                                              ;;
;; Copyright (C) KolibriOS team 2004-2007. All rights reserved. ;;
;; Distributed under terms of the GNU General Public License    ;;
;;                                                              ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;driver sceletone

format PE DLL native 0.05
entry START

section '.flat' code readable writable executable
include 'proc32.inc'
include 'struct.inc'
include 'macros.inc'
include 'peimport.inc'

Ну, "Copyright" - он и есть копирайт, комментарий в следующей строке извещает нас, куда же мы собственно попали, это неинтересно. Дальше мы должны известить компилятор, какой формат мы хотим получить. Драйвера должны иметь формат PE. В общем, так должно быть для всех драйверов. Дальше идёт указание функции START как точки входа, которую вызовет ядро после загрузки драйвера. После этого объявляется секция ".flat", в которой будет располагаться код нашего драйвера, после объявления секции подключаем вспомогательные файлы. {{#svn:/drivers/proc32.inc|proc32.inc}} содержит макросы для определения и вызова стандартных процедур (proc/endp, stdcall/ccall/invoke/cinvoke, local для создания локальных переменных) и находится в той же папке, что и {{#svn:/drivers/sceletone.asm|sceletone.asm}}. Его можно включать или не включать, макросы оттуда можно использовать или не использовать, в этой статье они используются, чтобы не усложнять восприятие (вообще говоря, при стремлении к максимальной эффективности использование макросов может повредить, но это тема отдельных жарких споров). {{#svn:/drivers/peimport.inc|peimport.inc}} содержит объявления для всех экспортируемых функций ядра. Загляните туда, ничего сложного там нет, просто куча стереотипных конструкций. На самом деле (в смысле того, как разрешается импорт при загрузке драйвера) список всех экспортируемых функций и данных ядра находится в файле {{#svn:/kernel/trunk/core/exports.inc|core/exports.inc}} (метка kernel_export), так что если вам как программисту ядра вдруг понадобиться что-нибудь своё экспортировать, лезьте туда (ну и {{#svn:/drivers/peimport.inc|peimport.inc}} отредактируйте из вежливости к другим).

Внимание! Здесь появляется возможность несовместимости: если вы используете какие-нибудь функции, которых (ещё или уже) нет в ядре, на которое вы рассчитываете, ядро откажется грузить ваш драйвер (ругнувшись на доске отладки нехорошим словом на ненашем языке "unresolved" с указанием имени функции).

Ну что же, идём дальше:

DEBUG        equ 1 ; for debug output in board

API_VERSION     equ 0  ;version api this driver

STRIDE       equ 4      ;size of row in devices table

SRV_GETVERSION  equ 0 ; number function for get api version

Это просто объявление констант

proc START c, state:dword, cmdline:dword

        cmp     [state], 1
        jne     .exit
.entry:

        push    esi
     if DEBUG
        mov     esi, msgInit
        invoke  SysMsgBoardStr
     end if
        call    detect
        pop     esi
        test    eax, eax
        jz      .fail

        invoke  RegService, my_service, service_proc
        ret
.fail:
.exit:
        xor     eax, eax
        ret
endp

Выше мы создали функцию START, о которой уже говорилось ранее. Данная функция принимает 2 аргумента: state и cmdline и возвращает хэндлер драйвера, полученный при вызове RegService. Если эта функция вернёт 0, то это будет означать, что драйвер по какой-то причине не может работать(либо нет нужного оборудования, с которым бы драйвер работал, либо его что-то не устраивает и чтобы не создавать ошибок, драйвер завершает работу). Параметр cmdline это командная строка в ascii кодировке, state это действие, которое требует от этой функции ядро. Сейчас есть 2 значения этого аргумента: DRV_ENTRY передаваемое при старте драйвера и DRV_EXIT передаваемое при завершении работы драйвера. Эти значения определены в файле {{#svn:/drivers/macros.inc|macros.inc}}. В этом коде вызываются 2 функции импортированные из ядра: SysMsgBoardStr и RegService, функции ядра имеют разные соглашения о вызовах, в одних параметры передаются через стек, в других через регистры. Описание соглашения о вызовах функций можно найти в файле {{#svn:/kernel/trunk/core/exports.inc|exports.inc}} в комментарии возле экспортируемой функции.

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

Процедуру service_proc экспортировать совершенно ненужно, о её размещении ядро узнаёт по другим каналам, о ней речь пойдёт ещё позже.

Последняя порция констант

DEBUG      equ 1

STRIDE     equ 4      ;size of row in devices table

(из которых первая включает код отладочного вывода в блоках if DEBUG/end if, последняя нужна для красоты и ни для чего больше) и мы наконец-то переходим к изучению кода:

section '.flat' code readable align 16

означает ровно-таки то, что написано;

proc START stdcall, state:dword

           cmp [state], 1
           jne .exit
.entry:

     if DEBUG
           mov esi, msgInit
           call SysMsgBoardStr
     end if

           stdcall RegService, my_service, service_proc
	   ret
.fail:
.exit:
           xor eax, eax
           ret
endp

Это код процедуры инициализации/финализации. При загрузке драйвера она вызывается с аргументом DRV_ENTRY = 1 и должна вернуть ненулевое значение при успехе. При завершении системы она вызывается с аргументом DRV_EXIT = -1. В нашем случае драйвер не работает ни с каким железом, так что ни инициализации никакого железа, ни вообще никакой финализации нет, а есть только минимально необходимые действия, чтобы драйвер считался загруженным, а именно, регистрация. Функция RegService экспортируется ядром и принимает два аргумента: имя драйвера (до 16 символов, включая завершающий 0) и указатель на процедуру обработки I/O, а возвращает 0 при неудаче или (ненулевой) зарегистрированный хэндл при успехе. Кстати, как узнать, что делает та или иная экспортируемая функция? Допустим, нам позарез нужно выделить пару страниц памяти ядра. Лезем в исходники ядра, файл {{#svn:/kernel/trunk/core/exports.inc|core/exports.inc}}, просматриваем экспортируемые имена (они осмысленны) и видим szKernelAlloc. Пролистываем вниз до метки kernel_export и ищем szKernelAlloc - обнаруживаем, что ему соответствует процедура kernel_alloc. Теперь ищем реализацию kernel_alloc, она обнаруживается в {{#svn:/kernel/trunk/core/heap.inc|core/heap.inc}}. Комментариев около функции нет, но есть объявление proc, из которого следует, что функция принимает один аргумент size типа dword. Теперь по названию ясно, что kernel_alloc выделяет память ядра в размере, равном единственному аргументу. Причём первые же три строчки кода функции показывают, что размер выравнивается вверх на границу 4096 (т.е. размер одной страницы), следовательно, функция выделяет некоторое целое количество страниц, а размер задаётся в байтах.

Дальше идёт процедура обработки запросов service_proc:

handle     equ  IOCTL.handle
io_code    equ  IOCTL.io_code
input      equ  IOCTL.input
inp_size   equ  IOCTL.inp_size
output     equ  IOCTL.output
out_size   equ  IOCTL.out_size

align 4
proc service_proc stdcall, ioctl:dword

;           mov edi, [ioctl]
;           mov eax, [edi+io_code]

	   xor eax, eax
	   ret
endp

restore   handle
restore   io_code
restore   input
restore   inp_size
restore   output
restore   out_size

Процедура обработки запросов вызывается, когда какой-то внешний код возжаждал общения именно с нашим драйвером. Это может быть как другой драйвер (формально драйвер может вызывать сам себя через механизм I/O, но смысла в этом нет), надыбавший где-то наш хэндл и вызвавший ServiceHandler, или даже само ядро (srv_handler, srv_handlerEx из {{#svn:/kernel/trunk/core/dll.inc|core/dll.inc}}), так и приложение функцией 68.17 (хэндл приложение может добыть при загрузке драйвера функцией 68.16). Нулевое возвращаемое значение означает успех, ненулевое соответствует ошибке. Вначале определяем сокращённые имена для членов структуры, описывающей запрос. В поле handle содержится хэндл драйвера (такой же, как и возвращаемое значение RegService), io_code - dword-идентификатор запроса, остальные поля вопросов вызывать не должны. Возвращаемое значение напрямую передаётся вызвавшему нас коду (драйвер/ядро/приложение). В конце восстанавливаем значения, переназначенные было на короткие имена членов структуры. В данном случае это без надобности, но в случае сложных драйверов короткие имена типа "input" запросто могут встречаться не один раз.

Дальше в {{#svn:/kernel/trunk/drivers/sceletone.asm|sceletone.asm|450}} содержится код поиска заданного оборудования на PCI-шине, нам он без надобности, при необходимости разберитесь сами.

Итак, с каркасом драйвера разобрались. А теперь будем писать свой драйвер. Начало стандартное:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                                              ;;
;; Copyright (C) KolibriOS team 2004-2007. All rights reserved. ;;
;; Distributed under terms of the GNU General Public License    ;;
;;                                                              ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; FileMon: driver part

format MS COFF

include 'proc32.inc'
include 'imports.inc'

Ориентируемся на {{#svn_rev:450}} (для 0.6.5.0 нужно было бы писать "new_app_base equ 0x60400000"):

OS_BASE         equ 0;
new_app_base    equ 0x80000000

Небольшая порция объявлений:

struc IOCTL
{  .handle      dd ?
   .io_code     dd ?
   .input       dd ?
   .inp_size    dd ?
   .output      dd ?
   .out_size    dd ?
}

virtual at 0
  IOCTL IOCTL
end virtual

public START
public version

DRV_ENTRY  equ 1
DRV_EXIT   equ -1

section '.flat' code readable align 16

Пока что всё стереотипно. Но прежде чем писать код, нужно определиться, чего мы от этого кода хотим. Итак, наш драйвер будет понимать четыре кода запроса ввода/вывода. Код 0 для всех драйверов специально предназначен для получения версии драйвера (здесь уже идёт работа с версией самого драйвера, а не версией интерфейса ядра). Строго говоря, реализовывать обработку этого запроса необязательно (ядру глубоко наплевать на версию драйвера), но весьма желательно, поскольку практически всегда драйвер можно развивать и изменять, а тогда для кода, использующего наш драйвер, знать версию всегда полезно. Версию драйвера можно возвращать в любом формате, в нашем примере для простоты будем использовать просто dword-номер версии, равный 1. Далее, код 1 означает "начать лог", код 2 - "выдать лог до текущего момента и сбросить", код 3 - "остановить лог". Лог будет записываться во внутренний буфер размера 16 Кб (учитывая, что опрашивать драйвер мы будем раз в секунду, этого должно хватить за глаза, но если вдруг не хватит, присутствие лишних записей мы сигнализируем, но сами записи не принимаем). Формат выдаваемой информации о логе: вначале общий размер записанных данных лога; потом байт со значением 0 или 1, причём 1 означает, что какие-то записи не поместились в буфере; потом массив структур переменного размера, первый байт которых содержит номер вызванной функции файловой системы и определяет дальнейшее содержимое записи. Инициализировать что-либо в драйвере нам не надо, так что процедура START выглядит так:

proc START stdcall, state:dword

           cmp [state], DRV_ENTRY
           jne .exit
.entry:
           stdcall RegService, my_service, service_proc
	   ret
.fail:
.exit:
           xor eax, eax
           ret
endp

Далее - обработка запросов:

handle     equ  IOCTL.handle
io_code    equ  IOCTL.io_code
input      equ  IOCTL.input
inp_size   equ  IOCTL.inp_size
output     equ  IOCTL.output
out_size   equ  IOCTL.out_size

proc service_proc stdcall, ioctl:dword
	mov	edi, [ioctl]
	mov	eax, [edi+io_code]
	test	eax, eax
	jz	.getversion
	dec	eax
	jz	.startlog
	dec	eax
	jz	.getlog
	dec	eax
	jz	.endlog
	xor	eax, eax
	ret
.getversion:
	cmp	[edi+out_size], 4
	jb	.err
	mov	edi, [edi+output]
	mov	dword [edi], 1		; version of driver
.ok:
	xor	eax, eax
	ret
.err:
	or	eax, -1
	ret
.startlog:
	mov	al, 1
	xchg	al, [bLogStarted]
	test	al, al
	jnz	.ok
	mov	[logptr], logbuf
	call	hook
	jnc	.ok
	mov	[bLogStarted], 0
	jmp	.err
.getlog:
	cli
	mov	esi, logbuf
	mov	ecx, [logptr]
	sub	ecx, esi
	add	ecx, 5
	cmp	ecx, [edi+out_size]
	jbe	@f
	mov	ecx, [edi+out_size]
	mov	[bOverflow], 1
@@:
	sub	ecx, 5
	xor	eax, eax
	xchg	al, [bOverflow]
	mov	edi, [edi+output]
	mov	[edi], ecx
	add	edi, 4
	stosb
	rep	movsb
	mov	[logptr], logbuf
	sti
	xor	eax, eax
	ret
.endlog:
	xchg	al, [bLogStarted]
	test	al, al
	jz	@f
	call	unhook
@@:
	xor	eax, eax
	ret
endp

restore   handle
restore   io_code
restore   input
restore   inp_size
restore   output
restore   out_size

Здесь стоит отметить, что входных данных для драйвера не нужно, поля input/inp_size мы не используем. В поле out_size вызывающий код должен поместить размер буфера output. Если нас вызывает приложение, то все манипуляции с переводом указателей приложения в указатели ядра осуществляет ядро, а в структуре ioctl передаются уже подправленные указатели.

Ну а теперь часть, отвечающая за взаимодействие с драйверной подсистемой, закончилась и начинается собственно работа. Мы перехватываем функции файловой системы 6,32,33,58,70. Для этого мы используем тот факт, что общий обработчик int 0x40 вызывает конкретную функцию косвенным вызовом из таблицы servetable (код этот обработчика располагается в файле {{#svn:/kernel/trunk/core/syscall.inc|core/syscall.inc}}). Следовательно, если подменить нужные элементы в этой таблице на адреса наших обработчиков, то вызываться будет наш код. Узнать адрес servetable можно сканированием кода обработчика int 0x40. Адрес функции i40 легко узнать из IDT, а команда вызова в текущей реализации имеет вид "call dword [servetable+edi*4]", в машинном коде "FF 14 BD <servetable>" (в принципе никто не гарантирует, что так будет и дальше, в частности, потенциально возможна замена edi на eax; тогда нужно будет соответственно менять код).

hook:
	cli
	sub	esp, 6
	sidt	[esp]
	pop	ax	; limit
	pop	eax	; base
	mov	edx, [eax+40h*8+4]
	mov	dx, [eax+40h*8]
; edx contains address of i40
	mov	ecx, 100
.find:
	cmp	byte [edx], 0xFF
	jnz	.cont
	cmp	byte [edx+1], 0x14
	jnz	.cont
	cmp	byte [edx+2], 0xBD
	jz	.found
.cont:
	inc	edx
	loop	.find
	sti
	mov	esi, msg_failed
	call	SysMsgBoardStr
	stc
	ret
.found:
	mov	eax, [edx+3]
; eax contains address of servetable
	mov	[servetable_ptr], eax
	mov	edx, newfn06
	xchg	[eax+6*4], edx
	mov	[oldfn06], edx
	mov	edx, newfn32
	xchg	[eax+32*4], edx
	mov	[oldfn32], edx
	mov	edx, newfn33
	xchg	[eax+33*4], edx
	mov	[oldfn33], edx
	mov	edx, newfn58
	xchg	[eax+58*4], edx
	mov	[oldfn58], edx
	mov	edx, newfn70
	xchg	[eax+70*4], edx
	mov	[oldfn70], edx
	sti
	clc
	ret

unhook:
	cli
	mov	eax, [servetable_ptr]
	mov	edx, [oldfn06]
	mov	[eax+6*4], edx
	mov	edx, [oldfn32]
	mov	[eax+32*4], edx
	mov	edx, [oldfn33]
	mov	[eax+33*4], edx
	mov	edx, [oldfn58]
	mov	[eax+58*4], edx
	mov	edx, [oldfn70]
	mov	[eax+70*4], edx
	sti
	ret

Две вспомогательные функции:

write_log_byte:
; in: al=byte
	push	ecx
	mov	ecx, [logptr]
	inc	ecx
	cmp	ecx, logbuf + logbufsize
	ja	@f
	mov	[logptr], ecx
	mov	[ecx-1], al
	pop	ecx
	ret
@@:
	mov	[bOverflow], 1
	pop	ecx
	ret

write_log_dword:
; in: eax=dword
	push	ecx
	mov	ecx, [logptr]
	add	ecx, 4
	cmp	ecx, logbuf + logbufsize
	ja	@f
	mov	[logptr], ecx
	mov	[ecx-4], eax
	pop	ecx
	ret
@@:
	mov	[bOverflow], 1
	pop	ecx
	ret

При написании самих обработчиков следует учитывать, что регистры циклически сдвигаются по сравнению с вызовом int 0x40 в приложении и что все указатели - это указатели 3-кольца.

newfn06:
	cli
	push	[logptr]
	push	eax
	mov	al, 6		; function 6
	call	write_log_byte
	mov	eax, ebx	; start block
	call	write_log_dword
	mov	eax, ecx	; number of blocks
	call	write_log_dword
	mov	eax, edx	; output buffer
	call	write_log_dword
	pop	eax
	push	eax
	push	esi
	lea	esi, [eax+new_app_base]	; pointer to file name
@@:
	lodsb
	call	write_log_byte
	test	al, al
	jnz	@b
	pop	esi
	pop	eax
	cmp	[bOverflow], 0
	jz	.nooverflow
	pop	[logptr]
	jmp	@f
.nooverflow:
	add	esp, 4
@@:
	sti
	jmp	[oldfn06]

newfn32:
	cli
	push	[logptr]
	push	eax
	mov	al, 32		; function 32
	call	write_log_byte
	pop	eax
	push	eax
	push	esi
	lea	esi, [eax+new_app_base]	; pointer to file name
@@:
	lodsb
	call	write_log_byte
	test	al, al
	jnz	@b
	pop	esi
	pop	eax
	cmp	[bOverflow], 0
	jz	.nooverflow
	pop	[logptr]
	jmp	@f
.nooverflow:
	add	esp, 4
@@:
	sti
	jmp	[oldfn32]

newfn33:
	cli
	push	[logptr]
	push	eax
	mov	al, 33		; function 33
	call	write_log_byte
	mov	eax, ebx	; input buffer
	call	write_log_dword
	mov	eax, ecx	; number of bytes
	call	write_log_dword
	pop	eax
	push	eax
	push	esi
	lea	esi, [eax+new_app_base]	; pointer to file name
@@:
	lodsb
	call	write_log_byte
	test	al, al
	jnz	@b
	pop	esi
	pop	eax
	cmp	[bOverflow], 0
	jz	.nooverflow
	pop	[logptr]
	jmp	@f
.nooverflow:
	add	esp, 4
@@:
	sti
	jmp	[oldfn33]

newfn58:
	cli
	push	[logptr]
	push	eax
	push	ebx
	lea	ebx, [eax+new_app_base]
	mov	al, 58		; function 58
	call	write_log_byte
; dump information structure
	mov	eax, [ebx]
	call	write_log_dword
	mov	eax, [ebx+4]
	call	write_log_dword
	mov	eax, [ebx+8]
	call	write_log_dword
	mov	eax, [ebx+12]
	call	write_log_dword
	push	esi
	lea	esi, [ebx+20]		; pointer to file name
@@:
	lodsb
	call	write_log_byte
	test	al, al
	jnz	@b
	pop	esi
	pop	ebx
	pop	eax
	cmp	[bOverflow], 0
	jz	.nooverflow
	pop	[logptr]
	jmp	@f
.nooverflow:
	add	esp, 4
@@:
	sti
	jmp	[oldfn58]

newfn70:
	cli
	push	[logptr]
	push	eax
	push	ebx
	lea	ebx, [eax+new_app_base]
	mov	al, 70		; function 70
	call	write_log_byte
; dump information structure
	mov	eax, [ebx]
	call	write_log_dword
	mov	eax, [ebx+4]
	call	write_log_dword
	mov	eax, [ebx+8]
	call	write_log_dword
	mov	eax, [ebx+12]
	call	write_log_dword
	mov	eax, [ebx+16]
	call	write_log_dword
	push	esi
	lea	esi, [ebx+20]		; pointer to file name
	lodsb
	test	al, al
	jnz	@f
	lodsd
	lea	esi, [eax+new_app_base+1]
@@:
	dec	esi
@@:
	lodsb
	call	write_log_byte
	test	al, al
	jnz	@b
	pop	esi
	pop	ebx
	pop	eax
	cmp	[bOverflow], 0
	jz	.nooverflow
	pop	[logptr]
	jmp	@f
.nooverflow:
	add	esp, 4
@@:
	sti
	jmp	[oldfn70]

На этом код заканчивается. Теперь используемые данные (мы ориентируемся на {{#svn_rev:450}}, для 0.6.5.0 version должна быть 0x00030003):

version		dd	0x00040004
my_service	db	'fmondrv',0

msg_failed	db	'Cannot hook required functions',13,10,0

section '.data' data readable writable align 16

servetable_ptr	dd	?

oldfn06		dd	?
oldfn32		dd	?
oldfn33		dd	?
oldfn58		dd	?
oldfn70		dd	?

logptr		dd	?
logbufsize = 16*1024
logbuf		rb	logbufsize

bOverflow	db	?
bLogStarted	db	?

Собрав весь приведённый код в один файл fmondrv.asm, получаем окончательный исходник драйвера. Кроме того, этот файл входит в архив к статье. Компиляция:

fasm fmondrv.asm

После этого по желанию можно упаковать fmondrv.obj с помощью KPACK, ядро прекрасно загружает kpack'ованные файлы, а такая мера в данном случае уменьшает размер с 1850 байт до 757 байт. Кстати, маленькая хитрость: по смещению +4 в COFF-объектнике хранится штамп даты/времени компиляции, ядру на него глубоко наплевать, так что можно забить его нулями любым hex-редактором, после чего сжатый файл будет чуть-чуть меньше (в данном случае 756 байт). Для установки драйвера скопируйте его в /rd/1/drivers, после этого он готов к загрузке.

Управляющая программа

Управляющая программа у нас будет выводить текстовую информацию на консоль и завершать работу при нажатии Esc. Для этого потребуется консольная DLL версии как минимум 3, причём в дистрибутив 0.6.5.0 входит версия 2, так что скачивайте последнюю версию из http://diamondz.land.ru/console.7z. В качестве шаблона используем testcon.asm (можно было бы и testcon2.asm) со следующими изменениями: в REQ_DLL_VER подставляем 3, в таблице импорта (метка myimport) убираем con_write_asciiz и добавляем con_printf, con_kbhit, con_getch2 и, разумеется, после строчки с комментарием "Now do some work" пишем свой код.

use32
        db      'MENUET01'
        dd      1
        dd      start
        dd      i_end
        dd      mem
        dd      mem
        dd      0
        dd      0

REQ_DLL_VER = 3
DLL_ENTRY = 1

start:
; First 3 steps are intended to load/init console DLL
; and are identical for all console programs

; load DLL
        mov     eax, 68
        mov     ebx, 19
        mov     ecx, dll_name
        int     0x40
        test    eax, eax
        jz      exit

; initialize import
        mov	edx, eax
        mov     esi, myimport
import_loop:
        lodsd
        test    eax, eax
        jz      import_done
        push    edx
import_find:
        mov     ebx, [edx]
        test    ebx, ebx
        jz      exit;import_not_found
        push    eax
@@:
        mov     cl, [eax]
        cmp     cl, [ebx]
        jnz     import_find_next
        test    cl, cl
        jz      import_found
        inc     eax
        inc     ebx
        jmp     @b
import_find_next:
        pop     eax
        add     edx, 8
        jmp     import_find
import_found:
        pop     eax
        mov     eax, [edx+4]
        mov     [esi-4], eax
        pop     edx
        jmp     import_loop
import_done:

; check version
        cmp     word [dll_ver], REQ_DLL_VER
        jb      exit
        cmp     word [dll_ver+2], REQ_DLL_VER
        ja      exit
        push    DLL_ENTRY
        call    [dll_start]

; yes! Now do some work (say helloworld in this case).
        push    caption
        push    -1
        push    -1
        push    -1
        push    -1
        call    [con_init]

Загружаем драйвер, при ошибке ругаемся на консоли и выходим, оставляя консоль на экране:

        mov     eax, 68
        mov     ebx, 16
        mov     ecx, drivername
        int     0x40
        mov     [hDriver], eax
        test    eax, eax
        jnz     @f
loaderr:
        push    aCantLoadDriver
        call    [con_printf]
        add     esp, 4
        push    0
        call    [con_exit]
        jmp     exit
@@:

Проверяем версию драйвера, для чего посылаем ему запрос с кодом 0:

        and     [ioctl_code], 0
        and     [inp_size], 0
        mov     [outp_size], 4
        mov     [output], driver_ver
        mov     eax, 68
        mov     ebx, 17
        mov     ecx, ioctl
        int     0x40
        test    eax, eax
        jnz     loaderr
        cmp     [driver_ver], 1
        jnz     loaderr

Запускаем лог - запрос с кодом 1:

        mov     [ioctl_code], 1
        and     [inp_size], 0
        and     [outp_size], 0
        mov     eax, 68
        mov     ebx, 17
        mov     ecx, ioctl
        int     0x40
        test    eax, eax
        jnz     loaderr

Итак, драйвер загружен и ведёт лог. Сообщим пользователю, что происходит:

        push    str0
        call    [con_printf]
        add     esp, 4

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

mainloop:
        mov     eax, 5
        mov     ebx, 100
        int     0x40
        mov     [ioctl_code], 2
        and     [inp_size], 0
        mov     [outp_size], 1+16*1024
        mov     [output], logbuf
        mov     eax, 68
        mov     ebx, 17
        mov     ecx, ioctl
        int     0x40
        push    eax
        mov     ecx, dword [logbuf]
        mov     esi, logbuf+5
message:
        test    ecx, ecx
        jz      done
        movzx   eax, byte [esi]
        push    eax
        push    str1
        call    [con_printf]
        add     esp, 8
        lodsb
        cmp     al, 6
        jz      fn06
        cmp     al, 32
        jz      fn32
        cmp     al, 33
        jz      fn33
        cmp     al, 58
        jz      fn58
        sub     ecx, 1+4*5      ; size of log data for fn70 (excluding filename)
        lodsd
        cmp     eax, 10
        jae     fn70unk
        jmp     [fn70+eax*4]
fn70unk:
        push    dword [esi+12]
        push    dword [esi+8]
        push    dword [esi+4]
        push    dword [esi]
        push    eax
        push    str2
        call    [con_printf]
        add     esp, 6*4
        add     esi, 16
        jmp     print_name
fn70readfile:
        push    dword [esi+12]
        push    dword [esi+8]
        push    dword [esi]
        push    str3
        call    [con_printf]
        add     esp, 4*4
        add     esi, 16
        jmp     print_name
fn70readfolder:
        mov     eax, str41
        test    byte [esi+4], 1
        jz      @f
        mov     eax, str42
@@:
        push    dword [esi+12]
        push    dword [esi+8]
        push    dword [esi]
        push    eax
        push    str4
        call    [con_printf]
        add     esp, 5*4
        add     esi, 16
        jmp     print_name
fn70create:
        push    dword [esi+12]
        push    dword [esi+8]
        push    str5
        call    [con_printf]
        add     esp, 3*4
        add     esi, 16
        jmp     print_name
fn70write:
        push    dword [esi+12]
        push    dword [esi+8]
        push    dword [esi+4]
        push    str6
        call    [con_printf]
        add     esp, 4*4
        add     esi, 16
        jmp     print_name
fn70setsize:
        push    dword [esi]
        push    str7
        call    [con_printf]
        add     esp, 4*2
        add     esi, 16
        jmp     print_name
fn70getattr:
        push    dword [esi+12]
        push    str8
        call    [con_printf]
        add     esp, 4*2
        add     esi, 16
        jmp     print_name
fn70setattr:
        push    dword [esi+12]
        push    str9
        call    [con_printf]
        add     esp, 4*2
        add     esi, 16
        jmp     print_name
fn70execute:
        push    str10
        call    [con_printf]
        add     esp, 4
        lodsd
        test    al, 1
        jz      @f
        push    str10_1
        call    [con_printf]
        add     esp, 4
@@:
        lodsd
        test    eax, eax
        jz      @f
        push    eax
        push    str10_2
        call    [con_printf]
        add     esp, 8
@@:
        add     esi, 8
        jmp     print_name
fn70delete:
        push    str11
        call    [con_printf]
        add     esp, 4
        add     esi, 16
        jmp     print_name
fn70createfolder:
        push    str12
        call    [con_printf]
        add     esp, 4
        add     esi, 16
        jmp     print_name
fn58:
        sub     ecx, 1+4*4      ; size of log data for fn58 (excluding filename)
        lodsd
        test    eax, eax
        jz      fn58read
        cmp     eax, 1
        jz      fn58write
        cmp     eax, 8
        jz      fn58lba
        cmp     eax, 15
        jz      fn58fsinfo
fn58unk:
        push    dword [esi+8]
        push    dword [esi+4]
        push    dword [esi]
        push    eax
        push    str13
        call    [con_printf]
        add     esp, 5*4
        add     esi, 12
        jmp     print_name
fn58read:
        push    dword [esi+8]
        mov     eax, [esi+4]
        shl     eax, 9
        push    eax
        mov     eax, [esi]
        shl     eax, 9
        push    eax
        push    str3
        call    [con_printf]
        add     esp, 4*4
        add     esi, 12
        jmp     print_name
fn58write:
        push    dword [esi+8]
        push    dword [esi+4]
        push    str5
        call    [con_printf]
        add     esp, 3*4
        add     esi, 12
        jmp     print_name
fn58lba:
        push    dword [esi+8]
        push    dword [esi]
        push    str14
        call    [con_printf]
        add     esp, 3*4
        add     esi, 12
        jmp     print_name
fn58fsinfo:
        push    str15
        call    [con_printf]
        add     esp, 4
        add     esi, 12
        jmp     print_name
fn33:
        sub     ecx, 1+2*4      ; size of log data for fn33
        lodsd
        push    eax
        lodsd
        push    eax
        push    str5
        call    [con_printf]
        add     esp, 3*4
        push    aRamdisk
        call    [con_printf]
        add     esp, 4
        jmp     print_name
fn32:
        dec     ecx             ; only filename is logged
        push    str11
        call    [con_printf]
        push    aRamdisk
        call    [con_printf]
        add     esp, 4+4
        jmp     print_name
fn06:
        sub     ecx, 1+3*4      ; size of log data for fn06
        push    dword [esi+8]
        mov     eax, [esi+4]
        test    eax, eax
        jnz     @f
        inc     eax
@@:
        shl     eax, 9
        push    eax
        lodsd
        test    eax, eax
        jnz     @f
        inc     eax
@@:
        dec     eax
        shl     eax, 9
        push    eax
        push    str3
        call    [con_printf]
        add     esp, 4*4
        push    aRamdisk
        call    [con_printf]
        add     esp, 4
        add     esi, 8
print_name:
        push    esi
        push    str_final
        call    [con_printf]
        add     esp, 8
@@:
        lodsb
        test    al, al
        jnz     @b
        jmp     message
done:
        cmp     byte [logbuf+4], 0
        jz      @f
        push    str_skipped
        call    [con_printf]
@@:
; we has output all driver data, now check console (did user press Esc?)
        call    [con_kbhit]
        test    al, al
        jz      mainloop
        call    [con_getch2]
        cmp     al, 27
        jnz     mainloop

По нажатию Esc сообщим драйверу, что больше логгинг нам не нужен,

        mov     [ioctl_code], 3
        and     [inp_size], 0
        and     [outp_size], 0
        mov     eax, 68
        mov     ebx, 17
        mov     ecx, ioctl
        int     0x40

завершим работу с консолью, убрав с экрана её окно,

        push    1
        call    [con_exit]

и завершим работу программы.

exit:
        or      eax, -1
        int     0x40

Данные программы:

dll_name db '/rd/1/console.obj',0
caption db 'FileMon',0
drivername db 'fmondrv',0
aCantLoadDriver db "Can't load driver",13,10,0

str0 db 'Monitoring file system calls... Press Esc to exit',10,0

str1 db 'Fn%2d: ',0
str2 db 'unknown subfunction %d, parameters: 0x%X, 0x%X, 0x%X, 0x%X, name ',0
str3 db 'read file, starting from 0x%X, %d bytes, to 0x%X; name ',0
str4 db 'read folder (%s version), starting from %d, %d blocks, to 0x%X; name ',0
str41 db 'ANSI',0
str42 db 'UNICODE',0
str5 db 'create/rewrite file, %d bytes from 0x%X; name ',0
str6 db 'write file, starting from 0x%X, %d bytes, from 0x%X; name ',0
str7 db 'set file size to %d bytes; name ',0
str8 db 'get file attributes to 0x%X; name ',0
str9 db 'set file attributes from 0x%X; name ',0
str10 db 'execute ',0
str10_1 db '(in debug mode) ',0
str10_2 db '(with parameters 0x%X) ',0
str11 db 'delete ',0
str12 db 'create folder ',0
str13 db 'unknown subfunction %d, parameters: 0x%X, 0x%X, 0x%X, name ',0
str14 db 'LBA read sector 0x%X to 0x%X from device ',0
str15 db '(obsolete!) query fs information of ',0
aRamdisk db '/rd/1/',0
str_final db '%s',10,0
str_skipped db '[Some information skipped]',10,0

align 4
label fn70 dword
        dd      fn70readfile
        dd      fn70readfolder
        dd      fn70create
        dd      fn70write
        dd      fn70setsize
        dd      fn70getattr
        dd      fn70setattr
        dd      fn70execute
        dd      fn70delete
        dd      fn70createfolder

align 4
myimport:
dll_start       dd      aStart
dll_ver         dd      aVersion
con_init        dd      aConInit
con_printf      dd      aConPrintf
con_exit        dd      aConExit
con_kbhit       dd      aConKbhit
con_getch2      dd      aConGetch2
                dd      0

aStart          db      'START',0
aVersion        db      'version',0
aConInit        db      'con_init',0
aConPrintf      db      'con_printf',0
aConExit        db      'con_exit',0
aConKbhit       db      'con_kbhit',0
aConGetch2      db      'con_getch2',0

i_end:

align 4
ioctl:
hDriver         dd      ?
ioctl_code      dd      ?
input           dd      ?
inp_size        dd      ?
output          dd      ?
outp_size       dd      ?

driver_ver      dd      ?
logbuf          rb      16*1024+5

align 4
rb 2048 ; stack
mem: