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

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

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

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

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

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

Как узнать, что приложение запущено через ярлык

Очередная развлекушка на Ассемблере. Давайте узнаем, была ли наша программа запущена через .lnk-файл, то есть через ярлык, или же напрямую через Проводник, файловый менеджер или другой процесс. Для этого надо получить структуру STARTUPINFO, а затем проверить, установлен ли флаг STARTF_TITLEISLINKNAME в поле dwFlags.Ранее этот флаг относился к недокументированным, сейчас в MSDN появилось его нормальное описание. Итак, если флаг STARTF_TITLEISLINKNAME установлен, то программа была запущена через ярлык, а в параметре lpTitle структуры STARTUPINFO содержится указатель на строку с полным путем к .lnk-файлу, через который был произведен запуск.

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

Управление редактором реестра из своего приложения

Наверняка вы слышали о программе RegJump от SysInternals, ныне принадлежащая Microsoft. При помощи этой программы вы можете открыть regedit сразу же на нужной ветке реестра. Мне стало очень интересно, как она это делает. Дизассемблер в руки, отладчик в боевую готовность и вперед!

Вот что мне удалось накопать. Я оставил только самый важный код, попутно упростив и оптимизировав его. Оригинальный RegJump сперва пытается найти запущенный regedit по наименованию класса окна, если такого нет, то пытается запустить regedit из системной папки. Так или иначе, вся работа выполняется с найденным окном. У меня подразумевается, что редактор реестра уже запущен.Наименование ветки реестра, куда надо перейти, переводится в верхний регистр, а в начало и конец строки прицепляется символ "\". Традиционные сокращения типа "HKLM" разворачиваются в полноценные наименования веток реестра "HKEY_LOCAL_MACHINE" и т.п. Я надеюсь, с подобным преобразованием строки у вас проблем возникнуть не должно. У меня строка сразу приведена в должный вид.

Хэндл процесса необходим для синхронизации пользовательского ввода с окном приложения, поскольку все управление regedit выполняется через эмуляцию нажатий клавиш в списке. Для "своей" копии regedit, которая запущена RegJump, используется результат выполнения функции CreateProcess, для запущенного ранее экземпляра хэндл получается через пару функций GetWindowThreadProcessId и OpenProcess. Особых привилегий для этого не надо.Когда все нужные окна найдены и хэндл процесса получен, начинается эмуляция нажатий клавиш. Сперва выполняется переход на самый верхний уровень списка. Судя по коду, Марк Руссинович предположил, что глубже 30-го уровня списка зайти невозможно, что ж, ему виднее. Затем начинается обработка строки с нужным названием ветки реестра. Строка обрабатывается посимвольно, когда встретится символ "\", то эмулируется нажатие стрелки вправо для открытия нужного уровня списка и перехода на него. Именно для этого исходная строка дополняется в начале и в конце этим символом. Строковые символы из строки передаются в поиск, тем самым определяя следующий уровень списка. Как видите, никаких ракетных технологий, но лично мне было очень интересно посмотреть на решение этой задачи от одного из признанных знатоков внутренностей Windows.

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

Запуск ограниченного количества копий программы

В комментариях к статье о запрете запуска нескольких копий программы пару лет назад был задан очень правильный вопрос: как реализовать запуск ограниченного числа копий программы больше одного? Сейчас я могу ответить на этот вопрос полноценной статьей. Настоятельно рекомендую сперва прочитать изначальную статью, чтобы не дублировать здесь теоретические выкладки. Для наглядности почти все методы остаются прежними, меняться будут только условия их использования.

Первый способ использует shared-память, общую для всех копий данного приложения. В ней находится счетчик, который каждая копия увеличивает на 1 при запуске и уменьшает на 1 при завершении своей работы. При старте выполняется проверка на количество ранее запущенных копий. Счетчик достиг максимального значения - пожалуйте на выход.Обратите внимание на использование префикса LOCK перед командами изменения счетчика копий. Этот префикс предназначен для обеспечения исключительного доступа к ячейке памяти на время выполнения команды при работе на многопроцессорных многозадачных системах. В отличие от проверки единственной копии, у такого варианта решения есть большой недостаток. Если приложение завершится аварийно или будет принудительно завершено системой, то счетчик работающих копий не уменьшится. Обойти это можно, если, например, в общей памяти хранить не просто счетчик, а массив идентификаторов процессов, при каждом запуске проверяя их наличие и актуальность.

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