Получение списка модулей процесса

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

Начинаем с описания недостающих данных. Структура DEBUG_BUFFER есть по ссылке выше, а остальное вот.Быстренько повторим теорию. Для приема отладочной информации процесса первым делом надо подготовить буфер в памяти, это делается с помощью недокументированной функции RtlCreateQueryDebugBuffer. Дальше заполняем его данными с помощью недокументированной функции RtlQueryProcessDebugInformation, как это делали ранее при работе с кучей. Стоит упомянуть, что огромный плюс этой функции в том, что ей для работы требуется только идентификатор процесса, сам процесс открывать не надо. Для работы с другими процессами достаточно будет привилегии SeDebugPrivilege.

Читать статью целиком »

Передача данных между процессами с помощью Mailslot

Mailslot - один из самых простых способов обмена данными между процессами, который работает еще со времен Windows 95. Каналы Mailslot позволяют передавать данные от одного или нескольких клиентов к одному или нескольким серверам, в том числе в широковещательном режиме. На локальном компьютере может быть один серверный процесс, но в сети или в домене может одновременно работать несколько серверов. Количество клиентских приложений не ограничено. Принцип работы Mailslot схож с работой электронной почты.

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

Для создания канала используется функция CreateMailslot, которая в качестве одного из параметров принимает имя канала. Имя канала для серверного приложения должно иметь вид \\.\mailslot\имя_канала, при этом имя должно быть уникальным для приложения, но одинаковым в пределах клиента и сервера. Создавать канал должна серверная часть приложения. Она же определяет максимальный размер передаваемых сообщений и время ожидания. В случае необходимости этот параметр можно менять при помощи функции SetMailslotInfo.

Получив хэндл канала, сервер будет читать из него присланные сообщения. Обработчик выполняется в цикле по таймеру или же в отдельном потоке с задержкой между итерациями. Каждый шаг цикла начинается с получения состояния канала, это делается при помощи функции GetMailslotInfo, она возвращает количество сообщений в очереди на момент запроса и размер сообщения, которое будет получено первым. Если сообщений в очереди нет, то после выполнения функции параметр lpMessageCount будет равен нулю, а параметр lpNextSize примет значение MAILSLOT_NO_MESSAGE. Полученные сообщения читаются из канала функцией ReadFile, будто из обычного текстового файла.

Читать статью целиком »

Запуск задания cron с интервалом меньше 60 секунд

Как известно из документации, минимальный интервал запуска заданий в cron равен 1 минуте. Причина такого ограничения понятна, минутный интервал нужен, чтобы не перегрузить систему параллельными задачами в случае некорректных настроек. А мне понадобилось запускать определенный процесс каждые 20 секунд. Да, можно было бы написать промежуточный скрипт, который запускался бы раз в минуту по планировщику, а потом запускал процессы с нужными интервалами. Но есть более красивое решение средствами самого cron. Для того чтобы какое-либо задание запускалось каждые 20 секунд, в файле crontab нужно сделать 3 записи, что-то типа такого:

####################################################
# Запуск задания каждые 20 секунд
####################################################

* * * * * /usr/local/bin/php -f /path/to/script.php
* * * * * (sleep 20 ; /usr/local/bin/php -f /path/to/script.php)
* * * * * (sleep 40 ; /usr/local/bin/php -f /path/to/script.php)

Теперь каждую минуту будет запускаться пакет из трех заданий, но самое первое стартует незамедлительно, второе запустится через 20 секунд, а третье только через 40 секунд. Таким образом исходная задача будет решена. А, например, для запуска заданий с интервалом в 30 секунд понадобятся только две записи, и пауза перед вторым заданием, соответственно, будет 30 секунд.

Отслеживание загрузки dll в память процесса

Ранее я уже рассказывал, как можно легко и просто получить список динамических библиотек, загруженных в ваш процесс. Сегодня расскажу о возможности отслеживания загрузки и выгрузки DLL. Начиная с Windows Vista, появилась функция LdrRegisterDllNotification. С ее помощью в приложении регистрируется callback-функция, которая будет вызываться каждый раз, как только в ваше приложение будет загружена DLL или какая-то DLL будет выгружена из его адресного пространства. Установка обработчика выполняется одной командой:Важное замечание. Как показала практика, в callback-функции не должно быть никаких открытий окон, вывода сообщений и прочих взаимодействий с интерфейсом. Это может привести к зацикливанию и падению приложения во время загрузки UI-библиотек.При каждом вызове в callback-функцию передается причина вызова - загрузка или выгрузка DLL, а также заполненная структура NOTIFICATION_DATA, в которой содержится полный путь и имя файла библиотеки, базовый адрес загрузки и размер загружаемого образа. Зная эти данные, можно проверить, что за DLL пытаются подгрузить в наш процесс и принять соответствующие меры. Например, при попытке подгрузить в процесс модуль мониторинга, можно отключить некоторые ветки алгоритма или исказить выдаваемые данные, а можно просто завершить работу приложения. Если пойти дальше, то теоретически можно даже модифицировать в памяти загруженную библиотеку, нейтрализовав в ней то, чего она не должна делать с вашим процессом. Просторы для фантазии безграничны.

Читать статью целиком »

Перезапуск приложения в случае его аварийного завершения

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

Читать статью целиком »