Как загрузить dll из ресурсов
Обновлено: 03.07.2024
Файл DLL – компонент динамически подключаемой библиотеки, чьи элементы используют практически все программы. Библиотека DLL файлов расположена в корневой папке системы. Компоненты должны быть все в наличии, иметь цифровую подпись, правильно работать и быть актуальными по версии. Если одно из требований не соблюдено, при запуске программы пользователь получит информационное уведомление: ошибка DLL. Неисправность свидетельствует о том, что отсутствует DLL файл, поврежден или устарел.
Как установить DLL файл
Чтобы программы, приложения и игры снова начали работать, необходимо установить вручную недостающие компоненты библиотеки. Просто поместить файл в папку недостаточно ─ нужно знать как их зарегистрировать.
Помещение и регистрация файлов библиотеки
Перед тем как установить DLL файл на Windows 7,8,10, их нужно скачать, причем точно под разрядность системы.
Давайте определим, какая разрядность у Вашей системы (если вы точно знаете, может пропустить этот шаг)
Шаг 1. Кликаем правой кнопкой мыши по "Мой компьютер" и выбираем "Свойства"
Шаг 2. В открывшемся окне, мы может прочитать свойства компьютера, версию операционной системы и её разрядность 32 (х86) или 64 бит. В нашем случаи стоит 64-разрядная операционная система Windows 10.
·
Шаг 3. После скачивания файлов их нужно поместить в корневую папку, зарегистрировать
для х32 (х86) систем компонент необходимо заменить или поместить в папку C:\Windows\System32;
для х64 необходимо выполнить замену или переместить в папку C:\Windows\ SysWOW64;
Шаг 4. Файл нужно зарегистрировать в системе.
Сделать это можно, открыв командную строку комбинацией «Win» + «R», или нажать «Пуск» и «Выполнить»;
в открывшемся окне ввести через пробел следующее: regsvr32 имя файла.dll – где, «regsvr32» ─ команда для регистрации, а «имя файла.dll» – полное имя вставленного компонента;
или же можно прописать расположение файла вручную - regsvr32.exe + путь к файлу
Шаг 5. Нажмите "ОК", и перезагрузите компьютер, и новые параметры вступят в силу.
Сразу хочется отметить, что при регистрации возможны появления ошибок. Например: "Не удалось загрузить модуль". Обычно они возникают по 3 причинам
Второй способ регистрации
Шаг 1. Зарегистрировать файл можно с помощью командой строки, которую нужно запустить от имени администратора.
Шаг 2. Пишем команду regsvr32.exe + путь к файлу и жмём "Enter"
Имею библиотеку на шарпе, но сорцов ее не имею.
И получать на выходе больше одного файла тоже не хочу.
Можно ли каким либо способом добавить в ресурсы дллку эту и использовать ее оттуда?
Помощь в написании контрольных, курсовых и дипломных работ здесь
Загрузка ресурсов из dll
Создал библиотеку в библиотеке три папки с изображениями, библиотека подключена к другому проекту.
нет, вы где то ошиблись, ILMerge позволяет сделать из длл и exe один ехе
Во вторых, согласно поставленной задаче мне нужно получить один файл уже при компиляции в вижуал студио. нет, вы где то ошиблись, ILMerge позволяет сделать из длл и exe один ехеЯ про это и говорил. Мне она не позволила по непонятной причине, да и ладно.
У меня уже просто есть одна длл, сделанная мною, и я хочу к ней прилепить еще одну, сорцов которой у меня нету. И на выходе хочу иметь одну длл. Если бы сорцы были, я бы просто скопировал их в свою длл и все.
так она обфусциована или нет? Можно просто воспользоваться любым декомпилятором и получить исходный код. надоже как интересно, неподумал чет, что класс асембли такое умеет , спасибо попробуюя прочитал тут по ссылкам статьи и в итоге получил такое
проверил - все работает
можно и так, я просто выдрал кусочек из своей проги и не все затер. у меня там код еще другой есть и возможность упаковки/распаковки библиотеки из ресурсовДобавлено через 11 минут
Нашёл решение на хабре=)
Инжектирование dll в сторонний процесс напрямую из ресурсов
Извините за подобное название темы, не знал как назвать более понятно. В общем, что мы имеем: 1.
Активирование функция Init при внедрении dll файла из ресурсов в игру
У меня есть проект, хочу что бы при внедрении dll файла в игру, активировалась функция Init в.
Подключение dll из ресурсов внутри другой dll
Здравствуйте! Есть сторонняя dll и собственная dll. Собственная dll написана для удобной работы со.
Подключение DLL из ресурсов
Всем привет . Как засунуть длл в ресурсы и её использовать ?
Подключение dll из ресурсов
Не бросайтесь камнями сразу. Было уже много раз эта тема тут, но у меня так и не получилось.
Библиотеки DLL расширения MFC — это библиотеки DLL, которые обычно реализуют классы многократного использования в существующих библиотеках классов Microsoft Foundation Class.
Библиотека DLL расширения MFC обладает следующими функциями и требованиями.
Клиентский исполняемый файл должен быть приложением MFC, скомпилированным с определенным _AFXDLL .
Библиотека DLL расширения MFC может также использоваться в обычной библиотеке DLL MFC, которая динамически связана с MFC.
Библиотеки DLL расширения MFC должны быть скомпилированы с определенным _AFXEXT . Это приводит также к определению _AFXDLL и гарантирует, что в файлах заголовков MFC будут извлечены соответствующие объявления. Это также гарантирует, что AFX_EXT_CLASS определяется как __declspec(dllexport) при сборке библиотеки DLL, что необходимо, если вы используете этот макрос для объявления классов в библиотеке DLL расширения MFC.
Библиотеки DLL расширения MFC не должны создавать экземпляры класса, производного от CWinApp , но для предоставления этого объекта следует полагаться на клиентское приложение (или библиотеку DLL).
Однако библиотеки DLL расширения MFC должны предоставлять функцию DllMain и выполнять необходимую инициализацию.
Библиотеки DLL расширения создаются с помощью библиотеки динамической компоновки MFC (также известной как общая версия MFC). Только исполняемые файлы MFC (приложения или обычные библиотеки DLL MFC), созданные с помощью общей версии MFC, могут использовать библиотеку DLL расширения MFC. Как клиентское приложение, так и библиотека DLL расширения MFC должны использовать одну и ту же версию MFCx0.dll. С помощью библиотеки DLL расширения MFC можно создавать новые пользовательские классы из MFC, а затем предоставлять эту расширенную версию MFC приложениям, которые вызывают библиотеку DLL.
Библиотеки DLL расширения также можно использовать для передачи объектов, производных от MFC, между приложением и библиотекой DLL. Функции элементов, связанные с переданным объектом, существуют в модуле, в котором был создан объект. Поскольку эти функции должны быть правильно экспортированы при использовании общей версии библиотеки MFC, можно свободно передавать указатели на объекты, производные от MFC или MFC, между приложением и загружаемыми библиотеками DLL расширения MFC.
Библиотека DLL расширения MFC использует общую версию MFC так же, как приложение использует общую версию библиотеки DLL MFC с несколькими дополнительными моментами, которые следует учитывать.
Она вызывает AfxInitExtensionModule в своей функции DllMain . Необходимо проверить возвращаемое значение этой функции. Если из AfxInitExtensionModule возвращается нулевое значение, из функции DllMain возвращается 0.
Она создает объект CDynLinkLibrary во время инициализации, если библиотека DLL расширения MFC экспортирует объекты CRuntimeClass или ресурсы в приложение.
В версиях MFC, предшествующих версии 4.0, этот тип библиотеки DLL назывался AFXDLL. AFXDLL относится к символу препроцессора _AFXDLL , который определяется при построении библиотеки DLL.
Библиотеки импорта для общей версии MFC именуются в соответствии с соглашением, описанным в статье Соглашения об именовании библиотек DLL MFC. Visual Studio предоставляет предварительно созданные версии библиотек DLL MFC, а также ряд библиотек DLL, не относящихся к MFC, которые можно использовать и распространять вместе с приложениями. Они описаны в файле Redist.txt, который устанавливается в папку Program Files\Microsoft Visual Studio.
Если вы выполняете экспорт с применением DEF-файла, поместите следующий код в начало и в конец файла заголовка:
Эти четыре строки гарантируют правильную компиляцию кода для библиотеки DLL расширения MFC. Если не указать эти четыре строки, компиляция или компоновка библиотеки DLL может быть выполнена неправильно.
Если необходимо передать указатель на объект MFC или объект MFC, производный от библиотеки DLL MFC, библиотека DLL должна быть библиотекой DLL расширения MFC. Функции элементов, связанные с переданным объектом, существуют в модуле, в котором был создан объект. Поскольку эти функции должны быть правильно экспортированы при использовании общей версии библиотеки MFC, можно свободно передавать указатели на объекты, производные от MFC или MFC, между приложением и загружаемыми библиотеками DLL расширения MFC.
Ввиду искажения имен C++ и проблем с экспортом список экспорта из библиотеки DLL расширения MFC может отличаться в отладочной и розничной версиях одной и той же библиотеки DLL и библиотеках DLL для разных платформ. В розничной версии MFCx0.dll содержится около 2000 экспортированных точек входа; в отладочной версии MFCx0D.dll содержится порядка 3000 экспортированных точек входа.
Управление памятью
MFCx0.dll и все библиотеки DLL расширения MFC, загруженные в адресное пространство клиентского приложения, используют одни и те же распределитель памяти, загрузку ресурсов и другие глобальные состояния MFC, как если бы они находились в одном приложении. Это важно, так как библиотеки DLL, не относящиеся к MFC, и обычные библиотеки DLL MFC выполняют в точности противоположные задачи и каждая библиотека DLL выделяется из собственного пула памяти.
Если библиотека DLL расширения MFC выделяет память, эта память может свободно смешиваться с любым другим объектом, выделенным приложением. Кроме того, если в работе приложения, которое динамически связывается с MFC, возникает сбой, защита операционной системы обеспечивает целостность любого другого приложения MFC, которое совместно использует библиотеку DLL.
Аналогично, другие глобальные состояния MFC, такие как текущий исполняемый файл для загрузки ресурсов, также совместно используются клиентским приложением и всеми библиотеками DLL расширения MFC, а также самой MFCx0.dll.
Совместное использование ресурсов и классов
Экспорт ресурсов осуществляется посредством списка ресурсов. Каждое приложение содержит отдельно связанный список объектов CDynLinkLibrary. При поиске ресурса большинство стандартных реализаций MFC, которые загружают ресурсы, сначала выполняют поиск в текущем модуле ресурсов ( AfxGetResourceHandle ). Если ресурс не найден, выполните анализ списка объектов CDynLinkLibrary, пытающихся загрузить запрошенный ресурс.
Анализ списка имеет недостатки, которые немного замедляют работу и требуют управления диапазонами идентификаторов ресурсов. Преимущество заключается в том, что клиентское приложение, которое ссылается на несколько библиотек DLL расширения MFC, может использовать любой ресурс, предоставляемый библиотекой DLL, без указания обработчика экземпляра DLL. AfxFindResourceHandle — это API, используемый для анализа списка ресурсов для поиска заданного соответствия. Он принимает имя и тип ресурса и возвращает маркер ресурса, в котором он был впервые найден (или значение NULL).
Если вы не хотите анализировать список и хотите загрузить ресурсы только из определенного места, используйте функции AfxGetResourceHandle и AfxSetResourceHandle , чтобы сохранить старый обработчик и задать новый. Не забудьте восстановить старый обработчик ресурсов перед возвратом в клиентское приложение. Пример использования этого подхода для явной загрузки меню см. в разделе Testdll2.cpp в примере MFC DLLHUSK.
В случае с примером MFC DLLHUSK список выглядит примерно следующим образом:
где xx — это номер версии; например, 42 представляет версию 4.2.
MFCxx.dll обычно является последним в списке ресурсов и классов. MFCxx.dll содержит все стандартные ресурсы MFC, включая строки запросов для всех стандартных идентификаторов команд. Размещение в конце списка позволяет библиотекам DLL и клиентскому приложению не иметь собственной копии стандартных ресурсов MFC, но вместо этого использовать общие ресурсы в MFCxx.dll.
Объединение ресурсов и имен классов всех библиотек DLL в пространство имен клиентского приложения не требует соблюдения осторожности при выборе идентификаторов или имен.
Пример DLLHUSK управляет пространством имен общих ресурсов с помощью нескольких файлов заголовков.
Если библиотека DLL расширения MFC должна поддерживать дополнительные данные для каждого приложения, можно создать новый класс на основе CDynLinkLibrary и создать его в DllMain . При запуске библиотека DLL может проверить список объектов CDynLinkLibrary текущего приложения, чтобы найти ресурс для конкретной библиотеки DLL расширения MFC.
Такой вот совет пришел ко мне с рассылкой "Ежедневная рассылка сайта Мастера DELPHI", думаю многим будет интересно.
Решить эту задачу нам поможет функция function ExtractIcon(hInstance, filename, iconindex):integer где hinstance - глобальная переменная приложения, ее изменять не надо. Тип integer.
filename - имя программы или DLL из которой надо извлекать иконки. Тип pchar. iconindex - порядковый номер иконки в файле (начинается с 0). В одном файле может находится несколько иконок. Тип integer.
Функция находится в модуле ShellApi, так что не забудьте подключить его в uses. Если эта функция возвратит ноль, значит иконок в файле нет.
Данная функция возвращает handle иконки, поэтому применять ее нужно так: Image1.Picture.Icon.Handle:=ExtractIcon(hInstance, pchar(paramstr(0)), 0);
данное объявление нарисует в Image'e картинку вашего приложения.
Автор: Михаил Христосенко
Как загрузить BMP файл из DLL?
procedure TForm1.Button1Click(Sender: TObject);
AModule := LoadLibrary( 'Images.dll' );
Работа с ресурсами
Сохранить файл в ресурсе программы на этапе компилляции можно выполнив следующие шаги:
1) Поставить себе RxLib
2) Появится в меню "Project" дополнительный пункт меню "Resources"
3) Открой его , создай новый ресурс "User Data", в него загрузи нужный файл, измени имя ресурса на что-нибудь типа 'MyResName'.
Теперь при компилляции проэкта в exe файл будет прикомпиллирован ваш файл в виде ресурса. Извлечь его на этапе выполнения можно следующим образом:
Сохранение и выдёргивание ресурсов в DLL или EXE?
Иногда возникает необходимость вшить ресурсы в исполняемый файл Вашего приложения (например чтобы предотвратить их случайное удаление пользователем, либо, чтобы защитить их от изменений). Данный пример показывает как вшить любой файл как ресурс в EXE-шнике.
Далее рассмотрим, как создать файл ресурсов, содержащий корию какого-либо файла. После создания такого файла его можно легко прицепить к Вашему проекту директивой . Файл ресурсов, который мы будем создавать имеет следующий формат:
+ заголовок для нашего RCDATA ресурса
+ собственно данные - RCDATA ресурс
Таблицы строк
Ресурсы в виде таблиц строк (Stringtable) являются очень полезным подспорьем, когда ваше приложение должно хранить большое количество строк для их вывода во время выполнения приложения. Вы должны побороть искушение непосредственной вставки строк в вашу программу, поскольку использование таблиц строк имеет два неоспоримых преимущества:
1) Строки, хранимые в ресурсах, не занимают память до тех пор, пока они не будут загружены вашим приложением.
2) Stringtables легко редактировать, создавая таким образом локализованные (переведенные) версии вашего приложения.
Таблицы строк компилируются в ".res"-файл, который включается в exe-файл приложения во время сборки. Даже после того, как вы распространите ваше приложение, таблицы строк, содержащиеся в вашем приложении могут редактироваться редактором ресурсов. Моим любимым редактором ресурсов является Borland Resource Workshop, поставляемый в комплекте с Delphi. Он позволяет в режиме WYSIWYG редактировать как 16-, так и 32-битные ресурсы, как автономные, так и имплантированные в exe или dll-файлы. Тем более это удобно, если учесть что вместе со всеми версиями Delphi поставляется компилятор
ресурсов из командной строки (Borland Resource Command Line Compiler) (BRCC.EXE и BRCC32.EXE), расположенный в Delphi-директории Bin.
Как поместить JPEG-картинку в exe-файл и потом загрузить ее?
1)Создайте текстовый файл с расширением ".rc".Имя этого файла должно отличаться
от имени файла - пректа или любого модуля проекта.
Файл должен содержать строку вроде: MYJPEG JPEG C: \DownLoad\MY.JPG
"MYJPEG" имя ресурса
"JPEG" пользовательский тип ресурса
"C: \DownLoad\MY.JPG" руть к JPEG файлу.
Пусть например rc - файл называется "foo.rc"
Запустите BRCC32.exe(Borland Resource CommandLine Compiler) - программа находится
в каталоге Bin Delphi / C + +Builder'а - передав ей в качестве параметра полный путь
Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.
Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.
32-битные и 64-битные приложения
Операционная система Windows бывает 32-разрядная и 64-разрядная. Соответственно, Modern-приложения тоже могут быть 32-битные либо 64-битные. При загрузке приложения в магазин Microsoft разработчик собирает обе версии (плюс еще, возможно, ARM), а Windows уже сам решает, какую загрузить пользователю. Отсюда следует очевидный вывод, что DLL-ка, которую мы будем внедрять в Modern-приложение, тоже должна быть в двух вариантах. Менее очевидный вывод в том, что приложение, которое будет «забрасывать» нашу DLL-ку в чужой процесс, тоже должно быть соответствующей битности. Нам ведь нужно запустить внутри чужого процесса поток, который загрузит нашу библиотеку и вызовет из неё какую-то функцию. Делается это через вызов CreateRemoteThread(Ex), а вот уже она требует одинаковой битности вызывающего и вызываемого процессов (а иначе как передавать адреса?).
- InjectedLibrary32.dll
- InjectedLibrary64.dll
- Injector32.exe
- Injector64.exe
Доступ к внедряемой DLL
Как вы, возможно, знаете, Modern-приложения живут в своих песочницах, откуда они имеют доступ только к своей папке и некоторым другим доступным для них (ограниченным) ресурсам ОС. К примеру, Modern-приложение не может вот просто так взять и открыть любой файл с диска. Для нас это означает то, что попытавшись заставить чужое приложение подгрузить нашу библиотеку в своё адресное пространство — мы получим ошибку доступа. Это можно легко увидеть, воспользовавшись, к примеру, утилитой ProcMon.
Что же делать? Разрешить доступ к файлу внедряемой библиотеки для Modern-приложений. Для этого есть системная утилита icacls. Вот эта команда открывает доступ к файлу на диске для всех Modern-приложений:
Теперь ошибки доступа у нас не будет.
Линковка DLL-ки
Но не всё так просто. DLL-ка может иметь зависимости. И даже если вам кажется, что их нет — возможно, вы забываете о зависимости от VC++ Runtime Library. По умолчанию созданная в Visual Studio С++ библиотека предполагает динамическую линковку с рантайм-библиотекой С++. Это означает, что когда какое-то приложение захочет загрузить вашу библиотеку — функция LoadLibrary() первым делом увидит, что вам необходима, к примеру, библиотека msvcp90r.dll и попытается её найти, что вобщем-то, получится если речь идёт об обычном (не Modern) приложении и наличии соответствующего VC++ Redistribution Package. Что касается Modern-приложений, то порядок поиска DLL-ок совсем другой. Если коротко: будучи вызванной из Modern-приложения, LoadLibrary() не найдёт библиотеки VC++ Redistribution Package, даже если они до этого были успешно установлены.
- Копировать VC++ Runtime Library в папку Modern-приложения
- Копировать VC++ Runtime Library в %SystemRoot%\system32
- Прописать библиотеки в специальный раздел в реестре (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs)
- Использовать статическую линковку (когда код VC++ Runtime Library включается в тело нашей DLL-ки)
Первые два способа крайне некрасивы (а без аккаунта администратора и невозможны), третий — сработает, но влияет на глобальную конфигурацию ОС, что тоже может быть чревато последствиями. Так что самый простой вариант — статическая линковка (ключи /MTd и /MT на вкладке Code Generation).
Цифровая подпись
Решив все вопросы с доступом к файлу DLL-ки может показаться, что у нас всё получилось — ProcMon не показывает никаких ошибок доступа. Но инъекция всё равно не работает — DLL-ка не появляется в списке загруженных модулей процесса. Что же пошло не так? На этот вопрос нам даёт ответ просмотр Windows Event Viewer.
Операционная система не хочет загружать нашу DLL-ку, поскольку она не подписана. В этом месте мне стало тревожно, поскольку я уж было подумал, что все модули, загружаемые в Modern-приложение, должны быть подписаны цифровой подписью одного издателя (разработчика). Но, к счастью, это не так. Windows требует от DLL-ки просто наличия валидной цифровой подписи, но не требует её соответствия подписи автора приложения. Т.е. мы можем взять подписанную DLL-ку от Хрома и забросить её в Spartan. Что же делать нам? Получить сертификат и подписывать нашу DLL-ку.
Да, это серьёзно усложняет работу. Но ведь в принципе, если мы разрабатываем нормальный продукт, а не какие-нибудь вирусы\трояны\малвари\кейлоггеры\локеры — у нас не будет проблем с получением сертификата и его использованием для подписи DLL-ки. Вообще, я считаю эту защиту одной из самых серьёзных шагов Microsoft по защите пользовательских данных и изоляции Modern-приложений в песочнице. Фактически от желающего пробросить мостик к приложению требуют предъявить документы и идентифицироваться, а это остановит 99% скрипт-киддисов.
Права доступа на канал связи
Ок, теперь наша DLL-ка внедрена в чужой процесс, она может вешать хуки на разные системные функции, делать что-то полезное, но… Сама она живёт в той же песочнице, что и родительский процесс, то есть ни передать данные «наружу», ни получать команды «извне» она не может, ведь для этого нужно создать канал связи, на который она по умолчанию не имеет прав. Как решать эту задачу я уже отдельно рассказывал вот в этой статье, а здесь просто упоминаю в качестве пункта, о котором важно не забыть.
Читайте также: