9

У меня есть файл DLL в каталоге SYSTEM32 одного сервера, который я не уверен, что мне действительно нужно.

Google сказал мне, для чего он обычно используется, но программное обеспечение никогда не устанавливалось в этой системе. Тем не менее, я считаю возможным, что один из других установленных продуктов на сервере мог включать (и, следовательно, предположительно, потребуется) файл.

Я выполнил поиск в реестре по имени файла, а также по ряду строк, найденных в метаданных файла, и не смог найти ничего информативного. (Хотя ключ ACMru действительно попался на глаза, пока я не выяснил, для чего он.)

Могу ли я что-нибудь сделать, чтобы сама система сообщала мне, какая программа установила DLL, и / или какая установленная программа (ы) (если таковая имеется) будет использовать ее?

ПРИМЕЧАНИЕ. Рекомендации по использованию инструментов хороши, но я не буду устанавливать или запускать дополнительное программное обеспечение в этой системе. Мне нужно работать с тем, что доступно при установке по умолчанию Server 2003.

3 ответа3

5

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

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

4

Вы могли бы потенциально изучить каждый.Файл MSI в папке% SystemRoot%\Installer. Все (?) программы, установленные с помощью установщика Windows, добавят сюда свой MSI, чтобы их можно было удалить позднее. Папка, как правило, содержит массу вещей. Если / как только вы найдете dll среди множества пакетов MSI, вам придется сопоставить пакет с четко определенным именем.

Чтобы декомпилировать MSI-файлы с помощью сценария, вы можете попробовать использовать этот инструмент VBS http://www.hanselman.com/blog/HowToListAllTheFilesInAnMSIInstallerUsingVBSciript.aspx или вы можете попробовать программу под названием MSIDiff (которую я никогда не использовал) http://dennisbareis.com/msidiff.htm. Конечно, учитывая ограничения, связанные с отсутствием необходимости установки инструментов, последним не нужно будет работать в этом отношении. Первый будет, если cscript установлен.

Последний инструмент может выполнить сопоставление имени пакета для вас, не прибегая к ручному поиску в реестре соответствующего GUID или имени файла MSI. Первый инструмент может быть изменен, чтобы вывести имя пакета, если вы знали, на какую таблицу / столбец ссылаться (я не знаю).

Скрипт VBS просто исследует файл MSI с точки зрения базы данных. Ключевая работа сделана с: базой данных.OpenView("Выбрать имя файла из файла").

1

Process Monitor может сделать это за вас. Просто отфильтруйте по имени DLL, и когда программа попытается загрузить ее, появится запись, в которой будет указано, какой процесс ищет и / или обращается к упомянутой вами DLL.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .