Extension dll параметр что это
Для начала нужно разобраться, что же такое DLL.
DLL — это сокращение фразы Dynamic-Link Library — динамически подключаемая библиотека.
Первоначальная идея введения библиотек заключалась в более рациональном использовании ресурсов ПК, таких как ОЗУ и НЖМД. Предполагалось, что различные приложения будут использовать одну библиотеку, тем самым ликвидируя проблему сохранения одинаковых участков кода в различных местах и многократную загрузку одинаковых участков в ОЗУ.
В дальнейшем, было решено увеличить эффективность разработки приложений за счёт модульности. Обновление самих DLL должно было позволить расширять и усовершенствовать систему, не затрагивая при этом всех приложений. Однако, данная идея столкнулась с проблемой одновременного требования приложениями разных, не полностью совместимых версий библиотек, что приводило к сбоям. Данная проблема была названа "DLL Hell".
По сути, DLL - это относительно независимый участок кода, имеющий свою оболочку.
Оболочка DLL имеет секции импорта/экспорта.
Секция экспорта перечисляет те идентификаторы объектов (классы, функции, переменные), доступ к которым предоставляет данная DLL. В большинстве случаев именно эта секция вызывает особый интерес у разработчиков. Тем не менее, DLL может вовсе не содержать секцию экспорта. Кроме функций, к которым можно получить доступ извне (exported), существуют также внутренние функции (internal), которые спрятаны от "посторонних глаз" и могут использоваться лишь кодом самой DLL.
Секция импорта предназначена для связи данной DLL с другими.
Большинство библиотек импортируют функции из системных DLL (kernel32.dll, user32.dll и др.). Иногда в стандартный список нужно добавить другие библиотеки, например ws2_32.dll для работы с Socket'ами.
DLL не может выполняться сама по себе, поэтому требует хост-процесс (главный процесс, в котором предполагается использование DLL).
Перед тем, как библиотеку можно будет использовать, её необходимо загрузить в область памяти хост-процесса. В exe-файле компилятором будет сгенерирована инструкция вызова заданной функции (call).
Т.к. DLL расположена в адресном пространстве процесса, то вызов функции из библиотеки будет иметь вид:
При выполнении команды call, процессор передает управление на код с адреса 010199, и выполняет его до команды ret, а затем возвращает управление команде следующей за call. Код который вызывается командой call называется процедурой.
Файл, являющийся динамически загружаемой библиотекой не всегда носит расширение *.dll.
Есть также: *.cpl (библиотеки, используемые апплетом панели управления) и *.ocx.
Библиотеки удобно использовать для разделения приложения на части, выполняющие разные роли.
Например, приложение, обеспечивающее работу с базами данных может быть разделено на часть, отвечающую за выборку данных из базы, находящейся на сервере, и, часть, которая отвечает за визуальное управление приложением. Это явный пример той модульности, о которой я упоминал выше. Вы в праве изменять принципы обмена данными с сервером БД, не затрагивая при этом работу с визуальной частью.
- 1.3. Необходимость внедрения DLL. Нужно ли это?
Настало время ответить на вопрос: Когда же нужно использовать DLL?
Если вы разрабатываете небольшой проект или тестовое приложение, то внедрение DLL будет для вас пустой тратой времени и сил. Тратой времени: не только времени на создание библиотеки, но ещё и времени, необходимого для загрузки DLL в память хост-процесса. До того, как вы будете использовать объекты из DLL, вам рано или поздно прийдётся выгрузить содержимое в память. А это требует некоторого времени.
Однако, если вашу DLL будет использовать более, чем одна копия приложения (или несколько различных приложений) - наступит явный выигрыш.
Для эксперимента запустите Microsoft Office. Первый запуск долгий. Это обусловлено тем, что все необходимые модули загрузаются в оперативную память. Теперь полностью закройте Office и снова откройте его! Окно появится почти мгновенно. Это обусловлено тем, что модули хранились в ОЗУ (система не тронет их, пока ей не понадобится память для других целей).
При создании больших проектов лучше сразу пытаться представить себе части, которые могут быть уникальными и требующими частого усовершенствования.
Но не старайтесь придать вашему проекту чрезвычайной "уникальности" за счёт помещения каждой функции в отдельную библиотеку! Это можно делать, только зачем тратить время для загрузки каждого модуля?
- 2.1. Создаём первую DLL своими руками.
Пришло время постепенно перейти от теории к практике.
Открываем IDE (для написании данной статьи я использовал RAD Studio 2010).
Переходим к File -> New -> Other -> Dynamic-Link Library.
Перед нами возникает диалог:
Source Type - язык, на котором ведётся разработка.
Use VCL - использование библиотеки визуальных компонентов.
Multi Threaded - опция, указывающая на то, будет ли использоваться многопоточность в данной DLL (VCL уже подразумевает в себе многопоточность).
VC++ Style DLL - опция, указывающая на то, будет ли DLL совместима с компиляторами Microsoft.
Если в совместимости нет нужды и опция не выбрана, то DLL будет иметь точку входу с таким прототипом:
Оставим диалог без изменений и нажмём "ОК".
Перед нами появится шаблон минимальной DLL. Сохраним его.
Как вы помните, сама по себе DLL работать не может, ей нужен клиент. Поэтому, для удобства сразу создадим новый проект VCL Forms Application.
Для этого переходим в Project Manager, вызываем контекстное меню у нашей Project Group и переходим к Add New Project -> VCL Forms Application.
Для удобста я назвал проекты TestDLL и TestVCL соответственно (и сохранил их в одном каталоге - это избавит меня от копирования DLL или указания абсолютного пути):
Без изменений запускаем TestVCL, сохраняем и переключаемся к проекту TestDLL (дабл-клик на проекте в Project Manager).
Переходим к Run -> Parameters и в поле Host Application указываем путь к нашему проекту TestVCL.
К шаблону DLL добавляем функцию, которая будет вычислять сумму и выводить результат на экран:
Сохраняем. Запускаем. DLL мы подготовили. Теперь необходимо узнать, как же подключить DLL к проекту. Сделать это можно тремя способами. Рассмотрим их подробнее.
При неявной загрузке DLL загружается (проецируется на адресное пространство вызывающего процесса) при его создании. Если при загрузке возникает ошибка - процесс останавливается и разрушается.
Для выполнения неявной загрузки приложению требуются:
- Заголовочный файл (*.h) с прототипами функций, описаниями классов и типов, которые используются в приложении.
- Библиотечный файл (*.lib), в котором описывается список экспортируемых из DLL функций (переменных), и их смещения, необходимые для правильной настройки вызовов функций.
В проекте TestVCL подключим наш заголовочный файл:
Далее, объявим прототип:
Теперь осталось только вызвать функцию там, где это необходимо.
Чтобы убедится в том, что всё работает, прописываем в конструкторе формы:
Запускаем и смотрим на результат. Думаю, "3 + 2 = 5" всех устраивает.
Для того, чтобы выполнить явную загрузку программист должен попыхтеть, управляя DLL через функции WinAPI.
Наиболее часто рассматриваемые WinAPI функции:
DisableThreadLibraryCalls, FreeLibrary, FreeLibraryAndExitThread, GetModuleFileName, GetModuleHandle, GetProcAddress, LoadLibrary .
При этом, основными функциями являются:
LoadLibrary[Ex] - позволяют загрузить DLL в адресное пространство хост-процесса.
FreeLibrary - функция, используемая для явной выгрузки DLL.
GetProcAddress - функция, позволяющая получить виртуальный адрес экспортируемой из DLL функции(или переменной) для ее последующего вызова.
Общая методика выглядит так:
1. Загрузить DLL с помощью LoadLibrary.
2. Получить указатели на необходимые объекты с помощью GetProcAddress.
3. Выгрузить DLL после завершения всех действий.
Теперь возникает вопрос, как же проверить теорию на практике?
Всё, что нужно, это добавить TestDLL.lib к проекту (также, как и при неявной загрузке).
А дальше, для проверки снова пишем в конструкторе формы:
И на экране снова красуется победная надпись "3 + 2 = 5"
Остался один неосвещенный вопрос. Почему же название функции "ShowSum" мы ищем в библиотеке с нижним подчёркиванием?
Виновато во всём декорирование имён.
Прототип функции Test(int); мог быть преобразован компилятором, например в ?Test@@YAKH@Z.
Естественно, такое декорирование нам вообще не по душе. Избавиться от него можно объявляя все экспортируемые функции с модификатором extern "C" - тогда компилятор не будет искажать имя функции.
Однако, как мы видим, нижние подчёркивание всё же добавилось.
Это один из нюансов среды C++ Builder. Однако, можно отучить его добавлять нижнее подчёркивание таким образом:
Project -> Options -> C++ Compiler -> Output -> Generate underscores on symbol names - перевести в состояние false.
Для чего же нужна отложенная загрузка?
Представьте себе ситуацию: вы написали приложение, использующее стандартные системные библиотеки вашей новой операционной системы, скажем, для проверки орфографии.
Даёте это приложение пользователю, который использует ОС более старой версии, чем у вас и в этой ОС нет функций для проверки орфографии. А пользователю это не сильно и надо. Приложение будет работать, пока не обратится к необходимой функции. То есть, фактически, DLL не нужна до обращения к определённой функции. Исключение отсутствия можно обработать и выдать пользователю предупреждение с просьбой обновить библиотеки своей ОС (и т.п.).
Использование отложенной загрузки DLL в C++ Builder мало отличается от неявной загрузки.
В проект добавляется заголовочный (*.h) файл с описаниями и библиотечный файл (*.lib).
Далее, переходим в Project -> Options -> C++ Linker -> Advanced -> Delay Load DLLs и вписываем название нашей библиотеки (TestDLL.dll).
Когда библиотека теряет свою необходимость её нужно явно выгрузить с помощью __FUnloadDelayLoadedDLL. В качестве параметра передаём имя DLL (с расширением + параметр регистрозависим).
Если вы используете многопоточные приложения - убедитесь, что все потоки завершили работу с DLL.
Примечание: Нельзя использовать отложенную загрузку для библиотек, имеющих секцию импорта (т.е. использующих другие библиотеки), а также Kernel32.dll и RTLDLL.dll (т.к. функции поддержки отложенной загрузки как раз и находятся в последней).
3. Заключение.
Данная статья даёт вам представление о возможных вариантах использования DLL в ваших проектах.
При внимательном ознакомлении с методами загрузки можно выбрать наиболее оптимальный вариант.
Подведя итоги можно выявить плюсы и минусы описанных методов:
Явная загрузка:
+ контроль и управление процессом жизни DLL.
- управлением DLL занимается программист посредством WinAPI.
Неявная загрузка:
+ все заботы берет на себя компилятор и сборщик.
- ресурсы заняты всё время жизни приложения.
Отложенная загрузка:
+ все заботы берет на себя компилятор и сборщик.
+ возможность использования приложения с не полностью совместимыми DLL.
- необходимость усиленного контроля за многопоточными приложениями.
Создание программ с использованием объектно-ориентированного подхода - это практика программирования, в основу которой положены те же принципы, что используются при любом техническом проектировании. И это существенно облегчает разработку, снижает затраты, уменьшает число ошибок, сокращает сроки и является приемом борьбы со сложностью в больших проектах.
DLL ( Dynamic-Link Library ) - динамически загружаемые библиотеки. Существуют два типа DLL
- Обычные DLL MFC - библиотеки ( MFC regular DLL )
- Расширенные DLL MFC - библиотеки ( MFC extension DLL )
Динамически подключаемая библиотека - это специального вида исполняемый файл с расширением .dll , используемый для хранения классов, функций и ресурсов отдельно от исполняемого файла.
Существует и другой способ хранения скомпилированного кода отдельно от исходного кода приложения - в библиотечных файлах с расширением .lib . Этот код включается в приложение линковщиком в процессе создания приложения. Такой процесс называется статическим связыванием. Код библиотеки хранится в исполняемом файле приложения. И если библиотеку использует несколько приложений, экземпляр кода будет включен в исполнимый файл каждого приложения.
Использование DLL обеспечивает динамическое связывание, когда код библиотеки загружается в память и присоединяется к приложению при его запуске на выполнение. Приложение, запущенное на выполнение, называется процессом. Если одновременно выполняются несколько процессов, то каждый процесс может загружать из DLL и присоединять к себе нужную функцию или даже все процессы одну и ту же функцию одновременно.
Применение DLL позволяет реконструировать и сопровождать функцию (или класс) только в одном экземпляре и все внесенные в нее изменения будут немедленно учтены любыми использующими ее приложениями без предварительной их перекомпиляции. Можно считать, что DLL является источником кода, а все упакованные в нее функции и классы - экспортируемыми функциями и классами.
Создание программ с использованием объектно-ориентированного подхода - это практика программирования, в основу которой положены те же принципы, что используются при любом техническом проектировании
Достоинства DLL
- Поскольку в DLL можно разместить функции, к которым обращаются многие приложения, то уменьшаются размеры исполняемых файлов приложений на этапе компиляции
- Если интерфейс DLL не изменяется, то ее можно заменить более новой, причем сами приложения обновлять не придется
- При надлежащем выборе типа DLL ее можно использовать в приложениях, написанных на других языках программирования для Windows
Динамически загружаемые библиотеки - это файлы с заранее откомпилированными кодами функций или классов, которые могут использоваться другими приложениями на этапе выполнения. Функция или класс добавляются в специальную таблицу, являющуюся неотъемлемой частью DLL . В таблице указывается местоположение всех функций и классов, содержащихся в DLL , что обеспечивает быстрый их поиск и вызов исполняемым внешним приложением при его загрузке в память.
Приложение может вызывать код из DLL двумя способами:
- По таблице определяется местоположение нужной функции, создается указатель на найденную функцию, с помощью указателя вызывается сама функция
- Приложение линкуется с обычным библиотечным LIB -файлом, в котором содержатся фиктивные модули программного кода (заглушки). При запуске приложения фиктивный псевдокод замещается реальным кодом из DLL
Заглушка - это псевдофункция, у которой имя и список аргументов совпадают с именем и списком аргументов реальной функции. Внутри функции-заглушки имеется незначительное количество кода, вызывающего реальную функцию из DLL , причем реальной функции при вызове передаются все те аргументы, которые были переданы заглушке. В этом смысле функции DLL можно рассматривать как часть кода приложения, а не как отдельный файл.
Второй способ значительно проще. Библиотечный LIB -файл при компиляции DLL создается автоматически. Для его создания не приходится предпринимать каких-либо особых действий. При использовании LIB -файлов все используемые в приложении DLL загружаются в память в момент запуска приложения и если некоторые из них отсутствуют, то Windows автоматически предупреждает об этом и приложение не выполняется.
Когда используется первый способ, разработчику приложения необходимо самостоятельно организовывать загрузку DLL в память и обрабатывать все ошибочные ситуации при отсутствии нужных DLL .
DLL создаются с помощью оболочки Visual Studio специальным мастером DLL Wizard .
MFC extension DLL
MFC extension DLL - это динамически загружаемые библиотеки, расширяющие библиотеку базовых классов MFC . Такой тип DLL легче всего создавать и кодировать. Чтобы сделать класс экспортируемым DLL , нужно при его объявлении указать макрос AFX_EXT_CLASS примерно так
Далее в приложении, использующем класс, достаточно будет включить этот макрос, и при запуске приложения будет импортирование из DLL нужный класс.
Одним из недостатков MFC extension DLL является то, что их нельзя использовать в программах, написанных на других языках программирования или в программах C++ , компиляторы которых не поддерживают MFC . Но компиляторы фирмы Borland и Symantec поддерживают MFC extension DLL .
MFC regular DLL
MFC regular DLL - это обычные динамически загружаемые библиотеки. Этот тип DLL поддерживает стандартные функции, а не классы, поэтому планировать их приходится несколько тщательнее, чем MFC extension DLL . Внутри самой DLL классы можно использовать, но вызов кода внешним приложением нужно организовать через функцию.
Для обеспечения возможности экспорта функции библиотекой следует эту функцию объявить экспортируемой по такому синтаксису
Необходимо включить все эти дополнительные слова как в заголовочный файл прототипа функции, так и в исходный код ее реализации.
- Выражение extern "C" объявляет, что это вызов стандартной функции C, поэтому корректировщик имен C++ не должен корректировать имя функции
- Ключевое слово PASCAL сообщает компилятору, что все параметры функции передаются в порядке, принятом в языке PASCAL , т.е. параметры в стеке размещаются в порядке, обратном обычному
- Ключевое слово EXPORT информирует компилятор о том, что эта функция будет экспортироваться динамически загружаемой библиотекой во внешние приложения
Для создания DLL применяется специальный тип проекта оболочки Visual Studio . Чтобы сделать функции экспортируемыми DLL, следует добавить их имена в файл определений DEF.lib этого проекта. Файл DEF.lib представляет собой библиотечный (т.е. с расширением LIB ) файл заглушек и таблицу экспортируемых функций, содержащихся в DLL . В него включается имя DLL , ее краткое описание и имена всех экспортируемых библиотекой функций. Файл DEF проекта DLL автоматически создается мастером "DLL Wizard" и имеет определенный формат. Формат файла изменять нельзя, в него можно только добавлять имена экспортируемых функций.
Примерный вид файла определений DEF.lib
Если в MFC regular DLL используются классы из MFC , то первой строчкой тела всех экспортируемых функций должен быть вызов макроса AFX_MANAGE_STATE . Это диктуется необходимостью обеспечить многопоточную поддержку в функциях, благодаря которой можно вызывать функции класса одновременно несколькими потоками процесса. Макрос AFX_MANAGE_STATE имеет единственный аргумент - указатель на структуру AFX_MANAGE_STATE , который можно получить в результате вызова функции AfxGetStaticModuleState() . Типичная экспортируемая функция, использующая библиотеку MFC , имеет следующий вид
При проектировании функций для DLL нужно соблюдать правила:
- Поскольку некоторые функции могут одновременно вызываться несколькими потоками процесса, то следует в них предусмотреть поддержку многопоточности
- Функции не должны обрабатывать глобальные переменные, а все необходимые значения для локальных переменных должны передаваться функциям через аргументы. Если же все-таки необходимо обрабатывать глобальные переменные функциями, то следует предусмотреть для них защиту с помощью механизма синхронизации потоков
Создание и использование MFC extension DLL
Создадим одну библиотеку DLL , расширяющую MFC , в которую включим два класса. Работа будет опираться на результаты работы Lab10 . Первым пусть будет класс MyLine из этой работы. Второй класс будет создавать случайные рисунки на поверхности рисования. В него войдет массив объектов MyLine , который он будет создавать и заполнять данными во время рисования.
В этом классе должна находиться функция для сохранения и восстановления рисунков, а также для удаления уже не нужных рисунков, чтобы можно было создавать новые. Кроме того, класс должен знать размеры поверхности рисования, так как ему придется генерировать рисунки в границах поверхности рисования.
Для чего вообще нужно внедрять свои 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-ка внедрена в чужой процесс, она может вешать хуки на разные системные функции, делать что-то полезное, но… Сама она живёт в той же песочнице, что и родительский процесс, то есть ни передать данные «наружу», ни получать команды «извне» она не может, ведь для этого нужно создать канал связи, на который она по умолчанию не имеет прав. Как решать эту задачу я уже отдельно рассказывал вот в этой статье, а здесь просто упоминаю в качестве пункта, о котором важно не забыть.
Что такое dll файл?
Какие dll файлы задействуются программами прямо сейчас, можно узнать, запустив, к примеру, утилиты Autoruns for Windows , пробежавшись по вкладкам программы:
Как работает dll файл?
Любая устанавливаемая в Windows программа всегда использует либо свои немногочисленные или имеющиеся в системе dll-ки. Программа обычно загружает свою dll-ку во время автозагрузки через специальную библиотеку Win32 API LoadLibrary или по сигналу с другого dll-файла. Обычно это выглядит так:
К СВЕДЕНИЮ
Куда они исчезают, или почему в системе отсутствует dll файл ?
попытка снять с регистрации файл для последующей правильной его установки в реестре провалилась
Почему нельзя просто его скачать?
решения не обнаружилось: всё равно ошибка и ничего не работает. Почему? Ответ для внимательных очевиден: вы никогда не задумывались, что Windows обновляет прежде всего ? Да-да, скачанный вами файл просто морально устарел , и вам в любом случае придётся искать уже обновлённую его версию. Вобщем, действуйте в этом варианте на свой страх и риск.
Прокатывает не всегда, ибо это инструмент общего действия. Однако попробовать стоит. Внутри побитого файла она ничего изменить не сможет, но системные файлы могут быть подменены. Однако, если задет файл конкретной программы, утилита отрапортует, что всё хорошо и захлопнется. Оставив вас ни с чем.
Советов здесь немного, и главный из них должен решаться ещё на этапе установки машины. Старайтесь не смешивать типы файловых систем самой машины и носителей для них и не разносите по разным томам папку с программой и носителями для неё.
Читайте также: