как узнать какие dll использует программа
Как узнать какие dll использует программа
Одним и тем же файлом DLL может одновременно пользоваться несколько программ. Это вызывает проблемы, например, в случае необходимости удалить файл из системы. Чтобы снять занятость файла, нужно закрыть все программы, которые его блокируют в настоящий момент.
Внимание! Все примеры будут приведены на системном файле только для демонстрации. Системные файлы удалять крайне не рекомендуется!
Для начала нам необходимо открыть командную строку Windows.делается это путем ввода cmd в строку “Выполнить…” или “Найти программы и файлы” в меню Пуск.
После открытия командной строки необходимо ввести команду tasklist /m FILENAME.dll, где FILENAME — название нужной вам библиотеки.
В качестве результата система покажет весь список процессов, которые занимают файл библиотеки в настоящий момент. В нашем примере их оказалось два, но может быть один или любое другое число
После освобождения файла от активных процессов над ним можно будет совершать различные операции, такие как отмена регистрации и удаление. Если вы хотите облегчить процесс работы с DLL-файлами, используйте DLLSearch Client. Он поможет упростить действия по поиску, установке и другим процессам, связанным с DLL.
DLLSearch Client — бесплатная программа
для исправления ошибок DLL.
© 2020 Запрещено копирование любых материалов.
Просмотр библиотек DLL и исполняемых файлов в окне «Модули» (C#, C++, Visual Basic, F#)
В процессе отладки в Visual Studio окно Модули отображает список используемых приложением библиотек DLL и исполняемых файлов ( .exe), а также сведения о них.
Окно «Модули» недоступно при отладке SQL и скриптов.
Использование окна модулей
Чтобы открыть окно «Модули» во время отладки, выберите Отладка > Окна > Модули или нажмите клавиши CTRL+ALT+U.
По умолчанию модули в окне Модули упорядочены в порядке загрузки. Чтобы выполнить сортировку по любому столбцу окна, щелкните заголовок соответствующего столбца.
Загрузить символы
В столбце Состояние символов в окне Модули показано, для каких модулей загружены отладочные символы. Если здесь указано состояние Загрузка символов пропущена, Невозможно найти или открыть PDB-файл или Загрузка отключена параметром включения и исключения, вы можете загрузить символы вручную. Дополнительные сведения о загрузке и использовании символов см. в статье Указание файлов символов (.pdb) и исходных файлов.
Загрузка символов вручную
В окне Модули щелкните правой кнопкой модуль, для которого не загружены символы.
Выберите Сведения о загрузке символов, чтобы узнать, почему символы не были загружены.
Щелкните Загрузить символы, чтобы загрузить символы вручную.
Если символы не загружаются, выберите Параметры символов, чтобы открыть диалоговое окно Параметры и указать или изменить расположение для загрузки символов.
Вы можете скачать символы с общедоступных серверов символов Майкрософт или других аналогичных серверов, а также загрузить их из локальной папки на компьютере. Дополнительные сведения см. в разделе об указании расположения символов и поведения при загрузке.
Изменение параметров поведения при загрузке символов
В окне Модули щелкните правой кнопкой мыши любой модуль.
Выберите Параметры символов.
Выберите Загрузить все символы или выберите конкретные модули.
Нажмите кнопку ОК. Изменения вступят в силу при следующем сеансе отладки.
Изменение поведения загрузки символов для конкретного модуля
В окне Модули щелкните правой кнопкой мыши требуемый модуль.
В контекстном меню установите или снимите флажок Всегда загружать автоматически. Изменения вступят в силу при следующем сеансе отладки.
Порядок поиска библиотеки динамической компоновки (DLL)
Система может содержать несколько версий одной библиотеки динамической компоновки (DLL). Приложения могут управлять расположением, из которого загружается DLL, путем указания полного пути или использования другого механизма, например манифеста. Если эти методы не используются, система выполняет поиск библиотеки DLL во время загрузки, как описано в этом разделе.
Факторы, влияющие на поиск
На то, что система осуществляет поиск библиотеки DLL, влияют следующие факторы:
Порядок поиска для приложений UWP
Прежде чем система будет искать библиотеку DLL, она проверяет следующее:
Если система должна искать модуль или его зависимости, она всегда использует порядок поиска для приложений UWP, даже если зависимость не является кодом приложения UWP.
Стандартный порядок поиска для приложений UWP
Если модуль еще не загружен или в списке известных библиотек DLL, система выполняет поиск в следующих расположениях в следующем порядке:
Если библиотека DLL имеет зависимости, система выполняет поиск зависимых библиотек DLL, как если бы они загружались только с именами модулей. Это справедливо, даже если первая библиотека DLL была загружена путем указания полного пути.
Альтернативный порядок поиска для приложений UWP
Если модуль изменяет стандартный порядок поиска, вызывая функцию LoadLibraryEx с параметром Load _ с _ измененным _ _ путем поиска, система выполняет поиск в каталоге указанного модуля вместо каталога вызывающего процесса. Система выполняет поиск в следующих расположениях в следующем порядке:
Порядок поиска для настольных приложений
Настольные приложения могут управлять расположением, из которого загружается DLL, путем указания полного пути, использования перенаправления DLLили манифеста. Если ни один из этих методов не используется, система выполняет поиск библиотеки DLL во время загрузки, как описано в этом разделе.
Прежде чем система будет искать библиотеку DLL, она проверяет следующее:
Если библиотека DLL имеет зависимости, система выполняет поиск зависимых библиотек DLL, как если бы они загружались только с именами модулей. Это справедливо, даже если первая библиотека DLL была загружена путем указания полного пути.
Если злоумышленник получает контроль над одним из каталогов, в котором выполняется поиск, он может поместить в этот каталог вредоносную копию библиотеки DLL. Способы предотвращения таких атак см. в разделе безопасность библиотеки динамической компоновки.
Стандартный порядок поиска для настольных приложений
Стандартный порядок поиска библиотек DLL, используемый системой, зависит от того, включен или отключен режим поиска «Защищенная библиотека DLL». Сейф Режим поиска библиотек DLL помещает текущий каталог пользователя в последующий порядок поиска.
Если сафедллсеарчмоде включен, порядок поиска выглядит следующим образом:
Если сафедллсеарчмоде отключен, то порядок поиска выглядит следующим образом:
Альтернативный порядок поиска для настольных приложений
Стандартный порядок поиска процесса также будет зависеть от вызова функции сетдллдиректори в родительском процессе перед началом текущего процесса.
Если указать альтернативную стратегию поиска, ее поведение будет продолжаться до тех пор, пока не будут найдены все связанные исполняемые модули. После того как система начнет обработку подпрограмм инициализации DLL, система вернется к стандартной стратегии поиска.
Если сафедллсеарчмоде включен, альтернативный порядок поиска выглядит следующим образом:
Если сафедллсеарчмоде отключен, альтернативный порядок поиска выглядит следующим образом:
Функция сетдллдиректори поддерживает альтернативный порядок поиска, если параметр лппаснаме задает путь. Альтернативный порядок поиска выглядит следующим образом:
Если параметр лппаснаме является пустой строкой, вызов удаляет текущий каталог из порядка поиска.
Сетдллдиректори эффективно отключает режим поиска в защищенных библиотеках DLL, пока указанный каталог находится в пути поиска. Чтобы восстановить защищенный режим поиска DLL на основе значения реестра сафедллсеарчмоде и восстановить текущий каталог в порядке поиска, вызовите сетдллдиректори с лппаснаме как null.
Порядок поиска с помощью флагов _ _ поиска «загрузить библиотеку «
Искомые каталоги зависят от флагов, указанных в сетдефаултдллдиректориес или LoadLibraryEx. Если используется более одного флага, поиск соответствующих каталогов выполняется в следующем порядке:
Если приложение не вызывает LoadLibraryEx с любыми флагами _ _ поиска в библиотеке нагрузки или не устанавливает порядок поиска DLL для процесса, система выполняет поиск библиотек DLL, используя стандартный или альтернативный порядок поиска.
Как узнать какие 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 (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!