Программа библиотека dll функции

Содержание

Осваиваю работу с dll , по вот этому полезному материалу: Как подключить к своей программе DLL -библиотеку Проблема вот какая: Есть несколько методов и все они находятся в dll . Как можно вызвать интересующий нас метод? Может к GetProcAddress прибавить смещение какое-то? Спасибо.

Отслеживать
371 1 1 золотой знак 5 5 серебряных знаков 13 13 бронзовых знаков
задан 29 авг 2013 в 16:52
2,586 8 8 золотых знаков 50 50 серебряных знаков 104 104 бронзовых знака
Каких ещё методов? Пример — в студию!

29 авг 2013 в 17:51

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

29 авг 2013 в 18:01
29 авг 2013 в 18:20

progzdeveloper, а можно простой пример? Просто имя функции в dll и имя указателя на нее в исполняемом файле должны совпадать?

Динамически загружаемые библиотеки (DLL)

29 авг 2013 в 19:21
29 авг 2013 в 22:27

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

При создании проекта в компиляторе укажите библиотека DLL. (в visual studio создать->проект->win32(или консоль) -> далее -> библиотека dll + пустой проект) далее вставить код

#include #include extern «C» __declspec(dllexport) void dll_function(int arg); extern «C» __declspec(dllexport) void dll_function(int arg) < std::cout LPCSTR func_name = «dll_function»; // название загружаемой функции FARPROC adresse_la_func = GetProcAddress(le_module, func_name); if(adresse_la_func!=0) < std::cout FreeLibrary(le_module); std::cout
Отслеживать
ответ дан 30 авг 2013 в 11:17
6,333 7 7 золотых знаков 47 47 серебряных знаков 92 92 бронзовых знака

C подключением и вызовом функций из dll разобрался, хотя что вот это GetModuleFileName(NULL, (LPTSTR)mod_name, size__); в вашем примере(извлекает путь к исполняемому файлу текущего процесса), что она сделает? Сейчас вопрос возник с листингом DUMPBIN. Содержание листинга не совсем понтно?

30 авг 2013 в 11:31

1)Это ничего, можно убрать. 2) Зачем вам этот листинг? Вы функцию получили? Вот и все что необходимо знать. Остальное уже не относится к вопросу.

30 авг 2013 в 12:59
Но а все же, если знаете. Или просто новый вопрос задать?
30 авг 2013 в 18:36

Продолжил разбираться и наткнулся на программу DUMPBIN, которая:

The Microsoft COFF Binary File Dumper (DUMPBIN.EXE) displays information about Common Object File Format (COFF) binary files. You can use DUMPBIN to examine COFF object files, standard libraries of COFF objects, executable files, and dynamic-link libraries (DLLs). Это отсюда: http://msdn.microsoft.com/en-us/library/c1h23y6c.aspx

alt text

Итак, я захотел посмотреть таблицу импорта библиотеки которую сам же и собрал. Вот что я увидел:

Где тут таблица импорта? Кроме имени функции, содержащейся в dll ничего не смог разобрать. Сколько переменных и какого типа она принимает, что возвращает функция, если вообще что-то возвращает? На эти вопросы можно по этой картинке ответить? Что такое Summary, что за цифры?

Разработка приложений с помощью WinAPI. Урок 12 DLL. Функции

Цифры 0 00011005-это смещение в памяти по которому будет расположен указатель на функцию, по которому вызывается функция? Что за характеристики и 00000000? И прочие цифры типа 1 ordinal base что означают? Что за порядок? Расшифруйте кто может)

Источник: ru.stackoverflow.com

Статья DLL библиотеки – инструкция к метле

Ещё во-времена старушки дос стало очевидно, что некоторые программные модули лучше хранить не внутри исполняемого файла, а вынести их наружу и подгружать по мере необходимости. В то время такие «прицепы» называли оверлеями и с точки зрения экономии 1М-байтного адресного пространства это было разумно – одну большую программу кромсали на мелкие части, и эти части отрабатывали в памяти по очереди. Подобная техника докатилась и до наших дней, только теперь это динамически подгружаемые DLL.

По сути, нет смысла копать данную тему в очередной раз – всё давно расписано, поэтому добавим экшена и сделаем ставку на нестандартное их применение. Как показывает практика, фишка с защитой программ на основе статически прилинкованных DLL пользуется спросом среди коммерческого софта, значит пора сорвать с неё вуаль и познакомиться по-ближе.
—————————————

«Dynamic Link Library» или DLL – это часть исполняемого РЕ-файла в виде внешнего модуля. Он оформлен как ларчик с N-нным количеством уникальных для наших программ функций, которых нет в составе системных Win32-API. Программный экзо-скелет динамических библиотек идентичен исполняемым файлам экзе, однако есть и некоторые нюансы:

1. Наличие секции-экспорта в коде, которой могут похвастаться исключительно библиотеки. Приложение может вызывать (импортировать) только те функции из DLL, которые оглашены в её секции-экспорта «.edata» . Однако бывают и внутренние функции, которые DLL не экспортирует во-внешний мир, используя только внутри своей тушки для производственных нужд – к их числу можно отнести, например функцию точки-входа в библиотеку DllEntryPoint() . По сути, в данной статье мы сделаем акцент только на этой процедуре инициализации.

2. Второе отличие DLL от EXE – это не способность ими исполнять свой код самостоятельно, поскольку каждый участок кода обёрнут в отдельную функцию. Все эти функции тупо ждут своего часа, пока их услуги не станут восстребованы экзе-файлу и он не затребует их явно. Исключение здесь составляет только упомянутая точка-входа, с которой без нашего ведома активно общается загрузчик LDR, на протяжении всего времени работы приложения.

Система предоставляет нам два способа подключения DLL к своим проектам – статический и динамический . В первом случае мы подключаем библиотеку и указываем импортируемые из неё функции на этапе компиляции РЕ-файла, и эти функции сразу загружаются в наше адресное пространство, вместе с приложением. Во-втором (динамическом) случае, можно загрузить функцию из DLL в произвольный момент времени, сыграв аккордом LoadLibrary() , GetProcAddress() и FreeLibrary() .

Скомпоновать библиотеку довольно просто – пишем обычный ЕХЕ, только в шапке указываем директиву «format PE DLL» . В результате, из выхлопной трубы fasm’a получим файл в формате *.dll. Однако при программировании пользовательских библиотек нужно учитывать ряд их особенностей, в частности релокацию образа в памяти.

Чтобы DLL не загрузилась поверх исполняемого приложения (конфликт базовых адресов), её ImageBase обязательно должна быть перемещаемой – достаточно добавить секцию .reloc в коде, об остальном компилятор позаботится сам. В этой секции будут собраны т.н. фиксапы (fixups) – адреса, к которым загрузчик должен будет внести поправки. Фиксапы применяются исключительно к инструкциям, которые обращаются по абсолютным адресам в памяти. Если адрес относительный (в пределах 127 байт), то он не требует модификации:

Такие отладчики как OllyDbg подчёркивают адреса, которые требуют коррекции после перемещения образа в памяти – на рис.выше их всего 4, и непосредственно опкод инструкции не учитывается (здесь pushcall, хотя могут быть и условныебезусловные переходы). Размер самих фиксапов равен 12-бит (выделены красным), а это 2^12=4096 или одна страница виртуальной памяти. Соответственно фиксап не может адресовать блок памяти свыше 4 Кбайт. Другими словами, каждая страница (блок) имеет свой набор фиксов.

Точка входа в DLL-библиотеку

Теперь о насущном..
Подобно исполняемым экзе-приложениям, библиотеки тоже имеют свою точку входа – в доках MSDN эта функция известна как DllEntryPoint() (или DllMain в терминологии си). Здесь и кроется всё самое интересное, чему мы посвятим весь последующий разговор.

Любое обращение EXE-модуля к функциям из DLL происходит через системного посредника LdrLoadDLL() . В системном ансамбле, эта кошерная функция из Ntdll.dll играет огромную роль. Она не только загружает библиотеки в пространство юзера на этапе проецирования образа в память, но и обслуживает функции динамического вызова процедур типа LoadLibrary() , GetModuleHandle() и прочии, от которых мы ожидаем получить дескрипторы модулей. Вот её прототип:

LdrLoadDll( PathToFile ;// путь (опционально); Flags ;// флаги (опционально); ModuleFileName ;// имя библиотеки; ModuleHandle ) ;// возвращаемый дескриптор.

Диалог этого загрузчика с вызываемой библиотекой происходит по схеме «запрос-ответ». Любая библиотека должна иметь упомянутую функцию взаимодействия с загрузчиком DllEntryPoint() , от которой в регистре EAX лоадер ждёт или TRUE (библиотека способна обработать запрос), или FALSE (что-то пошло не так). Не соблюдение этих правил приводит к краху приложения.

LdrLoadDLL() может извещать библиотеку о четырёх событиях, которые происходят во-внешнем (по отношению к библиотеке) мире. Эта информация передаётся точке-входа в DLL в параметре fdwReason . Кроме события, загрузчик сразу передаёт либе её базу в памяти, и способ подключения к исполняемому файлу. Прототип описывается так:

BOOL DllEntryPoint ( hinstDLL ;// виртуальная база данной библиотеки в памяти; fdwReason ;// причина вызова; lpvReserved ); ;// способ подключения: статический(0), или динамический(1). ;// ..(статический = явно, динамический = не явно) ;// Возможные значения «fdwReason» ;//——————————- • DLL_PROCESS_DETACH (0) – FreeLibrary() или DLL отключается от процесса, • DLL_PROCESS_ATTACH (1) – первое подключении DLL к процессу, при его запуске, • DLL_THREAD_ATTACH (2) — процесс создаёт новый поток, • DLL_THREAD_DETACH (3) — процесс завершает поток.

Из всей этой братии, нам интересен лишь аргумент DLL_PROCESS_ATTACH = 1 , благодаря которому статически присобачив библиотеку к нашему процессу, мы можем например, предварительно расшифровать основной код программы, обнаружить отладчик в фоне и т.д. Дело в том, что загрузчик проецирует DLL в пространство процесса задолго до точки-входа в программу, с которой начинают анализ все отладчики, а значит Оля пропустит этот этап между ног. Здесь уместно вспомнить про функции TLS-Callback , ..но поскольку загрузчик парсит импорт из библиотек вторым (а TLS аж десятым), то выигрыш тут на лицо.

DLL – промышленная реализация

Чтобы сформировать образ, приведём код типичной библиотеки. Пока она будет выводить на экран только сообщения об удачном подсоединению к родительскому процессу, а после его закрытия – покажет ещё одну мессагу, что мол родительский процесс отработал и отправляется на покой. Когда приложение вызывает библиотеку, в её стеке оказывается фрейм из трёх (не считая адреса-возврата) аргументов функции DllEntryPoint() , которые загрузчик кладёт туда на всеобщее обозрение – так это выглядит в отладчике:

Соответственно, мы можем снимать эти аргументы прямо со-стека, и сразу проверять их – код ниже придерживается именно такой политики:

Теперь у нас есть либа, и нужно написать родительское приложение, которое будет статически привязывать к себе эту библиотеку. Во-первых, обратим внимание на имя новоиспечённой DLL – здесь, в секции-экспорта я определил его как «about.dll», это важно! Теперь просто импортируем эту библиотеку по имени, и вызываем из неё функцию примерно так:

format pe console include ‘win32ax.inc’ entry start ;//—— .data frmt db ‘%s’,0 ;//—— .code start: cinvoke Hello ;// зовём функцию из about.dll . cinvoke scanf,frmt,frmt+2 ;// ждём клаву.. cinvoke exit,0 ;// Game Over! ;//—— section ‘.idata’ import data readable library msv,’msvcrt.dll’, about,’about.dll’ ;// указать точное имя DLL! import msv, scanf,’scanf’,exit,’exit’ import about, Hello,’Hello’

Тёмная сторона луны

Пробежавшись по макушкам кода библиотек, посмотрим на них из другой проекции..
Алгоритм работы загрузчика образов LDR плохо освещён в документации и это не удивительно – весь ядерный код мастдая, коммерческая тайна (будь она не ладна). Как это принято у Microsoft, она советует нам ознакомиться с третьей поправкой, восьмого исправления, четвёртой редакции от 32 февраля где сказано, что «..в военное время не только прямой угол может достигть 100 градусов, но и функция инициализации DllEntryPoint() может использоваться не по назначению». Самое главное: кто, где и когда объявляет это положение неизвестно, а значит мы вольны назначать его сами.

Мощь (и беспомощность) точки-входа в библиотеку в том, что некоторая часть театра действий происходит под управлением системных механизмов, отследить которые из прикладного уровня довольно сложно. В документации на РЕ-файл можно найти формат каталога секций «Data-Directories» . В этом дире рассчитавшись на первый-второй выстроены в ряд все секции, которые обходит загрузчик образов LdrLoadDll() при инициализации приложения. Причём последовательность секций строго регламентируется. Вот как выглядит эта структура в представлении редактора PE-Explorer:

Таким образом, импорт анализируется загрузчиком на самом начальном этапе, и большинство служебных структур прикладного уровня в этот момент даже не инициализированы ещё до конца – в частности, это относится к структуре PEB , не говоря уже о дочерней к ней структуре ТЕВ. Например, если мы внутри DllEntryPoint() захотим из РЕВ получить флаг-отладки нашего приложения «BeingDebugger» , то потерпим фиаско (проверено на практике). На скамейку запасных сразу отправляется и функция IsDebuggerPresent() , которая читает этот-же флаг из РЕВ. Значит нужно спускаться на уровень ниже, а для защитных механизмов это только гуд.

Если развивать мысль дальше, то наша библиотека не единственная у приложения. Кроме неё, в память каждого процесса система загружает и свои либы Ntdll.dll (собственно в ней и живёт загрузчик LDR), а так-же библиотеку kernel32.dll. С очерёдностью загрузки в память системных библиотек можно ознакомится в отладчике WinDbg, озадачив его командой !peb – поле InMemoryOrderModuleList как-раз отрапортует нам об этом:

Здесь видно, что первым десантируется в память мой исполняемый файл «DLL_attach.exe», следом за ним системные библиотеки, и только потом моя пользовательская либа «about.dll». Повторюсь, что система выстраивает структуру РЕВ только когда окончательно покончит с окружением процесса, скидывая в неё результаты проделанной работы. А лог на рисунке выше, WinDbg парсит уже из рабочего процесса, поэтому РЕВ как-бы готова к употреблению.

Библиотеки динамической линковки DLL

Библиотеки динамической линковки DLL, структура и использование DLL (англ. Dynamic-link library — динамически подключаемая библиотека) — понятие операционных систем Microsoft Windows и IBM OS/2; динамическая библиотека, позволяющая многократное применение различными программными приложениями. K DLL относятся также элементы управления ActiveX и драйверы.

В мире UNIX аналогичные функции выполняют т. н. shared objects («разделяемые объекты»). Понятие DLL Чем же отличаются Dynamic Link Library (DLL) от обычных приложений? Для понимания этого требуется уточнить понятия задачи (task), экземпляра (копии) приложения (instance) и модуля (module).

При запуске нескольких экземпляров одного приложения, Windows загружает в оперативную память только одну копию кода и ресурсов — модуль приложения, создавая несколько отдельных сегментов данных, стека и очереди сообщений (см. рис. 3), каждый набор которых представляет из себя задачу, в понимании Windows. Копия приложения представляет из себя контекст, в котором выполняется модуль приложения. Задача 1 Задача 2 Копия 1 приложения Копия 2 приложения Данные Данные Стек Стек