Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

КУРСОВА РОБОТА

на тему:

«Перехоплення функцій ядра Windows для захисту процесу»



Зміст

Вступ

1. Архітектура NT. Структура ядра

1.1 Режим ядра

1.2 Режим користувача

2. Перехоплення. Методи перехоплення функцій

2.1 Режим користувача

2.2 Режим ядра

3. Драйвер режиму ядра. IRP

3.1 Поняття драйверу

3.2 Пакети вводу-виводу

3.3 Структура IRP-пакету

Висновки

Використана література

Додатки

Вступ

Всі сучасні системи Windows базуються на ядрі NT і є операційними ситемами з витісняючою багатозадачністю, тобто система може тимчасово перервати процес без його втручання. Для обробки запитів вводу-виводу використовується схема, що використовує пакети вводу-виводу та підтримує асинхронні запити.

За архітектурою процесори сімейства x86 підтримують чотири рівня привілеїв виконання -- від 0 до 3 , проте ОС Windows використовує лише 2 з них: режим користувача виконується на третьому, а режим ядра на нульовому рівні. Основу операційної системи складають такі компоненти, як рівень абстракції від апаратного забезпечення та драйвери і служби, що працюють в режимі ядра або в користувацькому режимі.

Організація пам'яті в Windows NT



В загальному випадку вона виглядає так: адреси від 0x00000000 до 0x0000FFFF не використовуються, будь-яке звертання до них викликає помилку. Адреси від 0x00010000 до 0x7FFFFFFF є користувацьким адресовим простором (User Space), ця область памяті різна у кожного процесу системи. В ній знаходиться код третього кільця та повязані з ним дані. Адреси від 0x800000000 до 0xFFFFFFFF є областю памяті ядра системи (Kernel Space), ця область єдина для всієї системи. В ній розміщені ядро системи, драйвера, файловий кеш, системні пули, а також всі структури ядра. Доступ до цієї памяті можна отримати лише з нульового кільця, будь-яке звертання до неё процесу користувацього режиму викличе помилку. При руйнуванні памяті процесу режиму користувача буде завершений лише той процес, память якого порушена, проте порушення цілісності структур памяті ядра веде до падіння систему в цілому.



1. Архітектура NT. Структура ядра

1.1 Режим ядра

Ядро--центральна частина ОС, що забезпечує скоординований доступ до ресурсів ПК, таких як процесорний час, память, зовнішні апаратні засоби, засоби вводу-виводу інформації. Також ядро забезпечує сервіси файлової системи та основних мережевих протоколів.

Як найнижчий компонент ОС, ядро пропонує найбільш низький рівень абстракції від апаратного забезпечення для доступу до ресурсів системи. Режим ядра Windows NT забезпечує повний доступ до аппаратного апаратного забезпечення та працює в захищеній області пам'яті. Ядро контролює потоки виконання, керує памяттю та взаємодією з апаратною частиною, а також обмежує доступ до критичних регіонів памяті зі сторони служб та програм режиму користувача. Для виконання подібних операцій процес режиму користувача повинен попросити ядро виконати її від свого імені.



Структура ядра

В режимі ядра виконуються наступні складові ОС:

1) Рівень абстракції від апаратного забезпечення (HAL - Hardware Abstraction Layer) ізолює ядро, драйвери пристроїв та виконувальну частину від апаратної платформи, на якій працює ОС.

2) Драйвери пристроїв, що включают як файлову систему, так і апаратні драйвери, що транслують користувацькі виклики функцій вводу-виводу в запити фізичних пристроїв.

3) Виконувальна частина, що здійснює керування памяттю, процесами, потоками, безпекою, операціями вводу-виводу та міжпроцесорним обміном. Ядро Windows NT виконує низькорівневі операції: диспетчеризація потоків, переривань та виключень, синхронізації процесорів. Також ядро включає в себе набір базових процедур, які використовує виконувальна частина для створення високорівневих конструкцій.

Рівень абстракції від апаратного забезпечення (HAL)

HAL -рівень абстрагування, реалізований в програмному забезпеченні, що знаходиться між фізичним рівнем апаратного забезпечення та програмним забезпеченням, що працює на даній обчислювальній машині. HAL призначений для приховання відмінностей в апаратному забезпеченні від основної частини ядра операційної системи.

На персональных компьютерах HAL можна розглядати як драйвер материнської плати, що дозволяє взаємодіяти інструкціям високорівневих мов програмування з низькорівневими компонентами, такими як апаратним забезпеченням.

В ОС сімейства Windows NT HAL є необхідною частиною кода, який виконується в режимі ядра та знаходиться в іншому завантажувальному модулі. Це забезпечує можливість використання одного й того самого завантажувального модуля ядра ОС Windows NT на системах з різними архітектурами.

Драйвери пристроїв

Драйвери пристроїв- це завантажувальні модулі, що працюють в режимі ядра, створюючи інтерфейс між системою вводу/виводу та відповідним апаратним забезпеченням. Зазвичай такі модулі мають розширення .SYS. Всі вони створені з використанням викликів процедур HAL та є переносними на рівні двійкового коду між платформами NT. Існують декілька типів драйверів:

1) Драйвери, що керують апаратними засобами (з використанням HAL) для запису вихідних даних або отримання вхідних даних від фізичних пристроїв або через мережу.

2) Драйвери файлової системи, що приймають запити на файловий ввід/вивід та транслюють їх в запити вводу/виводу, повязані з конкретними пристроями.

3) Драйвери-фільтри. Прикладом є драйвери підтримки дзеркальних дисків, шифрування даних, перехоплення вводу/вивіду для додаткової обробки даних перед передачою їх на наступний рівень.

4) Мережеві драйвери, що передають та приймають віддалені запити вводу/вивіду.

Виконувальна частина

Виконувальна частина Windows NT - NTOSKRNL.EXE складається з наступних компонентів:

· Менеджер процесів та потоків керує процесами та потоками. Фактично процеси та потоки підтримуються в ОС найнижчим рівнем. Виконувальна частина додає нову семантику та функції до обєктів нижчого рівня.

· Менеджер віртуальної памяті використовує схему управління, при якій кожен процес отримує власний простір адрес, захищений від впливу інших процесів. Менеджер памяті також забезпечує низькорівневу підтримку для менеджера кеш-памяті.

· Монітор безпеки проводить політику забезпечення заходів безпеки на компьютері, захищаючи системні ресурси та виконуючи процедури аудиту та захисту обєктів.

· Система ввода/виводу використовує незалежний від пристроїв ввод-вивід та відповідає за пересилку даних відповідним драйверам для подальшої обробки.

· Менеджер кеш-памяті покращує швидкодію системи вводу-виводу, розміщуючи дані, що читаються з диску в основній памяті для пришвидшеного доступу до них, а також відкладаючи на короткий час запис змінених даних на диск.

· Менеджер обєктів, що створює, видаляє обєкти, а також керує ними. Обєкти використовуються в Windows NT для представлення таких ресурсів ОС, як процеси, потоки та обєкти синхронізації.

1.2 Режим користувача

Режим користувача складається з підсистем, що передають запити вводу\виводу відповідному драйверу режиму ядра через менеджер вводу-виводу. Основною тут є підсистема оточення, що розроблена для запуску додатків, розроблених під різні версії ОС. Ні одна з підсистем оточення не має прямого доступу до апаратного забезпечення компютера. Доступ до памяті забезпечується менеджером памяті, що працює в режимі ядра. Також приорітет виконання програм режиму користувача менше, ніж у компонентів режиму ядра.

Підсистема оточення включає в себе наступні -- система Win32, система OS/2 та система POSIX. Win32 запускає 32-розрядні Windows-додатки. Кожна програма запускаєтся в одному процесі з використання одного простору адрес, але для кожної програми використовується окремий потік. Також процес підсистеми оточення Win32 csrss.exe включає в себе функціонал менеджера вікон, тобто він опрацьовує такі події, як натискання клавіш клавіатури та миші, і передає їх на обробку конкретними програмами.



2. Перехоплення. Методи перехоплення функцій

Перехоплення -- технологія, що дозволяє змінити стандартну поведінку тих чи інших компонентів системи. З точки зору операційної системи, вона дозволяє змінити результати виконання функцій або замінити саму функцію.

Існують наступні види перехоплення системних функцій в ОС Windows:

· Режим користувача: модифікация IAT таблиць, сплайсинг.

· Режима ядра:модифікация SSDT/IDT таблиць, перехоплення з модифікацією тіла функції.

2.1 Режим користувача

Зміна IAT таблиць процеса

IAT -- таблиця адрес функцій, що імпортуються процесом для їх використання в роботі. Суть перехоплення зводиться до пошуку назви функції в таблиці та заміни її адреси на адресу нової. Ця технологія не змінює поведінку самої функції ОС, але змушує програму використовувати підставну функцію. Недоліком є необхідність модифікації IAT для кожного процесу в системі, що зводиться до завантаження DLL-бібліотеки у адресовий простір процеса.

Сплайсинг

Метод перехоплення шляхом зміни коду цільової функції в памяті системи. Суть зводиться до заміни перших 5 байт функції на команду довгого безумовного переходу (JMP), що передає управління до підставної функції. Щоб забезпечити коректність роботи, перехоплювач функції повинен зберегти оригінальний початок функції, і після виконання необхідних операцій повністю виконати справжню функцію.



2.2 Режим ядра

Перехоплення базується на модифікації структур ядра та його функцій. Це здійснюється за допомогою внесення змін до відповідних таблиць:

· IDT Таблиця диспетчеризації (векторів) переривань.

· SSDT Таблиця диспетчеризації системних сервісів.

· IRP Таблиця драйвера, яка зберігає вказівники на функції, що обробляють пакети IRP.

Таблиця векторів переривань(IDT) пов'язує безпосередньо підпрограму обробника переривань з вектором(номером) переривання. Починаючи з процесора типу 80286, адреса в фізичній памяті та розмір таблиці переривань визначає 48-бітний регістр IDTR. IDT використовує наступні типи переривань: апаратні, програмні та переривання, резервовані процесором, які є обробниками виняткових ситуацій на випадок деяких подій (ділення на нуль, помилка трасирування, переповнення).

SSDT пов'язує ім'я (номер) системної функції ядра з її адресою в пам'яті. Перехоплення за допомогою модифікації цієї таблиці є найбільш розповсюдженим. При виклику функції операційна система звертається до таблиці з метою отримання адреси, на яку буде передане керування для виконання завдань самою функцією.



3. Драйвер режиму ядра. IRP

3.1 Поняття драйверу

Драйвер--це компьютерна програма, за допомогою якої ОС отримує доступ до апаратного забезпеченння деякого пристрою; завантажувані модулі, що працюють в режимі ядра, забезпечуючи інтерфейс між системою вводу/виводу та відповідними пристроями. Операційна система керує так званим «віртуальним пристроєм», який розуміє системний набір команд. Драйвер, в свою чергу, переводить ці команди у такі, що може виконати безпосередньо пристрій. Це є основним принципом ідеології абстракції від апаратного забезпечення.

Драйвер складається з деяких ключових функцій, що обробляють системні події. Головними з них є:

· Завантаження драйверу (реєстрація в системі, ініціалізація приладу).

· Вивантаження (звільнення зайнятих ресурсів:памяті, файлів, приладів).

· Відкриття драйверу (початок основної роботи. Зазвичай відкривається функцією CreateFile() в Win32).

· Читання/запис (програма обмінюється інформацією з пристроєм).

· Закриття драйверу (вивільнення ресурсів та видалення дескриптору файлу).

· Керування вводом/вивідом (IO Control, IOCTL). За допомогою цього інтерфейсу драйвер може пересилати дані та команди, специфічні для приладу. В Win32-системах керування здійснюється функцією DeviceIoControl().

Також драйвер є єдиним шляхом додати в систему код, що працює в нульовому кльці, тому написання драверій можна розглядати як спосіб доступу до внутрішніх функцій та структур даних операційної системи, що розміщені в режимі ядрі.

Взаємодія драйверів між собою та програмами режиму користувача базується на використанні технології IRP.

3.2 Пакети вводу-виводу (I/O request packet, IRP)

IRP пакет--структура даних Windows, що забезпечує обмін даними між драйверами, а також між драйвером та програмою користувацького режиму. З точки зору архітектури будь-який драйвер є учасником вводу-виводу, незалежно від того, чи керує він пристроєм. Також неможлива пряма взаємодія між драйвером та програмою користувацького режиму. Вона зводиться до посилання коду IOCTL, який призводить до того, що диспетчер вводу/виводу формує на його основі IRP пакет. В самому драйвері визначені функції, що реагують на тип запиту пакета.

3.3 Структура IRP пакета

IRP пакет складається з двох частин: постійної та стеку вводу-виводу.

В постійній частині зберігається інформація, що не змінюється при передачі по стеку пристроїв або не потребує збереження. Стеком пристріїв називається набір пристроїв, що повинні опрацювати поточний IRP пакет. Від пристроя до пристроя пакет передається послідовно. Постійна частина включає в себе інформацію, яка не змінюється під час проходження пакету або не повинна зберігатися в процесі роботи виконання пакету. Найбільш важливими є наступні поля:

· MdlAddress-вказівкник на буфер запиту. Ссилається на память, де описаний запит.

· Flags-зберігає прапори, що описують процес вводу-виводу.

· IoStatus-блок стану вводу-виводу, що описує стан завершення обробки IRP. Коли IRP завершений, драйвер поміщує в поле loStatus.Status стан завершення операції, а в поле loStatus.Information - додаткову інформацію, яку потрібно передати назад ініціатору запиту.

· Cancel, CancelRoutine-поля використовуються, якщо IRP може бути скасований в процесі обробки. Cancel - поле типу BOOLEAN, значення якого встановлюється диспетчером вводу/виводу. Встановлення цього поля в TRUE означає, що операція вводу-виводу була відмінена. CancelRoutine - вказівник на функцію драйвера, що буде викликана диспетчером вводу-виводу для коректної відміни IRP.

· UserBuffer-віртуальна адресу буферу даних ініціатора запиту вводу-виводу.

Стек вводу-виводу в IRP містить інформацію відносно запиту вводу-виводу для конкретного драйверу. Розміщення стеку визначається структурою IO_STACK_LOCATION. Для визначення розміщення стеку всередині заданого IRP, драйвер може використати функцію IoGetCurrentlrpStackLocation, що поверне покажчик на поточний стек. Розглянемо основні поля стеку вводу-виводу:

· MajorFunction-вказівник на головний код функції вводу-виводу, звязаний з запитом вводу-виводу. Тут вказується тип операції, що має бути виконана.

· MinorFunction-покажчик на другорядний код функції. При використанні це поле перевизначає головний код функції.

· Control-сукупність прапорів, які встановлюються та читаються диспетчером вводу-виводу, вказуючи, яким чином потрібно обробити даний пакет IRP. Наприклад, прапори SL_INVOKE_ ON_CANCEL, SL_INVOKE_ON_ERROR и SL_INVOKE_ON_SUCCESS вказують, коли повинна бути викликана підпрограма завершення вводу-виводу драйвера.

· DeviceObject-покажчик на обєкт-пристрій, що є отримувачем запиту вводу-виводу.



Висновки

ядро операційна система функція

В даній роботі досліджена внутрішня структура операційної системи Windows, в результаті чого можна зробити ряд висновків:

· Завдяки поділу функціональності на режим ядра та режим користувача стабільність та безпека системи є великими, оскільки помилки користувацького режиму не можуть впливати на функціонування системи в цілому.

· Гібридне ядро дає змогу динамічно завантажувати та видаляти модулі ядра, що дозволяє застосовувати гнучку систему драйверів. Так, саме таким чином стала можливою технологія «plug and play», основою якої є завантаження додаткових драйверів в адресовий простір вже працюючого ядра.

· За допомогою написання та динамічного завантаження драйверів стала можливою модифікація внутрішніх структур ядра, що дозволяє створювати антивірусні системи та системи проактивного захисту, захищених від будь-якого впливу зі сторони шкідливих програм.

В результаті проведеної роботи за допомогою документації Майкрософт було визначено функції ядра, які безпосередньо або опосередковано впливають на роботу процесу. Основними з них є наступні:

· NtOpenProcess (дозволяє отримати дескриптор процеса та службову інформацію про нього)

· NtOpenThread(дозволяє отримати дескриптор та додаткову інформацію про потік виконання)

· NtTerminateProcess(використовується для аварійного завершення процесу)

· NtTerminateThread(дозволяє примусово завершити виконання потоку)

· NtWriteVirtualMemory(даний інструмент дозволяє здійснювати запис інформації в адресовий простір процесу)

· NtDuplicateObject(дозволяє скопіювати об'єкт операційної системи зі зміною прав на нього. Так, це дозволяє отримати дескриптор процесу або потоку в обхід раніше згаданих функцій)

· NtDebugActiveProcess(дозволяє здійснювати налагодження процесу, що дає змогу закрити дескриптор об'єкту, роблячи неможливим його подальше існування)

На основі цієї інформації був створений драйвер, що перехоплює системні функції ядра Windows на основі модифікації таблиці SSDT (метод зміни адреси функції, що перехоплюються, на підставну). Це дозволяє здійснювати контроль аргументів функцій, які були викликані та здійснювати їх модифікацію.



Використана література

1. Соломон Д., Руссинович М. Внутреннее устройство Microsoft Windows 2010. Мастер-класс. / Пер. с англ. - СПб.: Питер; М.: Издательско-торговый дом "Русская Редакция". 2006. - 746 стр.

2. А. С. Моляков Исследование ядра Windows NT 5.1 на целевой платформе Intel 3000. Систематический поиск недекларированных возможностей. Компания Спутник +. 2006 г.- 130 стр.

3. Свен Шрайбер Недокументированные возможности Windows 2000. Питер. 2002 г. - 544 стр.

4. В. П. Солдатов Программирование драйверов Windows. Бином-Пресс. 2009 г.- 576 стр.

5. Светлана Сорокина, Андрей Тихонов, Андрей Щербаков Программирование драйверов и систем безопасности. БХВ-Петербург. 2008 г.-256стр.

6. Гэри Неббет Справочник по базовым функциям API Windows NT/2000. ISBN 5-8459-0238-X. 2002г.-528стр.

7. Валерия Комиссарова Программирование драйверов для Windows. БХВ-Петербург. 2007г.- 256 стр.



Додаток 1.

Початковий код драйверу режиму ядра, компілятор WDK, мова-С

#include <ntddk.h>

typedef PVOID* PNTPROC;

typedef DWORD (ULONG);

typedef DWORD*PDWORD;

typedef unsigned char (BYTE);

typedef BYTE* PBYTE;

typedef struct _SYSTEM_SERVICE_TABLE

{

PNTPROC ServiceTable;

PDWORD CounterTable;

ULONG ServiceLimit;

PBYTE ArgumentTable;

}

SYSTEM_SERVICE_TABLE ,

* PSYSTEM_SERVICE_TABLE ,

* * PPSYSTEM_SERVICE_TABLE ;

typedef struct _SERVICE_DESCRIPTOR_TABLE {

SYSTEM_SERVICE_TABLE ntoskrnl; //SST для ntoskrnl.exe

SYSTEM_SERVICE_TABLE win32k; //SST для win32k.sys

SYSTEM_SERVICE_TABLE unused1;

SYSTEM_SERVICE_TABLE unused2;

}

SERVICE_DESCRIPTOR_TABLE ,

* PSERVICE_DESCRIPTOR_TABLE,

* * PPSERVICE_DESCRIPTOR_TABLE ;

#define NTCALL(_function) KeServiceDescriptorTable->ntoskrnl.ServiceTable[_function]

#define USERCALL(_function) KeServiceDescriptorTableShadow->win32k.ServiceTable[_function]

extern PSERVICE_DESCRIPTOR_TABLE KeServiceDescriptorTable;

UNICODE_STRING DeviceName;

UNICODE_STRING SymbolicLinkName;

PDEVICE_OBJECT deviceObject = NULL;

PEPROCESS IoThreadToProcess(

__in PETHREAD Thread

);

HANDLE ProtectedPid = 0;

NTSTATUS NtQueryInformationThread(

__in HANDLE ThreadHandle,

__in THREADINFOCLASS ThreadInformationClass,

__inout PVOID ThreadInformation,

__in ULONG ThreadInformationLength,

__out_opt PULONG ReturnLength

);

typedef struct _THREAD_BASIC_INFORMATION {

NTSTATUS ExitStatus;

PVOID TebBaseAddress;

CLIENT_ID ClientId;

KAFFINITY AffinityMask;

KPRIORITY Priority;

KPRIORITY BasePriority;

} THREAD_BASIC_INFORMATION, *PTHREAD_BASIC_INFORMATION;

NTSTATUS PsGetThreadProcessId (IN PETHREAD Thread ) ;

typedef NTSTATUS (*NtOpenProcessPointer)(

OUT PHANDLE ThreadHandle,

IN ACCESS_MASK DesiredAccess,

IN POBJECT_ATTRIBUTES ObjectAttributes,

IN PCLIENT_ID ClientId);

typedef NTSTATUS (*NtOpenThreadPointer)(

__out PHANDLE ThreadHandle,

__in ACCESS_MASK DesiredAccess,

__in POBJECT_ATTRIBUTES ObjectAttributes,

__in PCLIENT_ID ClientId

);

NTSTATUS ObReferenceObjectByHandle(

__in HANDLE Handle,

__in ACCESS_MASK DesiredAccess,

__in_opt POBJECT_TYPE ObjectType,

__in KPROCESSOR_MODE AccessMode,

__out PVOID *Object,

__out_opt POBJECT_HANDLE_INFORMATION HandleInformation

);

typedef NTSTATUS (*NtTerminateProcessPointer)(

IN HANDLE ProcessHandle OPTIONAL,

IN NTSTATUS ExitStatus );

typedef NTSTATUS (*NtTerminateThreadPointer)(

IN HANDLE ThreadHandle,

IN NTSTATUS ExitStatus );

typedef NTSTATUS (*NtWriteVirtualMemoryPointer)(

IN HANDLE ProcessHandle,

IN PVOID BaseAddress,

IN PVOID Buffer,

IN ULONG NumberOfBytesToWrite,

OUT PULONG NumberOfBytesWritten OPTIONAL );

typedef NTSTATUS (*NtDebugActiveProcessPointer)(

IN HANDLE Process,

IN HANDLE DebugObject);

NtOpenProcessPointer TrueNtOpenProcess;

NtTerminateProcessPointer TrueNtTerminateProcess;

NtWriteVirtualMemoryPointer TrueNtWriteVirtualMemory;

NtDebugActiveProcessPointer TrueNtDebugActiveProcess;

NtTerminateThreadPointer TrueNtTerminateThread;

NtOpenThreadPointer TrueNtOpenThread;

ULONG OpenProcessId;

ULONG TerminateProcessId;

ULONG WriteVirtualMemoryId;

ULONG DebugActiveProcessId;

ULONG TerminateThreadId;

ULONG OpenThreadId;

ULONG GetPid(HANDLE ProcessHandle) {

PEPROCESS process=0;

ULONG PID;

ObReferenceObjectByHandle(

ProcessHandle,

0,

NULL,

KernelMode,

&process,

NULL);

__try

{

PID=(ULONG)PsGetProcessId(process);

}

__except(EXCEPTION_EXECUTE_HANDLER)

{

return STATUS_INVALID_PARAMETER;

};

ObDereferenceObject(process);

return PID;

};

NTSTATUS

NewNtTerminateThread (

IN HANDLE ThreadHandle,

IN NTSTATUS ExitStatus)

{

ULONG uPid = 0;

PETHREAD thread = NULL;

NTSTATUS status = STATUS_UNSUCCESSFUL;

status = ObReferenceObjectByHandle (

ThreadHandle,

0,

*PsThreadType,

KernelMode,

(PVOID*) &thread,

NULL);

if (! NT_SUCCESS (status))

{

return TrueNtTerminateThread (

ThreadHandle,

ExitStatus);

}

uPid = (ULONG) PsGetThreadProcessId (

thread);

ObDereferenceObject (

thread);

if (uPid==ProtectedPid) {

return STATUS_ACCESS_DENIED;

}

else return TrueNtTerminateThread (

ThreadHandle,

ExitStatus);

};

NTSTATUS NewNtOpenThread(

__out PHANDLE ThreadHandle,

__in ACCESS_MASK DesiredAccess,

__in POBJECT_ATTRIBUTES ObjectAttributes,

__in PCLIENT_ID ClientId) {

ULONG uPid = 0;

PETHREAD thread = NULL;

NTSTATUS status = STATUS_UNSUCCESSFUL;

status = ObReferenceObjectByHandle (

ThreadHandle,

0,

*PsThreadType,

KernelMode,

(PVOID*) &thread,

NULL);

if (! NT_SUCCESS (status))

{

return TrueNtOpenThread(ThreadHandle, DesiredAccess,ObjectAttributes, ClientId);

}

uPid = (ULONG) PsGetThreadProcessId (

thread);

ObDereferenceObject (

thread);

if (uPid==ProtectedPid) {

return STATUS_ACCESS_DENIED;

}

else

return TrueNtOpenThread(ThreadHandle, DesiredAccess,ObjectAttributes, ClientId);

};

NTSTATUS NewNtOpenProcess(

OUT PHANDLE ProcessHandle,

IN ACCESS_MASK DesiredAccess,

IN POBJECT_ATTRIBUTES ObjectAttributes,

IN PCLIENT_ID ClientId) {

ULONG ProcessId;

__try

{

ProcessId = ClientId->UniqueProcess;

}

__except(EXCEPTION_EXECUTE_HANDLER)

{

return STATUS_INVALID_PARAMETER;

}

if (ProcessId==ProtectedPid) {

return STATUS_ACCESS_DENIED;

}

else

return TrueNtOpenProcess(

ProcessHandle,

DesiredAccess,

ObjectAttributes,

ClientId);

};

NTSTATUS NewNtTerminateProcess(

IN HANDLE ProcessHandle OPTIONAL,

IN NTSTATUS ExitStatus) {

if (GetPid(ProcessHandle)==ProtectedPid) {

return STATUS_ACCESS_DENIED;

} else

return TrueNtTerminateProcess(

ProcessHandle OPTIONAL,

ExitStatus);

};

NTSTATUS NewNtWriteVirtualMemory(

IN HANDLE ProcessHandle,

IN PVOID BaseAddress,

IN PVOID Buffer,

IN ULONG NumberOfBytesToWrite,

OUT PULONG NumberOfBytesWritten OPTIONAL ) {

if (GetPid(ProcessHandle)==ProtectedPid) {

return STATUS_ACCESS_DENIED;

} else

return TrueNtWriteVirtualMemory(

ProcessHandle,

BaseAddress,

Buffer,

NumberOfBytesToWrite,

NumberOfBytesWritten OPTIONAL);

};

NTSTATUS NewNtDebugActiveProcess(

IN HANDLE ProcessHandle,

IN HANDLE DebugObject) {

if (GetPid(ProcessHandle)==ProtectedPid) {

return STATUS_ACCESS_DENIED;

} else

return TrueNtDebugActiveProcess(

ProcessHandle,

DebugObject);

};

NTSTATUS DriverDispatcher(

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp)

{

HANDLE tHandle;

PIO_STACK_LOCATION irpStack;

ULONG ioControlCode;

KIRQL Old;

irpStack = IoGetCurrentIrpStackLocation (Irp);

ioControlCode = irpStack->Parameters.DeviceIoControl.IoControlCode;

if (irpStack->MajorFunction == IRP_MJ_DEVICE_CONTROL) ProtectedPid = (HANDLE)ioControlCode;

Irp->IoStatus.Status = STATUS_SUCCESS;

IoCompleteRequest(Irp, IO_NO_INCREMENT);

return STATUS_SUCCESS;

}

VOID DriverUnload(IN PDRIVER_OBJECT DriverObject)

{

ULONG CR0Reg;

IoDeleteSymbolicLink(&SymbolicLinkName);

IoDeleteDevice(deviceObject);

__asm

{

cli

mov eax, cr0

mov CR0Reg,eax

and eax,0xFFFEFFFF

mov cr0, eax

}

NTCALL(OpenProcessId)=TrueNtOpenProcess;

NTCALL(TerminateProcessId)=TrueNtTerminateProcess;

NTCALL(WriteVirtualMemoryId)=TrueNtWriteVirtualMemory;

NTCALL(DebugActiveProcessId)=TrueNtDebugActiveProcess;

NTCALL(TerminateThreadId)=TrueNtTerminateThread;

NTCALL(OpenThreadId)=TrueNtOpenThread;

__asm

{

mov eax, CR0Reg

mov cr0, eax

sti

}

return;

}

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,

IN PUNICODE_STRING RegistryPath)

{

ULONG CR0Reg;

NTSTATUS st;

PCWSTR dDeviceName = L"\\Device\\NoTerminate";

PCWSTR dSymbolicLinkName = L"\\DosDevices\\NoTerminate";

RtlInitUnicodeString(&DeviceName, dDeviceName);

RtlInitUnicodeString(&SymbolicLinkName, dSymbolicLinkName);

st = IoCreateDevice(DriverObject, 0, &DeviceName, FILE_DEVICE_NULL, 0, FALSE, &deviceObject);

if (st == STATUS_SUCCESS)

st = IoCreateSymbolicLink(&SymbolicLinkName,&DeviceName);

OpenProcessId =0x07A;

TerminateProcessId=0x101;

WriteVirtualMemoryId=0x115;

DebugActiveProcessId=0x039;

TerminateThreadId=0x102;

OpenThreadId=0x080;

TrueNtOpenProcess=NTCALL(OpenProcessId);

TrueNtTerminateProcess=NTCALL(TerminateProcessId);

TrueNtWriteVirtualMemory=NTCALL(WriteVirtualMemoryId);

TrueNtDebugActiveProcess=NTCALL(DebugActiveProcessId);

TrueNtTerminateThread=NTCALL(TerminateThreadId);

TrueNtOpenThread=NTCALL(OpenThreadId);

__asm

{

cli

mov eax, cr0

mov CR0Reg,eax

and eax,0xFFFEFFFF

mov cr0, eax

}

NTCALL(OpenProcessId)=NewNtOpenProcess;

NTCALL(TerminateProcessId)=NewNtTerminateProcess;

NTCALL(WriteVirtualMemoryId)=NewNtWriteVirtualMemory;

NTCALL(DebugActiveProcessId)=NewNtDebugActiveProcess;

NTCALL(TerminateThreadId)=NewNtTerminateThread;

NTCALL(OpenThreadId)=NewNtOpenThread;

__asm

{

mov eax, CR0Reg

mov cr0, eax

sti

}

DriverObject->MajorFunction[IRP_MJ_CREATE] =

DriverObject->MajorFunction[IRP_MJ_CLOSE] =

DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DriverDispatcher;

DriverObject->DriverUnload = DriverUnload;

return STATUS_SUCCESS;

}



Додаток 2.

Початковий код програми, що здійснює обмін інформацієї з драйвером. Мова-Delphi

unit nt;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls;

type

TForm1 = class(TForm)

Button1: TButton;

Edit1: TEdit;

Button2: TButton;

Label1: TLabel;

procedure Button1Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);

private

{ Private declarations }

public

{ Public declarations }

end;

var

TrId:dword;

Form1: TForm1;

hDriver: dword;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

begin

hDriver := CreateFile('\\.\NoTerminate', GENERIC_ALL, 0,

nil, OPEN_EXISTING, 0, 0);

DeviceIoControl(hDriver, StrToInt64(Edit1.Text), nil, 0, nil, 0, TrId, nil);

Button1.Enabled:=false;

Button2.Enabled:=true;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

Label1.Caption:='PID='+inttostr(GetCurrentProcessId);

Edit1.Text:=inttostr(GetCurrentProcessId);

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

Button1.Enabled:=true;

Button2.Enabled:=false;

DeviceIoControl(hDriver,0, nil, 0, nil, 0, TrId, nil);

end;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);

begin

CanClose:=false;

end;

end.

Размещено на Allbest.ru