Драйвера WinNT

Здравствуйте.
Если знаете ответы на эти вопросы, то ответьте, пожалуйста.
Также очень прошу, писать только тем, кто занимается программированием драйверов под WinNT, и знает тему. Тем кому просто интересно, ОЧЕНЬ прошу ни писать. За ответы типа "DDK рулит", буду просит модератора убрать сообщение. Тема сложная, поэтому прощу говорить только по существу. Если ответ большой, то дайте ссылку на литературу по теме. Русиновича и Соломона, просьба не называть.

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

У меня есть пакет WinDDkXP, там есть утилита, Device Tree V2.6, она показывает драйверы установленные в системе, но там нет описания работы драйвера, что он конкретно делает, какие параметры принимает и отдает.

Например, мне нужно обратится к железу или портам. LPT, COM, USB. Соответственно, нужно вызвать соответствующий драйвер и:
установить его, запустить, получить к ниму доступ, передать параметры, указывающие, какой, конкретно порт я хочу задействовать и с какими установками - все это в пользовательском приложении, осуществляющее работу с драйвером, работающим в режиме ядра.

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

Можно вызвать определенный (системный или пользовательский) драйвер, самостоятельно, из пользовательского приложения?
Передать ему параметры, из пользовательского кода, чтоб он выполнил определенную работу?
Что будет, если подобный драйвер уже вызван, и я вызываю его сам и инициализирую на определенную работу?

Функция

Код (Text):

1. DeviceIoControl(
2.   HANDLE hDevice,
3.   DWORD dwIoControlCode,
4.   LPVOID lpInBuffer,
5.   DWORD nInBufferSize,
6.   LPVOID lpOutBuffer,
7.   DWORD nOutBufferSize,
8.   LPDWORD lpBytesReturned,
9.   LPOVERLAPPED lpOverlapped
10. );

- осуществляет передачу-прием между драйвером и пользовательским приложением через SCManager.
3. Где в параметрах этой функции, параметры, передаваемые для драйвера? Параметры принимаемые от драйвера?

4. Для передачи драйверу из пользовательского приложения, данных, используется ф-ия DeviceIoControl(...,IOCTL_PRINT_DEBUG_MESS, ...).
Обработка в драйвере поступающих данных, осуществляется, для параметра IOCTL_PRINT_DEBUG_MESS, вот таким способом:
ULONG ControlCode = IrpStack->Parameters.DeviceIoControl.IoControlCode;
Как выделить все остальное?


Я читаю литературу, но кое-что не понятно.

 

lpInBuffer - передаваемые
lpOutBuffer - принимаемые параметры

это уже просто так не узнаешь. либо реверс, либо посик сорсов

 

RamMerLabs, WinXP не документирована на эту тему? Чтоб это знать нужно мониторить каждый драйвер?

 

probka
на сайте возьми программу Four-F
https://wasm.ru/baixado.php?mode=tool&id=254

 

Отвечаю по порядку.

1) Можно узнать список драйверов, список создаваемых виртуальных устройств ими (объектов Device, подробности в ddk), но узнать то, что они могут делать и как к ним для этого обращаться - это либо реверс, либо поиск исходников.
Это обычно не афишируется, за некоторыми исключениями (стандартные драйвера и их интерфейсы описаны в ddk & co)

2) Можно вызвать драйвер или нет зависит от того, как он регистрируется. Если драйвер создает объект "устройство" с символьной ссылкой на него, то ему можно отправить запросы IRP через функции CreateFile, ReadFile, WriteFile, DevceIoControl и другие. Обычно для связи пользоватлеьского приложения и драйвера используется DeviceIoControl, как наиболее универсальная.

3) Фунция ничего не знает ни о драйвере, ни о параметрах, поэтому она принимает указатель на входной буффер, его размер, указатель на выходной буффер и его размер. Как трактовать буффера решает драйвер.

4) Irp->SystemBuffer содержит копию входного буффера и туда можно записать что-то. Оно будет скопировано менеджером ввода-вывода в выходной буффер. Подробности в статьях Four-F, у Руссиновича и в DDK.

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

 

Great, мне нужен только список драйверов. С описанием их работы. Это все.
реверс, ddk & co - это что?
У меня есть MSDN 2006 и WinDDK 2600. Это то, что мне удалось достать. Обновить не получается.

Four-F - это то же самое что и Device Tree V2.6.

Я могу заново переписать драйвер ядра? Удалить тот который в ядре и поставить свой?

 

Для того чтоб к COM порту обратится, нужно сделать так:

Код (Text):

1. #include <windows.h>
2. . . .
3. HANDLE port;
4. . . .
5. port=CreateFile("COM2", ...

Но кроме COM порта, как обратится к другому железу (шины, чипсеты, карты, хард)?
Какие есть еще идентификаторы? И как/где узнать их?

 

Реверсинг драйвера.
DDK & co - имел в виду ddk и компанию типа ifs kit и других хелп систем по ринг0 кодингу от m$

при желании да. а цель?

Про реверс-инжинеринг слыхал?

 

это, скорее, исключение, чем правило.
Чувак, почитай сначала про то, как работают драйвера, у Four-F отличный цикл статей, в добавок к этому конечно Руссиновича почитай. Особенно про девайсы и символьные ссылки.
Мне сейчас расписывать это нет времени да и не зачем, поскольку в соответствующей литературе это описано гораздо более подробно, чем я могу себе это позволить здесь.

 

Great, скачал, по ссылке, которую дал wsd. Называется WinObjEx.exe.

Реверсинг драйвера - что это?

Улучшение, оптимизация.

Нет. Дай ссылки, пожалуйста.

Да. Согласен. Но я думаю на C/C++, а не на асме. Мне нужен С/С++, на основе ООП.

Руссиновича и Соломона, читать не посоветую даже врагу. Эту книгу сжечь надо. Ни чего личного. Я читал её. Это просто пипец.

Значит к другим девайсам по другому обращаются?

 

Может в помощь

Если автор не удалил
Утилита для просмотра списка устройств и IRP-стека каждого устройства
http://gr8.cih.ms/uploads/devstack.rar
http://gr8.cih.ms/uploads/devstack-src.rar

http://www.geocities.jp/webcrazyjp/irpmon.htm
http://www.geocities.jp/webcrazyjp/irpmon.zip

http://www.tssc.de/products/tools/irptrace/detail.htm
http://www.tssc.de/download/prods/irptrace.exe

Если зарегестрирован на osronline
DeviceTree
http://www.osronline.com/article.cfm?article=97
IrpTracker
http://www.osronline.com/article.cfm?article=199

Ещё раньше была утилита driverspy, ссылок под рукой нет.
Ну и проект с форума sysinternals
http://rapidshare.com/files/99662550/driverdetect.rar.html

 

probka

оптимизация ядра??? ну-ну... может и ОСЬ наподобие Винды сделаете?

ООП крайне мало применим для разработки драйверов

это Вас, товарисч, сжечь нужно за подобные заявления. в чём смысл лезть в программирование драйверов, не понимая, как действует система. а указанная книга наиболее подробно описывает устройство win.
прочтите её ещё раз, но разбираясь во всех деталях, и 99.(9)% вопросов сами найдут ответы.

 

msinfo32 - самый банальный список устройств, если уж на то пошло

 

probka

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

В целом возми вот это http://www.wasm.ru/baixado.php?mode=tool&id=254 далее зайди в подпункт Global?? Все что в строке с именами может быть открыто при наличии соответсвующих прав функцией CreateFile("xxx", собственно вот ответ на твой вопрос. А далее что бы понять, что тузла выводит - читай Руссиновича

 

То, что ты ее не понял, не значит, что она плоха.

У меня сложилось впечатление, что ты ничего не знаешь о работе драйверов, но хочешь узнать всё за один раз. Чел, так не получится при всем желании.

google.ru

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

Именно. Читай про символьные ссылки, я уже сказал кого читать - Four-F, DDK, Руссинович.

1) Большинство драйверов пишут на Си
2) Если ты ставишь в один ряд С и С++, которые не имеют ничего общего, значит ты не знаешь ни то, ни другое.


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

 

Спасибо, что напомнили - перезалил версию поновее.

 

Ra_ , скачал. Спасибо.
RamMerLabs:

А чо там делать .., чел..? У тебя intel на уровне таракана что-ли?

Сказал как в воду пернул. ВСЕ(!) драйвера в winde строятся на ООП(!). Для тебя это новость!?

Вот вы ее и зачитывайте до дыр. Архитектуру я знаю. Мне детали нужны.

Ага .., а лопотомию мне за ваш счет потом делать будут?
eight, спасибо, с мира по нитке, как говорится ...
PROFi, я это понимаю. Но тяжела слишком книга эта.

Спасибо тебе огромное, а можно где-нибудь прочитать, что делает каждая? Ее задачи по функционалу? То есть нужно переходить по Ring(n)? В какой момент? И как это сделать безболезненно?

Great, извини, конечно, но Даос, это, кажется, ассоциируется с "правильным путем"?
"Путь Даоса" - есть такая фича, кажется?

Плохих нет учеников, есть лекторы.
О дравах я знаю. И много, буть спокоен. Сам их дела(л)(ю).

Чувак, чувак, только мне не надо мОзги компостировАть, ладно? Знаем мы всю эту "движуху". Когда то что можно сделать за 3 месяца делается за 3 года, только потому, что истинная причина длительности проекта, шизо главного инжинера и очко-втирательства
заказчику.

Что!!? Не вынуждай меня матерится.
И хватит уже только о себе думать. С другими тоже надо делится, чувак.

Вот, если знаете, ответьте, еще, пожалуйста:
В одном тестовом примере драйвера, в функции DriverEntry, есть такая регистрация процедур:
DriverObject->MajorFunction[IRP_MJ_READ] = ReadWrite_IRPhandler;
DriverObject->MajorFunction[IRP_MJ_WRITE] = ReadWrite_IRPhandler;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]= DeviceControlRoutine;

В описании написано, что процедура ReadWrite_IRPhandler предназначена для обработки запросов Диспетчера ввода/вывода, которые он формирует в виде IRP пакетов с кодами IRP_MJ_READ/IRP_MJ_WRITE по результатам обращения к драйверу из пользовательских приложений с вызовами read/write или из кода режима ядра с вызовами ZwReadFile или ZwWriteFile

Процедура DeviceControlRoutine предназначена для обработки запросов Диспетчера ввода/вывода, которые он формирует в виде IRP пакетов с кодом IRP_MJ_DEVICE_CONTROL по результатам обращения к драйверу из пользовательских приложений с вызовами DeviceIoControl

Это две процедуры которые общаются с Диспетчера ввода/вывода и принимают параметры от него, переданные из пользовательского приложения.
Управление драйвером и, соответственно, железом, осуществляет процедура DeviceControlRoutine.
Какие задачи выполняет процедура ReadWrite_IRPhandler? Общается с Диспетчером ввода/вывода и, ОБСЛУЖИВАЕТ"?", основную передачу управляющих данных?

 

Read(Write)File -> NtRead(Write)File -> генерация пакета IRP_MJ_READ (WRITE) и вызов этой функции (FastIo не в счет).
Соответсвенно, она отвечает за то, как записать (не обязательно физически записать) переданный в WriteFile буффер и как прочитать в буффер для ReadFile (тоже не обязательно физически ниоткуда читать).

 

Great, но ведь мы уже управляем драйвером при помощи DeviceControlRoutine.
Какие передачи идут через ReadWrite_IRPhandler? Для какой цели?

 

да, ваши знанийа подтверждаются сложностью заданного вопроса. Great крут, не каждый гуру нашел бы ответ.