Операционные системы 09.02.03 2 курс. Автономной некоммерческой образовательной организации профессионального образования

• Название: Автономной некоммерческой образовательной организации профессионального образования
• Дата: 17.02.2021
• Размер: 0.57 Mb.
• Имя файла: Операционные системы 09.02.03 2 курс.doc
• Тип: Лекция; #177186
• страница: 20 из 20

Лекция №19

При помощи набора функций, которые экспортирует NTIS, возможно осуществление следующих действий:

1. 
   В них драйвер может получать сетевые пакеты для передачи от любых выше лежащих транспортных драйверов и посылать их в сеть через один или несколько сетевых адаптеров, которыми он управляет.
   
2. 
   NIC драйвер способен принимать сетевые пакеты от одного или нескольких сетевых адаптеров и передавать их одному или нескольким драйверам транспортных протоколов.
   
3. 
   Транспортный драйвер может задавать параметры конфигураций для NIC драйверов.
   
4. 
   Транспортный драйвер может запрашивать необходимые конфигурации или статистику работы любого NIC драйвера.
   
5. 
   NIC драйвер может через NT информировать драйвер транспортного протокола о внештатных ситуациях в процессе работы.
   

Драйвер NT имеет следующую архитектуру:


NP I S
I

NTERFACE



LAN PROTOCOLS …

LAN MEDIUM TYPE Medium


NTIS INTERHEATE
Aware

Protocols

NATUVE MEDIUM TYPE


NPIS MINIPORT


NPIS INTERFACE




NET CARD

LAN PROTOCOLS – транспортный протокол поддержки локальной сети.

LAN MEDIUM TYPE – типы сетевых интерфейсов, которые могут поддерживать транспортный протокол.

NTIS INTERHEATE – так называемый промежуточный драйвер NTIS, встраиваемый между драйвером транспортных протоколов и NIC драйвером, позволяющим проводить………………..

…………………….тип транспортного протокола, непосредственно взаимодействующим с оригинальным сетевым интерфейсом NIC, которые могут отличаться от стандартных.

APP (запрос)





з
добавление
аголовок




ADI IRP данные
коды



(оболочка)
NATUVE MEDIUM TYPE – оригинальные сетевые интерфейсы, которые экспортируют в NIC – драйвер. Эти интерфейсы могут быть отличны от трех, которые поддерживают транспортные драйверы. При помощи слоя промежуточных драйверов эти интерфейсы могут быть скрыты от слоя транспортных протоколов. Вместо них промежуточный драйвер иммулируют стандартные типы сетевых протоколов.

NPIS MINIPORT – NIC драйвер, поддерживающий стандартный минипорт (обеспечивает более легкую обработку, библиотеку).

Библиотека NPIS обеспечивает ………. NIC драйверов, полностью независящих от конкретной реализации средой разработки; любая внешняя функция, которая может быть использована разработчиком, может быть выполнена библиотекой.

Включает:

• 
  Функцию взаимодействия транспорта с протоколом.
  
• 
  Регистрацию обработки прерывания
  
• 
  Передача информации через порты ввода- вывода и т.д.
  

2 технологии:

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

Промежуточный сетевой драйвер встраивается между слоем транспортного протокола и слоем NIC драйверов. Возможно послойное встраивание промежуточных сетевых драйверов. Промежуточный драйвер будет иммулировать для слоя транспортных протоколов объекты адаптера NIC драйвера; для NIC драйвера – объект транспортных протоколов.

Недостатки:

• 
  Энергоемкость достаточно большая у промежуточного сетевого драйвера (1 драйвер – 2 лишних объекта)
  
• 
  Трудоемкость встраивания промежуточного драйвера в подсистему удаленного доступа
  

2. 
   Встраивание подсистемы защиты основано на встраивании подсистемы в оболочку NTIS.
   

Применение данного подхода имеет следующие преимущества:

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

Для того, чтобы работа драйвера была успешной, нужно:

• 
  Изменить порядок запуска так, чтобы наш драйвер запускался сразу после драйвера NTIS.
  
• 
  Установить свои обработчики на некоторые экспортируемые драйвером NTIS функции.
  

Например:

1. 
   Send Complete Handier (функция завершения посылки сетевого пакета)
   
2. 
   Wan Send Complete Handier (функция завершения через глобальную сеть)
   
3. 
   Transfer Data Complete Handier (функция завершения получения сетевого пакета от драйвера сетевого адаптера)
   
4. 
   Функция завершения обработки запроса драйвера сетевого протокола в драйвер сетевого адаптера и т.д.
   

Лекция №20

Динамически подключаемая библиотека (dynamic_link_library DLL)

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

Чтобы приложение могло вызвать функции, содержащиеся в DLL, образ её файла нужно спроецировать на адресное пространство вызывающего ее процесса. Это можно сделать за счет явного связывания за время выполнения при загрузке. После проецирования DLL на адресное пространство вызывающего процесса, все её функции достается всем потокам процесса. Когда поток вызывает какую- либо функцию из DLL, функция считывает параметры из стека потока. Любые созданные кодом DLL объекты принадлежат вызывающему потоку. Сама DLL ничем не владеет.

1. 
   Неявносвязывание:
   Самый распространенный и простой метод. Для создания DLL:
   

1. 
   Пишем заголовочный файл с прототипами функций, структурами и идентификаторами, которые будут экспортировать данные в DLL.
   
2. 
   Пишем на Си модуль исходного кода с телами функций.
   
3. 
   Компилируем, получаем объектный файл.
   
4. 
   Все объектные файлы собираются в один загруженный DLL – модуль, где двоичный код и глобальные переменные.
   
5. 
   Если компоновщик обнаружит, что DLL экспортирует хотя бы одну переменную или функцию, создается .LIB. В .LIB находится список символьных имен функций и переменных, экспортируемых из DLL.
   
6. 
   Во все модули исходного кода, где есть ссылки на внешнюю функцию, переменные, структуру данных или идентификатор, нужно включить заголовочные файлы.
   

После этого приложение на выполнение.

При запуске загрузчик выполняет следующие действия:

1. 
   Загрузчик ОС создает виртуальное адресное пространство для нового процесса и проецирует на него исполняемый модуль.
   
2. 
   Загрузчик анализирует отдел импорта, находит нужные DLL модули и проецирует на адресное пространство процесса.
   
3. 
   Поскольку DLL может импортировать функции из другой DLL, у неё может быть свой отдел импорта.
   
4. 
   Загрузчик просматривает отдел всего импорта каждой DLL и проецирует все DLL в адресное пространство процесса.
   

Явная загрузка DLL:

Проецирование DLL на адресное пространство.

Код приложения ссылается на идентификаторы, содержащиеся в DLL, и тем самым заставляет загрузчик неявно загружать DLL при запуске приложений.

2. 
   Явное связывание в период выполнения приложений.
   

Поток явно загружает DLL, получает адрес ………….и вызывает функцию по имеющемуся адресу. Это происходит при выполнении приложений.

2 функции:

MINSIANCE Load Library (PCISIR psz Path name)

MINSIANCE Load Library Ex (PCISIR psz Path name, HANDLE, hFile, Dword dw Flags)

Обе функции ищут образ DLL файла и пытаются спроецировать его на адресное пространство вызывающего процесса. Значение ……………………сообщает адрес виртуальной памяти, куда проецируют образ файла.

Параметры:

• 
  Имя (1 функция)
  
• 
  hFile (2 функция) – зарезервировано; через него можно передавать NULL
  
• 
  dw Flags – можно передавать либо 0, либо комбинацию флагов.
  

Флаги:

1. 
   DONT_ RESOLVE_ DLL_ REFERENDES (указывает системе спроецировать DLL на адресное пространство вызывающего процесса; проецируя DLL, система обычно вызывает из ……. DLL-main – с помощью этой функции инициализируется соответствующая библиотека; установка этого флага позволяет спроецировать DLL без обращения к DLL-main, проверки на загрузку дополнительной DLL не производиться)
   
2. 
   LOAD_ LIBRARY_ AS_DATAFILE (позволяет загрузить библиотеку с файлами данных. DLL-main не вызывается, DLL проецируется как файл данных (вызова DLL не происходит)
   
3. 
   LOAD_ WITH _ALTEREAD_SEARCH_PATH (изменяет алгоритм исполняемой функции при поиске DLL файла)
   

Алгоритм:

1. 
   каталог, заданный в первом параметре Pathname.
   
2. 
   текущий каталог процесса
   
3. 
   системный каталог WINDOWS
   
4. 
   основной каталог WINDOWS
   
5. 
   каталоги, перечисленные в переменном окружении.
   

Как только необходимость в DLL отпадает, её можно выгрузить из адресного пространства процесса.

Bool Free Library (HINSANCE hinds DLL)

Передаем тот параметр, который получили.

Чтобы получить явный адрес экспортируемого идентификатора (имя функции), существует вызов:

Far prog Get Prog Address (Hiwstance hinds DLL, PCISIR psz Symbol Name)

Symbol Name может быть указан в двух форматах:

1. 
   имя (например, HEYD)
   
2. 
   порядковый номер (например, 2)
   

В DLL может быть только одна функция входа – вызова. Используется для инициализации или очистки входа в DLL. Если инициализация не нужна, создавать необязательно.

Если нужно, то должна быть следующая:

H 300L WINAPI DLL MAIN (…)

{switch (fdw Reason)

case: DLL_PROCCESS_ATTACH

case: DLL_THREAD_ATTACH

case: DLL_ THREAD _DETACH

case: DLL_PROCCESS_DETACH}
DLL_PROCCESS_ATTACH вызывается только 1 раз; при вызове флажка будет выполняться инициализация.

DLL_THREAD_ATTACH – при создании нового потока система просматривает все DLL, спроецируемые на данный момент на адресное пространство данного процесса и…………………….

DLL_PROCCESS_DETACH – отключает, вызывается только 1 раз …………………. (DLL). Всю память очищают (инициализируют).

Лекция №21

Внедрение DLL

Внедрение:

1. 
   Использование реестра
   

HKLM\ Soft Ware\ Microsoft\ Windows NT\ Current version\ Windows\ App_ Init_ DLLS

Значение параметра App_ Init_ DLLS может быть как имя одной DLL, так и нескольких, разделенных пробелами, либо запятыми.

При перезагрузке реестр сохраняется.

Когда модуль User_32 будет спроецирован на адресное пространство, модуль получит уведомление DLL_ Process_ Attach, и после его обработки вызовет Load_ Library для всех DLL, указанных в строке App_ Init_ DLLS.

В момент загрузки DLL инициализируется как DLL-main. User_32 DLL использует все приложения, использующие графический интерфейс. Во все оконные приложения загружена библиотека.

Трудности:

1. 
   Поскольку внедренная DLL загружена на ранней стадии процесса, требуется осторожность при вызове функций в самой DLL. Проблема вызова функций из модуля Kernel_32 DLL проблем нет. User_32 DLL не проверяет, загружены ли другие библиотеки.
   
2. 
   Т.к. параметры реестра считываются из конфигурации, требуется перезагрузка (для NT 4.0 и более низкие). С Windows 2000 проверка App_ Init_ DLLS проверяется и используется при загрузке каждого нового процесса.
   
3. 
   Т.к. библиотека попадает в разные графические приложения, можно проверить.
   
4. 
   DLL проецируется на адресное пространство на все время жизни.
   

2. 
   Внедрение потоков с помощью удаленных потоков.
   

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

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

Для этого существует функция:

Create Remote Thread (HANDLE hProcess

PRECURITY_ATTRIBUTES pza;

DWORD dw StackSize;

PTHEARD START_RBITINE

pfn Start ADDR

PVOID pv PARAM;

DWORD Sdw Create;

pdword pdw Thread ID ;)

Идентификатор HANDLE hProcess определяет процесс, которому будет принадлежать новый поток (его нет в Create Thread).

Параметр pfn Start ADDR определяет адрес функции потока, причем этот адрес относиться к удаленному процессу. Чтобы заставить вновь созданный поток загрузить в DLL, нужно, чтобы он вызвал Load_Library, необходимо выяснить точный адрес в памяти.

Load_Library А и Load_ Library W определяются передачей информации (в ASCII и ЮНИКОД формате).

Для выяснения точного адреса существует функция:

Get Process Address
Create Remote Thread относится к ядру, находится в Kernel 32 DLL, который используется всеми приложениями. Kernel 32 проецируется, как правило, по одному адресу во всех процессах.

PTHEARD_ START_ ROUTINE _pfn THEARD Rth = (PTHEARD_ START_ ROUTINE) Get Proc Address (Get MoubleHandle (Text (“Kernel 32”)), “Load Library А”)

HANDLE hTheard = Create Remote Thread (hProcess Remote, NULL, Ø, pfn Thread Rtf, “C:\\MyLib.dll”, Ø, NULL);

Строка, которая содержит полное имя файла DLL, находится в адресном пространстве вызывающего процесса. Её адрес должен быть передан созданному потоку, который передает его в Load Library А. Мы должны разместить строку с полным именем DLL в адресном пространстве удаленного процесса. Для этого функция Virtual alloc Ex, которая позволяет выделять память в чужом адресном пространстве.

Pvoid Virtual Alloc Ex (HANDLE hProcess;

PVOID pv Address;

SIZE_T dw Size;

DWORD dw Allocation type;

DWORD fl Protect;)

Для освобождения – Virtual Free Ex.

Далее копируем имя библиотеки из нашего процесса в удаленный.

WRITE Process Memory (HANDLE hProcess

PVOID pv Address remote

Адрес строки → PVOID pv Buffer Local,

с именем библиотеки

PVOID dw Size

PDWORD pdw Num bytes Written)
Общая последовательность операций:

1. 
   Выделение блока памяти Virtual Alloc Ex.
   
2. 
   Вызывает функцию WRITE Process Memory и копируем строку с адресом.
   
3. 
   Используя функцию Get Proc Address получаем истинный адрес функции Load Library А (W) в модуле Kernel 32.
   
4. 
   Вызываем Create Remote Thread, который вызовет Load Library, который передаст строку с именем загружаемой библиотеки.
   
5. 
   DLL внедрена, DLL- main получает DLL_ PROCCESS_ ATTACH, которая выполняет свои действия.
   
6. 
   После этого выполнение необходимых действий: вызов Virtual Free Ex (освобождение блока), с помощью Get Proc Address выяснение адреса функции free Library. Используя Create Remote Thread вызываем поток, который вызовет free Library и удалит библиотеку.
   

3. 
   Замена DLL загружаемого процесса на другую DLL с тем же самым именем.
   

Недостатки:

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

Суть метода: переименование исходной DLL, используем нашу DLL с именем исходной DLL.

4. 
   Перехват API вызовов.
   

1. 
   Ищется адрес функции, вызов которой необходимо перехватить.
   
2. 
   Копируем начальные n байтов, сохраняем у себя в памяти; на их место вставляем jmp с адресом нашей функции.
   

Недостатки:

В системе с вытесняющей многозадачностью может не работать.

Суть метода:

5. 
   Перехват API вызова с помощью раздела импорта.
   

В разделе импорта содержится список DLL, необходимые модулю для работы. В разделе перечислены все идентификаторы, которые наше приложение экспортирует из каждой DLL. При вызове экспортирующей поток получает её адрес из раздела импорта. Для перехвата функции – изменение её адреса в разделе импорта.