Proxy dll что это

Обновлено: 02.07.2024

Если для приложения выбрано маршалирование прокси-сервера или заглушки, то файлы c и h, созданные MIDL, должны быть скомпилированы и связаны для создания прокси-библиотеки DLL, и эта библиотека DLL должна быть введена в системный реестр, чтобы клиенты могли искать интерфейсы. Созданный с помощью MIDL файл DLLDATA. c содержит необходимые подпрограммы и другие сведения для создания и регистрации библиотеки DLL прокси-сервера или заглушки.

Первый шаг в создании библиотеки DLL заключается в написании файла определения модуля для компоновщика, как показано в следующем примере:

Кроме того, эти экспортированные функции можно указать в командной строке КОМПОНОВКИ файла makefile.

Экспортированные функции объявляются в RPCProxy. h, который включает DLLDATA. c, а реализации по умолчанию являются частью библиотеки времени выполнения RPC. COM использует эти функции для создания фабрики классов, выгрузки библиотек DLL (после того, как убедитесь, что объекты или блокировки отсутствуют), извлеките сведения о прокси-библиотеке и самостоятельно Зарегистрируйте и отмените регистрацию DLL-библиотеки прокси. Чтобы воспользоваться этими предопределенными функциями, необходимо вызвать параметр Кпрепроцессор/D (или-D) при компиляции файлов DLLDATA. c и example _ . c, как показано в следующем файле Makefile:

Если эти определения препроцессора не заданы во время компиляции, эти функции не определяются автоматически. (То есть макросы в папке RPCProxy. c расширяются на Nothing.) Их придется явно определить в другом исходном файле, модуль которого также будет включен в окончательную компоновку и компиляцию в командной строке компилятора C.

Когда _ определена библиотека регистрации прокси-сервера _ , RPCProxy. h предоставляет дополнительные элементы управления условной компиляцией с прокси-сервером _ CLSID =GUID, прокси-сервер _ CLSID _ — это явное значение идентификатора GUID и Строка префикса входа _ =префикс строки. Эти определения макросов более подробно описаны в определении языка C-компилятора для прокси-серверов и заглушек в документации программиста MIDL.

Если по каким-либо причинам вы не можете использовать подпрограммы регистрации заглушек прокси по умолчанию, можно зарегистрировать библиотеку DLL вручную, добавив следующие записи в системный реестр с помощью Regedt32.exe.

Понадобилось мне перехватывать вызовы GDS32.DLL. Решил написать прокси-dll.

Пишем исследовательский стенд

Первое, что нам нужно — это получить список всех экспортируемых функций из настоящей dll.
Сделаем это следующим кодом:

Здесь трудностей вроде нет. Добираемся последовательно до таблицы экспорта (строка 19) указателей на массив имен(NamesCursor) и массива номеров(OrdinalCursor) и читаем функцию за функцией, имена и номера. Количество функций находится в поле NumberOfNames. Этот код был добыт на просторах интернета, потом доработан и упрощён.

Рассмотрим нашу тестовую dll.

Здесь трудностей тоже вроде нет. Экспортируем две функции — сложения и вычитания.
список экспортируемых функций и номеров у нас будет такой:

myAdd=2
mySub=1
Листинг 3

Такие номера присвоил компилятор. Почему именно такие? Этого я не знаю.
Теперь сосредоточимся на функции сложения. Посмотрим в какой код откомпилировался её вызов, для этого вызовем её и посмотрим в отладчике.

Тут всё просто. Получаем адрес функции и вызываем её. Поясню лишь, что во втором параметре GetProcAddress указатель на имя функции, но это в том случае, если он больше $FFFF, если меньше или равен, то он воспринимается как номер функции в таблице экспорта. То есть мы можем вызвать функцию по номеру или по имени.

Теперь посмотрим как происходит занесение результата сложения в переменную, а именно работа строки 13.

1. TestCall.dpr.13: N:=myAdd(1,2);
2. push $02
3. push $01
4. call dword ptr [$0040cba4]
5. mov [$0040cbac],eax
Листинг 5

И тут всё просто, помещаем в стек, двойку(2) и единицу(3), вызываем нашу функцию (4), результат сложения помещен компилятором в регистр еах, и потом из регистра копируем результат в переменную N(5).

Вот он перед вами распространенный вызов функции из Dll. Аргументы помещаются в стек, делается call, и из регистров (или стека) считываются результаты.

Моя идея заключается в том, что когда вместо настоящей лежит моя фейковая dll, то сначала она перехватывает входы функции и имя функции, потом вызывает настоящую функцию и как будто бы ничего не было.

Пишем фейковую Dll.

Итак список функций и номеров у нас есть, но каждой экспортируемой функции должен соответствовать какой-то код. Какой. Вот ради этого всё и пишется. Те примеры, которые я видел на просторах интернета, в них полезный код для каждой перехватываемой функции клонируется, и причем еще надо знать параметры экспорта функции, чтобы вызвать настоящую с теми же самыми параметрами. Мне стало лень проводить такую кропотливую работу(по поиску описания всех функций GDS32 и дублирования на делфи) это раз. И все-таки клонировать полезный код — это «не наш метод». Идея в следующем — мы хотим, чтобы после вызова функции приложением отработал наш код. Раз код один и тот же ну вот и сделаем отдельную процедуру с полезным кодом — ProxyProc. А каждая фейковая процедура должна будет просто вызвать ProxyProc. Дальше прокси-процедура должна как-то узнать какая именно процедура вызвала её. После раздумий пришел к выводу, что идеальный вариант — это поместить в стек номер функции. Также нам надо сохранить состояние регистров и флагов, потому что они могут влиять на выполнение процедуры в настоящей DLL. Итого получаем на каждую экспортируемую функцию четыре строчки кода. И да, раз мы вмешиваемся в глубинные механизмы работы Windows, дабы быть уверенными чего и где мы запортили, писать будем на ассемблере.

1. pushfd //одно и то же для каждой функции
2. pushad //одно и то же для каждой функции
3. push 2 // меняется номер для каждой функции
4. call ProxyProc // одно и то же для каждой функции
Листинг 6

Реализуем идею

Тут всё просто. Экспортируем две фейковые процедуры, а имена и номера им даем такие же как в настоящей dll.
Дальше самая хитрая часть — это сама прокси-процедура. Из чего она должна состоять.

1. Выполнить какие-то полезные нам операции с номером функции и входными параметрами
2. Узнать адрес настоящей функции
3. Вернуть все регистры к исходному состоянию
4. Передать управление на адрес настоящей процедуры, как будто бы ничего не было.

Соответственно её код может быть следующим.

Теперь когда мы откомпилируем этот код, то получим «minilib2.dll'. Переименуем его на „minilib.dll“ и подменим, а „minilib.dll“ переименуем соответственно в „minilib_.dll“

Теперь посмотрим как это работает

TestCall.dpr.13: N:=myAdd(1,2);
1. push $02
2. push $01
3. call dword ptr [$0040cba4] // вызываем myAdd, но попадаем в фейк
4. mov [$0040cbac],eax
Листинг 9
В листинге 9 часть уже виденного кода, который вызывает функцию из Dll и в таблице ниже состояние стека и регистров после попадания в фейковую процедуру, то есть после вхождения в call на строке 3

EAX 00364434
EBX 7FFDA000
ECX 00000000
EDX 00000003
ESI 16A1F224
EDI 13D84260
EBP 0012FFC0
ESP 0012FFA4
EIP 00364434
EFL 00000246
Листинг 10
0012FFAC 00000002 // второй аргумент
0012FFA8 00000001 // первый аргумент
->0012FFA4 0040811A // адрес возврата в экзешник
Листинг 11

Дальше видим слева код нашей четырехстрочной фейковой процедуры и справа состояние стека после попадания в proxyproc, то есть после вхождения в call на строке 4

minilib2.myAdd: // она же fakeProc0002
1. pushfd
2. pushad
3. push $02
4. call $00364408 // вызываем proxyProc
Листинг 12
0012FFAC 00000002 // второй аргумент
0012FFA8 00000001 // первый аргумент
0012FFA4 0040811A // адрес возврата в экзешник
0012FFAO 00000346 // регистр флага
0012FF9C 00364434 // регистр ЕАХ
0012FF98 00000000 // регистр ЕСХ
0012FF94 00000003 // регистр EDX
0012FF90 7FFDA000 // регистр EBX
0012FF8C 0012FFAO // регистр ESP
0012FF88 0012FFC0 // регистр EBP
0012FF84 16A1F224 // регистр ESI
0012FF80 13D84260 // регистр EDI
0012FF7C 00000002 // номер функции (02)
->0012FF78 0036443D // адрес возврата в фейковую процедуру fakeProc0002
Листинг 13

Дальше видим слева код прокси-процедуры и справа состояние стека после получения адреса истинной процедуры после выполнения строки 6. Видим что из стека убран адрес возврата в фейковую процедуру fakeProc0002 и убран номер функции из стека, зато в стеке появился адрес настоящей функции.

minilib2.ProxyProc:
1. add esp,$04
2. push dword ptr [$0036782c]
3. call $00364394 // это LoadLibrary
4. push eax
5. call $00364384 // это GetProcAdress
6. mov [esp-$04],eax
7. popad
8. popfd
9. jmp dword ptr [esp-$28]
Листинг 14
0012FFAC 00000002 // второй аргумент
0012FFA8 00000001 // первый аргумент
0012FFA4 0040811A // адрес возврата в экзешник
0012FFAO 00000346 // регистр флага
0012FF9C 00364434 // регистр ЕАХ
0012FF98 00000000 // регистр ЕСХ
0012FF94 00000003 // регистр EDX
0012FF90 7FFDA000 // регистр EBX
0012FF8C 0012FFAO // регистр ESP
0012FF88 0012FFC0 // регистр EBP
0012FF84 16A1F224 // регистр ESI
->0012FF80 13D84260 // регистр EDI
0012FF7C 0037437C // адрес настоящей процедуры в настоящей dll
Листинг 15

Дальше видим в таблице слева состояние регистров и справа состояние стека перед jmp на истинную процедуру, то есть перед тем как выполнить строку 9 листинга 14. Как видим состояние стека и регистров идентично состоянию сразу после вхождению в фейковую процедуру(листинги 10 и 11), и надеемся истинная процедура DLL не почувствует разницы. (28 в шестнадцатеричной — это 40 в десятичной, то есть 10 раз по 4 байта это как раз то место в стеке, где у нас лежит адрес истинной процедуры (листинг 17)).

EAX 00364434
EBX 7FFDA000
ECX 00000000
EDX 00000003
ESI 16A1F224
EDI 13D84260
EBP 0012FFC0
ESP 0012FFA4
EIP 00364422
EFL 00000246
Листинг 16
0012FFAC 00000002 // второй аргумент
0012FFA8 00000001 // первый аргумент
->0012FFA4 0040811A // адрес возврата в экзешник
1. 0012FFAO 00000346 // регистр флага
2. 0012FF9C 00364434 // регистр ЕАХ
3. 0012FF98 00000000 // регистр ЕСХ
4. 0012FF94 00000003 // регистр EDX
5. 0012FF90 7FFDA000 // регистр EBX
6. 0012FF8C 0012FFAO // регистр ESP
7. 0012FF88 0012FFC0 // регистр EBP
8. 0012FF84 16A1F224 // регистр ESI
9. 0012FF80 13D84260 // регистр EDI
10. 0012FF7C 0037437C // адрес настоящей процедуры в настоящей dll
Листинг 17

И наконец процедура разработчика.

В этой процедуре уже не обязательно писать на ассемблере. Здесь мы собственно и можем сделать перехват, без вреда содержимому регистров и стека.

Например простым кодом, чтобы выводить в файл все номера вызываемых функций может быть такой.

На строке 7 в переменную _ebp занесли указатель базы
на строке 9 связали переменную F с файлом
на строке 10 открыли файл для добавления
На строке 11 записали текущие дату и время, и номер вызванной функции
К указателю базы мы должны прибавить три раза по 4 байта, потому что в стеке после номера функции лежат три указателя: 1. Указатель на возврат в фейковую процедуру, 2. Указатель на возврат в прокси-процедуру и 3. Помещенный компилятором указатель на стек(push ebp). Тип указателя PAnsiChar был выбран, потому что к нему допускаются операции сложения и вычитания с числами.
На строке 12 закрыли файл.


На сайте я скачал триальную версию и запросил для нее пробный ключ, который мне и прислали на имейл. Теперь можно начинать изучение программы и ее механизма регистрации.

Процесс

Программа устанавливается в директорию C:\Program Files (x86)\Deleaker как standalone, хотя есть вариант интеграции Deleaker в Visual Studio в виде дополнения (.vsix). Но я не пользуюсь Visual Studio, и для меня такой способ был недоступен.



В директорию были установлены такие файлы.



Запускаем программу и вводим присланный ключ. Софтина обещает нам пробный период использования.



Инструменты, которые нам понадобятся

  • x64dbg — отладчик;
  • DIE aka Detect It Easy — анализатор файлов;
  • CFF Explorer — PE-редактор;
  • MASM — компилятор.

Итак, проверив все исполняемые файлы анализатором DIE, в директории установленной программы находим две DLL’ки, «накрытые» VMProtect:

Я предположил, что механизм (код) лицензирования (регистрации) находится именно в них.

Зачем нужны две DLL’ки?

Забегу вперед: DLL’ки идентичны, единственное различие — одна 32-битная, другая 64-битная. Механизм лицензирования (регистрации) используется только из deleakersdk32.dll, что облегчает нашу задачу.

Далее я открыл deleakersdk32.dll в CFF Explorer и зашел в директорию Export. Там нашлись четыре экспортируемые функции с говорящими именами.



Эти функции как раз и отвечают за лицензирование (регистрацию) программы.

Но это не беда, мы просто запускаем Deleaker.exe и аттачимся к процессу x64dbg.

В окне Symbols отладчика, в левой половине находим и выделяем курсором нашу DLL. Справа мы увидим список ее импортируемых и экспортируемых функций. Нас интересуют только те, что мы обнаружили ранее в CFF Explorer. Выделяя по очереди курсором функции, нажимаем клавишу F2, тем самым устанавливая точки останова (breakpoints) на начало исполнения кода этих функций.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Разработка Readiris 15 компанией IRIS послужила толчком для создания последней версии файла proxy.dll. Он также известен как файл Dynamic Link Library (расширение DLL), который классифицируется как файл Win32 DLL (Библиотека динамической компоновки).

Впервые proxy.dll был представлен 10/24/2018 в составе AutoCAD 2019 для Windows 10. Самый последний выпуск для Readiris 15 состоялся 02/17/2015 [версия 15].




Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Сведения о разработчике и ПО
Программа: Readiris 15
Разработчик: IRIS
Программное обеспечение: Readiris
Версия ПО: 15
Сведения о файле
Точка входа: 0x1a09
Размер кода: 4096
Информация о файле Описание
Размер файла: 11 kB
Дата и время изменения файла: 2020:01:07 08:32:13+00:00
Тип файла: Win32 DLL
Тип MIME: application/octet-stream
Тип компьютера: Intel 386 or later, and compatibles
Метка времени: 2014:12:11 15:22:47+00:00
Тип PE: PE32
Версия компоновщика: 10.0
Размер кода: 4096
Размер инициализированных данных: 6144
Размер неинициализированных данных: 0
Точка входа: 0x1a09
Версия ОС: 5.1
Версия образа: 2.8
Версия подсистемы: 5.1
Подсистема: Windows GUI

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Ошибки библиотеки динамической компоновки proxy.dll

Файл proxy.dll считается разновидностью DLL-файла. DLL-файлы, такие как proxy.dll, по сути являются справочником, хранящим информацию и инструкции для исполняемых файлов (EXE-файлов), например MpSigStub.exe. Данные файлы были созданы для того, чтобы различные программы (например, Readiris) имели общий доступ к файлу proxy.dll для более эффективного распределения памяти, что в свою очередь способствует повышению быстродействия компьютера.

  • Нарушение прав доступа по адресу — proxy.dll.
  • Не удается найти proxy.dll.
  • Не удается найти C:\Program Files (x86)\Readiris Pro 15\proxy.dll.
  • Не удается зарегистрировать proxy.dll.
  • Не удается запустить Readiris. Отсутствует требуемый компонент: proxy.dll. Повторите установку Readiris.
  • Не удалось загрузить proxy.dll.
  • Не удалось запустить приложение, потому что не найден proxy.dll.
  • Файл proxy.dll отсутствует или поврежден.
  • Не удалось запустить это приложение, потому что не найден proxy.dll. Попробуйте переустановить программу, чтобы устранить эту проблему.

Файл proxy.dll может отсутствовать из-за случайного удаления, быть удаленным другой программой как общий файл (общий с Readiris) или быть удаленным в результате заражения вредоносным программным обеспечением. Кроме того, повреждение файла proxy.dll может быть вызвано отключением питания при загрузке Readiris, сбоем системы при загрузке proxy.dll, наличием плохих секторов на запоминающем устройстве (обычно это основной жесткий диск) или, как нередко бывает, заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.


Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Если на этапе 1 не удается устранить ошибку proxy.dll, перейдите к шагу 2 ниже.


Шаг 2. Если вы недавно установили приложение Readiris (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Readiris.

Чтобы удалить программное обеспечение Readiris, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

После полного удаления приложения следует перезагрузить ПК и заново установить Readiris.

Если на этапе 2 также не удается устранить ошибку proxy.dll, перейдите к шагу 3 ниже.


Шаг 3. Выполните обновление Windows.


Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла proxy.dll. Мы храним полную базу данных файлов proxy.dll со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Readiris . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

Windows 10: C:\Program Files (x86)\EagleGet\
Windows 10: C:\Program Files (x86)\Readiris Pro 15\
Windows 10: C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\9.2.2.2501\AdskLicensingAgent\

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

Читайте также: