Дело о загадочном драйвере

На днях я при помощи программы Process Explorer исследовал набор драйверов, установленных на своем домашнем компьютере. Было любопытно, не подхватил ли я драйверы устройств для управления цифровыми правами (DRM) наподобие тех, что были выпущены компаниями Sony и Starforce. В представлении библиотек DLL процесса System, в котором фигурируют загруженные в данный момент драйверы и модули режима ядра (например, слой абстрагирования оборудования (Hardware Abstraction Layer, HAL)), были перечислены в основном драйверы, связанные с ОС и ПО для записи DVD-дисков. В таком окружении одна из записей, Asctrm.sys, привлекла мое внимание. В поле сведений о производителе было написано “Windows (R) 2000 DDK provider”.

Эта строка характерна для драйверов, основанных на образцах кода из пакета для разработчиков драйверов устройств для Windows 2000, и видеть ее в рабочих версиях довольно непривычно. Описание драйвера ничуть не более информативно - “TR Manager”. Весь в подозрениях, я начал расследование.

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

Далее я принялся обследовать образ. Дважды щелкнув на записи драйвера в представлении DLL программы Process Explorer, я открыл диалоговое окно свойств библиотеки. На странице образа не удалось найти ничего полезного, кроме даты компоновки драйвера (декабрь 2004 г.). В попытках узнать, зачем же нужен этот драйвер, я переместился во вкладку Strings (Строки). Все обнаруженные программой Process Explorer строки не были уникальными - все, кроме последней:

При компиляции драйвера компоновщик сохраняет в образе путь к файлу отладочной информации, который имеет расширение PDB. В составе пути оказалось нечто похожее на наименование компании - AegiSoft. Впрочем, как следует из материалов на веб-узле https://www.aegisoft.com/, компания Aegis Software, Inc. разрабатывает «эффективные, полнофункциональные и удобные приложения и службы биржевой торговли для финансовых организаций, которым требуется высокая производительность, надежность, доступность и гибкость». Не слишком похоже на компанию, производящую драйверы устройств.

На удачу я ввел в поле поиска Google строку “aegis” и наткнулся на новостную заметку, датированную январем 2001 года, где сообщается о приобретении RealNetworks компании Aegisoft Corp. (обратите внимание на различия в написании Aegisoft и Aegis Software, Inc.). Я запустил проигрыватель RealPlayer, который был установлен в моей системе, и действительно, драйвер оказался связан именно с ним. Это подтвердилось поиском по дескриптору “asctrm” - имени объекта устройства, замеченного мною в одной из строк драйвера.

Похоже, более современные версии проигрывателя RealPlayer не задействуют драйверы устройств, но в моей системе стоит старая версия. Оповещений о новых выпусках я не получаю, поскольку сразу после установки RealPlayer всегда запускаю программу Autoruns и удаляю запись проигрывателя в разделе HKLM\Software\Microsoft\Windows\CurrentVersion\Run, которая при установке RealPlayer создается для запуска планировщика Real Networks в ходе загрузки системы. Кстати говоря, эта запись называется TkBellExe - еще одно неинформативное наименование.

Итак, как выяснилось, драйвер не относится к числу вредоносных (правда, справедливость такой оценки зависит от индивидуальной позиции относительно управления цифровыми правами). На этом примере становится ясно, как важно для всех производителей ПО (и в том числе для корпорации Майкрософт!) четко обозначать свои приложения и драйверы в ресурсах версий, в разделах и значениях реестра.

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

Исходная запись создана пользователем Mark Russinovich 27.03.06 в 03:52:00
Запись перенесена из блога Sysinternals.com/Blog