компьютерный вопрос

[dok34.ru]

В современной винде драйвера стандатритизированы. Это не как в windows 90-ых. Там надо его подстраивать под диспетчер ввода, вывода. Есть irp пакет, и он ожидает ссылки на функции которые надо прочитать (read, write, close, open и другие). Все на с++ пишется в режиме ядра. Еще надо прописать взаимодействие не только с диспетчером вводом вывод который irp пакеты создает, но и с plug and play, а также с диспетчером энергопотребления и с другими драйверами. Скажем, есть общий драйвер порта. Вы пишите драйвер минипорта для устройства. Значит надо учитывать драйвер порта который находится выше в иерархии. Меня как безопасницу больше инетерсует не ввод вывод а фильтры. Антивирусы как фильтры работают между диспетчером вводом вывода и драйверами, анализируют безопасная это операция или нет. Вирусы тоже могут работать как фильтры. Анализировать инфу и сбрасывать ее злодеям. Меня этот аспект интересует. Вирусы которые работают как фильтры в ядре. Раньше, до windows vista было проще разработчиков вирусов и антивирусов. Современную винду очень легко довести до синего экрана смерти, так как там есть patch guard, который делает модификацию кода ядра очень сложным. Если сделать -- то все, синий экран смерти. А до patch guard, до windows vista антивирусы часто занимались hooking. Сейчас тоже можно заниматься хукингом, но на уровне ntdll.dll. Хотя один из авторов книги windows internals Павел Йософович говорит, что хугинг на уровне ядра, ntos.exe, a не ntdll.dll возможен. Но надо знать хорошо алгоритмы patch guard. Но навряд ли разработчики антивирусов к этому прибегают, так как это будет часто вызывать синие экраны смерти. Но вирус может попытаться это рискнуть сделать, но тоже риск быть замеченным велик. Если patch guard видит модификацию критического года я ядре -- сразу синий экран.

О, спасибо, интересно!
Про минипорт к базовому драйверу хорошо объяснили!
А с ядром я давно не общался, всё новое!
В линуксе есть исходники, ядро можно самому компилить под нужное железо и задачи. Тут понятно, всё закрытое, но интересно!
... только я пожалуй перенесу сейчас в Комповую тему 🙂

 

[Ksenia]

О, спасибо, интересно!
Про минипорт к базовому драйверу хорошо объяснили!
А с ядром я давно не общался, всё новое!
В линуксе есть исходники, ядро можно самому компилить под нужное железо и задачи. Тут понятно, всё закрытое, но интересно!
... только я пожалуй перенесу сейчас в Комповую тему 🙂

Драйвер шины еще есть, на более высоком уровне. Который перечисляет все устройства к ней подключенные. Плюс в windows все репрезентируется как объекты, в отличие от linux (все файлы). Есть отдельно объекты устройств, объекты драйверов, которые диспетчером объектов контролируются. Можно посмотреть список объектов, его дерево с помощью специальных инструментов windows Internals. При том прикладные программы не могут получать ко многим объектам напрямую, в том числе к объектам устройств. Только через символическую ссылку если она есть. Такой символической ссылкой является путь к файлу, например. К именованным объектом можно получить доступ с уровня пользователя. Например, к мьютексам, семафорам, объектам синхронизации, именованным каналам и пр, но только в рамках сессии. Сессия -- это тоже объект, как и windowstation (несколько), в которой объекты рабочего стола (несколько) К другим -- только через символическую ссылку. Которая диспетчером объектов переводится в реальный путь к объекту, и к зависимости от операции и типа объектов диспетчер объектов переправляет вызов в ту или иную подсистему. Вообще, это все очень сложно. 2000 страниц, два тома. Руссинович и Йософич винду очень долго копали...Как я поняла, отдельные окна, кнопки, меню (кнопки, меню -- тоже окна) не объекты ядра, а это все относится к user32.dll. Также когда программист пишет на с++ программу для windows, он входит в цикл извлечения сообщений из очереди (нажатие клавиши мыши, клавиатуры) -- это все user32.dll, и очередь не объект ядра, нет.

Интересно что одна и та же сущность в винде представлена несколькими структурами. Например, процесс на уровне исполнительного уровня ядра структурой Eprocess, глубже на уровне ядра -- Кprocess. Потом для каждой подсистемы и для каждого сеанса есть процесс подсистемы, подсистема win32 -- это процесс csrss.exe, и он хранит структуры процессов за которые он ответственен (в рамках своего сеанса и подсистемы), и диспетчер объектов поддерживает репрезентацию объектов ядра, в том числе процессов, но не всех. И их список можно посмотреть.

 

[Ksenia]

Драйвер шины еще есть, на более высоком уровне. Который перечисляет все устройства к ней подключенные. Плюс в windows все репрезентируется как объекты, в отличие от linux (все файлы). Есть отдельно объекты устройств, объекты драйверов, которые диспетчером объектов контролируются. Можно посмотреть список объектов, его дерево с помощью специальных инструментов windows Internals. При том прикладные программы не могут получать ко многим объектам напрямую, в том числе к объектам устройств. Только через символическую ссылку если она есть. Такой символической ссылкой является путь к файлу, например. К именованным объектом можно получить доступ с уровня пользователя. Например, к мьютексам, семафорам, объектам синхронизации, именованным каналам и пр, но только в рамках сессии. Сессия -- это тоже объект, как и windowstation (несколько), в которой объекты рабочего стола (несколько) К другим -- только через символическую ссылку. Которая диспетчером объектов переводится в реальный путь к объекту, и к зависимости от операции и типа объектов диспетчер объектов переправляет вызов в ту или иную подсистему. Вообще, это все очень сложно. 2000 страниц, два тома. Руссинович и Йософич винду очень долго копали...Как я поняла, отдельные окна, кнопки, меню (кнопки, меню -- тоже окна) не объекты ядра, а это все относится к user32.dll. Также когда программист пишет на с++ программу для windows, он входит в цикл извлечения сообщений из очереди (нажатие клавиши мыши, клавиатуры) -- это все user32.dll, и очередь не объект ядра, нет. Интересно что одна и та же сущность в винде представлена несколькими структурами. Например, процесс на уровне исполнительного уровня ядра структурой Eprocess, глубже на уровне ядра -- Кprocess. Потом для каждой подсистемы и для каждого сеанса есть процесс подсистемы, подсистема win32 -- это процесс csrss.exe, и он хранит структуры процессов за которые он ответственен (в рамках своего сеанса и подсистемы), и диспетчер объектов поддерживает репрезентацию объектов ядра, в том числе процессов, но не всех. И их список можно посмотреть.

Понятно, что если писать программы на Java или на C#, то это все тонкости не нужны. Даже базовую архитектуру ОС знать не нужно, так как код C# или Java предполагает наличие не сложных подсистем операционной системы, а виртуальную среду (.NET или Java-машину), виртуальную машину, довольно-таки дружественную, где все надежно, да еще и мусор автоматически убирается. Это для тех, кто на С/С++ всякие сложности пишет 🙂 Это просто я хардкорщица, поэтому глубоко копаю 🙂

 

[dok34.ru]

Понятно, что если писать программы на Java или на C#, то это все тонкости не нужны. Даже базовую архитектуру ОС знать не нужно, так как код C# или Java предполагает наличие не сложных подсистем операционной системы, а виртуальную среду (.NET или Java-машину), виртуальную машину, довольно-таки дружественную, где все надежно, да еще и мусор автоматически убирается. Это для тех, кто на С/С++ всякие сложности пишет 🙂 Это просто я хардкорщица, поэтому глубоко копаю 🙂

...аналогично, коллега!
Тоже предпочитаю понимать происходящее.