как узнать какие dll использует программа
Как узнать какие dll использует программа
Одним и тем же файлом DLL может одновременно пользоваться несколько программ. Это вызывает проблемы, например, в случае необходимости удалить файл из системы. Чтобы снять занятость файла, нужно закрыть все программы, которые его блокируют в настоящий момент.
Внимание! Все примеры будут приведены на системном файле только для демонстрации. Системные файлы удалять крайне не рекомендуется!
Для начала нам необходимо открыть командную строку Windows.делается это путем ввода cmd в строку “Выполнить…” или “Найти программы и файлы” в меню Пуск.
После открытия командной строки необходимо ввести команду tasklist /m FILENAME.dll, где FILENAME — название нужной вам библиотеки.
В качестве результата система покажет весь список процессов, которые занимают файл библиотеки в настоящий момент. В нашем примере их оказалось два, но может быть один или любое другое число
После освобождения файла от активных процессов над ним можно будет совершать различные операции, такие как отмена регистрации и удаление. Если вы хотите облегчить процесс работы с DLL-файлами, используйте DLLSearch Client. Он поможет упростить действия по поиску, установке и другим процессам, связанным с DLL.
DLLSearch Client — бесплатная программа
для исправления ошибок DLL.
© 2020 Запрещено копирование любых материалов.
Как узнать какие dll использует программа
Написал прогу, на моем компе нормально работает, принес на комп, где дельфи нет и никогда не стояло, пробую запустить, выдает сообщение, что требуется такая-то библиотека. В связи с чем вопрос, а точнее целых два:
1) Можно ли сделать так, чтобы при компиляции весь код из таких библиотек компилировался в основную прогу, т.е. чтобы эти длл-ки не требовались
2) Если нет, то как узнать, какие библиотеки может потребовать прога, чтобы распространять их вместе с прогой?
← →
Игорь Шевченко © ( 2009-04-21 18:14 ) [1]
> Если нет, то как узнать, какие библиотеки может потребовать
> прога, чтобы распространять их вместе с прогой?
← →
12 © ( 2009-04-22 10:33 ) [2]
Function GetAllProcesses2: Boolean;
Type
TEnumProcessModules = Function (hProcess: THandle; lphModule: LPDWORD; cb: DWORD; Var lpcbNeeded: DWORD): BOOL Stdcall;
TGetModuleFileNameExA = Function (hProcess: THandle; HMODULE: HMODULE; lpFileName: PAnsiChar; nSize: DWORD): DWORD Stdcall;
Var
EnumProcessModules : TEnumProcessModules;
GetModuleFileNameExA: TGetModuleFileNameExA;
hPSAPI : THandle;
Counter1 : LongWord;
pbNeeded : DWORD;
ModHndls : Array[0..1023] Of DWORD;
mbNeeded : DWORD;
ModulePath : String;
Begin
Result := False;
hPSAPI := LoadLibrary(«PSAPI.dll»);
If hPSAPI
← →
Rouse_ © ( 2009-04-22 11:53 ) [3]
← →
Franzy ( 2009-04-22 13:51 ) [4]
Попробую прогу от Rouse.
← →
Anatoly Podgoretsky © ( 2009-04-22 14:13 ) [6]
> Franzy (22.04.2009 13:51:04) [4]
Данная задача решения не имеет.
← →
Игорь Шевченко © ( 2009-04-22 21:48 ) [7]
> Написал прогу, на моем компе нормально работает, принес
> на комп, где дельфи нет и никогда не стояло
> НЕТ той длл, на отсутствие которой ругалась ось (dforrt.
> dll).
эта DLL к Delphi не относится
Есть подозрение, что используемая длл тоже какие-то свои длл использует.
Да, так и есть. tdump длл-ки показал, что она обращается к этой самой dforrt.dll. А еще к какой-то MSVCRT.dll:
IMPORT: MSVCRT.dll=
IMPORT: MSVCRT.dll=
IMPORT: MSVCRT.dll=
IMPORT: MSVCRT.dll=
Это родная виндовская или тоже какая-то левая?
> Это родная виндовская или тоже какая-то левая?
← →
Сергей М. © ( 2009-04-23 13:45 ) [11]
Родство с этим модулем у «винды» того же колена, что и родство Делфи-приложений с можулем rtlXX.bpl
Так она родная для винды или нет? Или тоже из вижл студио?
← →
Сергей М. © ( 2009-04-23 14:46 ) [13]
← →
Anatoly Podgoretsky © ( 2009-04-23 15:05 ) [14]
> Franzy (23.04.2009 13:38:09) [9]
Т.е. она есть не везде и ее тоже надо включать вместе с dforrt.dll в комплект с экзишником?
← →
Сергей М. © ( 2009-04-23 15:22 ) [17]
Не надо.
Модуль поставляется штатно в составе дистрибутива, без него невозможна работа огромной кучи штатно поставляемого в составе ОС прикладного софта.
> Сергей М. © (23.04.09 15:22) [17]
>
> Не надо.
Не факт кстати. Плюс у нее версии разные еще есть.
> Franzy (23.04.09 15:17) [16]
>
> Т.е. она есть не везде и ее тоже надо включать вместе с
> dforrt.dll в комплект с экзишником?
Если нужна MSVCRT.dll, то разумнее в процессе установки программы поставить еще м Microsoft Visual C++ 2008 Redistributable, ну или другой версии.
← →
Игорь Шевченко © ( 2009-04-23 18:46 ) [19]
> Это родная виндовская или тоже какая-то левая?
Как определить какие DLL-файлы используются в Windows
Приложения и процессы Windows получают доступ к файлу типа DLL. DLL-файл, если он поврежден или отсутствует, часто препятствует правильному запуску приложения или процесса. Время от времени приложение или процесс могут завершиться неудачно, если нужный DLL-файл отсутствует. Дело в том, что эти файлы важны, даже если вы никогда не запускаете и не загружаете их. LoadedDllsView — бесплатное приложение для Windows, которое показывает, какие DLL-файлы используются в любой заданной точке. Вы можете выбрать DLL-файл и посмотреть, какое приложение или процесс обращаются к нему. Вот как это работает.
Загрузите и запустите LoadedDllsView. Дайте ему несколько секунд, чтобы загрузить список используемых DLL-файлов. Приложение может перестать отвечать на запросы в течение нескольких секунд, но разрешить запуск и не закрывать приложение.
LoadedDllsView покажет вам, какие DLL-файлы используются в списках. Выберите его и в панели под списком DLL-файлов вы увидите, какие приложения или процессы используют его.
Для каждого файла вы можете увидеть, сколько процессов обращается к нему, будь то файл 32 или 64 бит, разработчик, который создал файл, имя версии продукта, путь и т. Д. LoadedDllsView предоставляет вам всю информацию о каждом файле DLL, который используется.
LoadedDllsView позволяет фильтровать файлы DLL. Если есть определенный файл, на который вы хотите посмотреть, вы можете использовать фильтры для сужения поиска. Вы можете фильтровать файлы на 32 и 64-разрядные версии, файлы DLL от Microsoft или нажать Ctrl + Q, чтобы вызвать поиск строк.
Строковый поиск может включать одну или несколько строк, разделенных запятыми, и вы можете ограничить поиск всеми или только видимыми столбцами. Чтобы настроить видимые столбцы, перетащите их и перетащите их.
Автоматизация обнаружения возможных путей перехвата DLL (DLL Hijacks)
Привет, хабровчане. Прямо сейчас открыт набор на новый поток курса «Пентест. Практика тестирования на проникновение». В преддверии старта курса делимся с вами переводом интересного материала.
Введение
В этой статье мы рассмотрим концепцию перехвата порядка поиска динамически подключаемых библиотек (DLL hijacking) и то, как она может быть использована для достижения устойчивости (persistence) в юзерленде в системах Windows. Этот метод описан в MITER ATT&CK в разделе: «Перехват порядка поиска DLL (T1038)».
Подмена DLL может быть использована злоумышленниками для множества разных целей, но в этой статье основное внимание будет уделено достижению устойчивости с помощью приложений с автозапуском. Например, поскольку Slack и Microsoft Teams запускаются при загрузке (по умолчанию), подмена DLL в одном из этих приложений позволит злоумышленнику получить устойчивый доступ к своей цели — всякий раз, когда пользователь входит в систему.
После представления концепции DLL, порядка поиска DLL, и подмены DLL, я раскрою процесс автоматизации обнаружения возможности перехвата DLL. В этой статье будет рассказано об обнаружении путей перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Я хочу поблагодарить своего коллегу Джозайю Массари ( @Airzero24 ) за то, что он первым обнаружил некоторые из этих перехватов DLL, объяснил их методологию и вдохновил меня автоматизировать обнаружение.
Что такое DLL?
DLL — это библиотека, содержащая код и данные, которые могут использоваться одновременно более чем одной программой. (Сурс)
Например, разработчик, которому необходимо выполнять HTTP-запросы, может использовать библиотеку WinHTTP ( winhttp.dll ) вместо реализации HTTP-запросов с использованием сырых сокетов.
Порядок поиска DLL и перехват
Поскольку DLL существуют в виде файлов на диске, вы можете задаться вопросом, как приложение узнает, откуда загружать DLL? Microsoft подробно задокументировала порядок поиска DLL здесь.
Начиная с Windows XP SP2, безопасный режим поиска DLL включен по умолчанию ( HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode ). При включенном безопасном режиме порядок поиска DLL следующий:
Если приложение не указывает, откуда загружать DLL, Windows использует порядок поиска DLL по умолчанию, приведенный выше. Первая позиция в порядке поиска DLL (каталог, из которого загружается приложение) представляет интерес для злоумышленников.
Использование подмены DLL для достижения устойчивости
Именно эти программы стали целью перехвата, потому что по умолчанию они настроены на запуск при загрузке Windows. Это можно увидеть ниже в диспетчере задач:
Приложения Windows, настроенные на автозапуск
Чтобы проверить подмену DLL, я создал загрузчик шеллкода DLL, который запускал Cobalt Strike Beacon. Я переименовал вредоносную DLL в userenv.dll и скопировал ее в каталог уязвимого приложения. Я запустил приложение и увидел свой новый Beacon коллбек.
Cobalt Strike Beacon через перехват DLL
Используя Process Explorer, я могу проверить, действительно ли моя вредоносная DLL была загружена уязвимым приложением.
Обозреватель процессов, показывающий загруженную вредоносную DLL
Автоматическое обнаружение возможности перехвата DLL
После подтверждения ранее известного перехвата DLL, я хотел проверить, смогу ли я найти другие возможности для подмены DLL, которые можно было бы эксплуатировать.
Код, использованный в моих проверка, можно найти здесь.
На примере Slack
Чтобы начать этот процесс, я запустил Process Monitor (ProcMon) со следующими фильтрами:
Затем я запустил Slack и изучил ProcMon на предмет любых DLL, которые Slack искал, но не смог найти.
Возможные пути перехвата DLL, обнаруженные с помощью ProcMon
Я экспортировал эти данные из ProcMon в виде CSV файла для облегчения парсинга в PowerShell.
С моей текущей DLL загрузчика шелл-кода я не смог бы легко определить имена DLL, которые были успешно загружены Slack. Я создал новую DLL, которая использовала GetModuleHandleEx и GetModuleFileName для определения имени загруженной DLL и записи его в текстовый файл.
Моя следующая цель состояла в том, чтобы проанализировать CSV-файл на наличие в списке путей к DLL, просмотреть этот список, скопировать мою тестовую DLL по указанному пути, запустить целевой процесс, остановить целевой процесс и удалить тестовую DLL. Если тестовая DLL была успешно загружена, она запишет свое имя в результирующий файл.
Когда этот процесс завершится, у меня будет список возможных перехватов DLL (я надеюсь), записанных в текстовый файл.
Всю магию в моем проекте DLLHijackTest творит скрипт PowerShell. Он принимает путь к CSV-файлу, сгенерированному ProcMon, путь к вашей вредоносной DLL, путь к процессу, который вы хотите запустить, и любые аргументы, которые вы хотите передать процессу.
Параметры Get-PotentialDLLHijack
Get-PotentialDLLHijack.ps1
Через несколько минут я проверяю текстовый файл, указанный в моей «вредоносной» DLL, на предмет возможных перехватов DLL. Я обнаружил следующие возможные пути перехвата для Slack:
На примере Microsoft Teams
Выполняем описанный выше процесс еще раз:
На примере Visual Studio Code
Повторяя описанный выше процесс, я обнаружил следующие потенциальные пути перехвата для Visual Studio Code:
Подмена общих (shared) DLL
Я заметил, что Slack, Microsoft Teams и Visual Studio Code совместно используют следующие DLL:
Методология: понимание путей перехвата общих DLL
DLL с отложенной загрузкой
Стек трейс, когда Code.exe пытается загрузить WINSTA.dll
Стек трейс, когда Slack пытается загрузить ntshrui.dll
Строка « WINSTA.dll » в wtsapi32.dll
Кликнув правой кнопкой мыши по локации в памяти, мы сможем найти любые ссылки на этот адрес.
Ссылки на WINSTA.dll
__delayLoadHelper2 и ResolveDelayLoadedAPI в Ghidra
__delayLoadHelper2 и ResolveDelayLoadedAPI в ProcMon.
Подмена DLL в NetShareGetInfo и NetShareEnum
Стек трейс при загрузке cscapi.dll
srvcli.dll вызывает LoadLibrary для cscapi.dll
NetShareGetInfo загружает cscapi.dll
Я проверил это с помощью РоС программ, которые вызывали NetShareEnum и NetShareGetInfo :
NetShareEnum.exe загружает cscapi.dll
NetShareGetInfo.exe загружает cscapi.dll
Результаты
В Slack доступны следующие пути подмены DLL:
В Microsoft Teams доступны следующие пути подмены DLL:
В Visual Studio Code доступны следующие пути подмены DLL:
Заключение
Напомним, что перехват DLL — это метод, с помощью которого злоумышленники могут повлиять на выполнение кода в подписанных/доверенных приложениях. Я создал инструменты, помогающие автоматизировать обнаружение путей перехвата DLL. Используя этот инструмент, я обнаружил пути перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Я заметил, что пути перехвата DLL этих трех приложений частично совпадают, и исследовал причину. Я осветил свою методику понимания данного совпадения. Я узнал о DLL с отложенной загрузкой и обнаружил два вызова API, которые делают возможным перехват DLL в любой программе, которая их вызывает:
Ссылки
Большой привет моим коллегам Дэниелу Хейнсену ( @hotnops ), Ли Кристенсену ( @tifkin_ ) и Мэтту Хэнду( @matterpreter ) за то, что они помогли справиться с Ghidra/ProcMon!
20 ответов
Ну, этот вопрос простителен для новичка. В DLL копаться не нужно, тем более в системных. MSDN вам в руки.
А если просто просмотреть список ф-ций в DLL (да и для много другого) можно заюзать HIEW.
Evg64, а какая у Вас вообще цель? Создать свою DLL, просто спортивный интерес или что-то иное? Если Вы хотите использовать функции Win API, то Вам не нужно вообще заботиться о загрузке функции из DLL: за Вас всё уже сделано в виде библиотек. В этом случае, как сказал Lerkin, смотрите MSDN относительно Вашей задачи.
Если же всё-таки нужен список, есть утилита, правда шараварная: PE Explorer. Можно слить триалку на 30 дней, но, думаю, этого хватит, чтобы удовлетворить любопытство 🙂
А вообще узнать больше о длл меня сподвигла банальная мысль о том, что знание возможностей длл файлов расширит возможности программирования)
Насчет MSDN я не совсем понял: ведь не может же там содержаться информации по всему многообразию функций из всего многообразия длл файлов? Я там смотрел, да можно было и не смотреть) Может я что-то понял не так?
Прикинь, может, особенно если учесть что объем МСДН 1.5 гига, и все ф-ции, содержащиеся в длл-ках виндов там описаны.
А вообще работают от обратного: ищут функцию для решения определенных задач, а потом смотрят что надо подключить для вызова этой ф-ции.
И не смотри, не трать время. dll-ку в Блокноте открываешь, и читаешь. Нормальным, русским языком написано.
P.S. Есть начинающие, которым желательно тут же стать заканчивающими.
Попробую развернуто закрыть эту тему.
Как же избежать таких потерь? А достаточно изложить на хорошем форуме свой вариант постижения таинств программирования, и стоически выдержав первую волну сарказма со стороны участников, начать задавать наводящие вопросы, когда посоветуют, например, обратиться к MSDN. Попросить посоветовать доступную для понимания литературу по программированию в WinAPI, и много чего еще.
А самое главное, нужно четко понимать, ЧТО человек собрался программировать и ДЛЯ ЧЕГО.