Перенаправление DLL с помощью деклараций

Question

Перенаправление DLL с помощью деклараций

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

У меня есть тестовое приложение, LoadDll.exe, который просто звонит

LoadLibrary("C:\\EmptyDll.dll");

LoadDll.exe имеет декларацию (как отдельный файл, LoadDll.exe.manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
  version="1.0.0.1"
  processorArchitecture="x86"
  name="LoadDll"
  type="win32"
/>
<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="EmptyDll"
      version="1.0.0.1"
      processorArchitecture="x86"
    />
  </dependentAssembly>
</dependency>
</assembly>

Папка приложения, содержащая LoadDll.exe (НЕ c:\), содержит EmptyDll.dll со встроенной декларацией.

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<assemblyIdentity
      type="win32"
      name="EmptyDll"
   version="1.0.0.1"
      processorArchitecture="x86"
    />    
</assembly>

Однако LoadDll.exe идет вперед и загружает C:\EmptyDll.dll а не EmptyDll.dll в папке приложения.

Если Вы повреждаете любую декларацию (например, изменяете номер версии в идентификационных данных декларации EmptyDll.dll), LoadDll.exe не загружается, таким образом, файлы манифеста читаются и обрабатываются окнами, но просто игнорируются.

Кто-либо получил какие-либо идеи?

Спасибо!

Toby

18

c++ windows dll manifest

задан WearyMonkey 20 January 2010 в 11:30

3 ответа

Другие вопросы по тегам:

c++ windows dll manifest

Похожие вопросы:

score 8 · Answer 1

Хорошо, вам нужно настроить это так:

C: \ apppath \ testapp.exe - Ваши тестовые приложения EXE-файл
C: \ apppath \ testapp.exe.manifest - - потенциально встроенный файл манифеста приложения
C: \ apppath \ joolassm \ roughsassm.manifest - манифест, описывающий вашу новую сборку.
C: \ apppath \ joolassm \ project.dll - монтажная dll
c: \ apppath \ joolassm \ project.dll.2.manifest - встроенный манифест в DLL

Итак, у вас есть ваше испытательное приложение, которое содержит манифест приложений: который содержит зависимые ссылки на angifics для приложения, включая один, который вы добавляете в настраиваемую сборку DLL.

В папке приложений Subsm Subplater в папке приложения у вас есть монтажный манифест сборки «offoreassm», который содержит файловый узел, ссылающийся на фактическую dll, "just.dll".

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

Это важный момент: монтаж «монтажные» монтаж «OpdowAssm», а «пустые» DLL проявляются потенциально отличаются. Файл манифеста («OpdowaSSM») файл сборки не должен быть встроенным, но может поделиться названием DLL-манифеста, если вы выберете назвать свой манифест по имени DLL.

Теперь, когда загрузчик загружает ваш EXE, он загружает манифест вашего EXE и добавляет его к контексту активации. Когда таблица импорта EXE обрабатывается, или вы вызываете LoadLibrary, сначала загрузчик ищет контекст активации для монтажа манифеста с соответствующим узлом файла. Если он найдет соответствующую сборку, то он обработает и загружает DLL из местоположения сборки (папка, содержащая сборки .manifest), и это может, в это время, если в DLL и DLL нет встроенного манифеста. То же самое имя, повторно используйте тот же файл Mainest для настройки контекста активации DLL.

Если вы хотите поставить «OpdowaSSM» Mainest и DLL, в другой папке в папку приложения, и если вы нацеливаете Windows Server 2008 или Windows 7 или позже, вы можете добавить файл конфигурации для вашего Приложение: -

C: \ apppath \ testapp.exe.config - файл конфигурации приложения

файл конфигурации приложения

файл конфигурации приложения может содержать зондирующий узел под узлом узла (файлы конфигурации выглядят Лот, как файлы манифеста), с PrivatePath = «какой-то относительный путь» . В этом случае относительная папка будет искать сборки.

Мой последний ответ здесь имеет пример файлов, охватывающих процесс создания сборки из DLL, и ссылается на него с EXE: - Путь для загрузки DLL из центрального хранилища

просто чтобы уточнить: Устройство Win32 - это простейший) файл манифеста, описывающий сборку и DLL. Они всегда в этой модели, расположенные в той же папке, поэтому файловый узел манифеста не может содержать информацию о пути вообще - только имя DLL.

Сборки могут быть переданы - давая им сильную версию (и некоторую цифровую подпись) и установить их в Windows \ Winsxs или в частном порядке.

Версии Windows до 5.1 (WIN XP) не будут искать сборки вообще, так как эта технология была добавлена только в XP. Windows 5.1 Thru 6.0 (XP и Vista) будут искать только частные сборки в папке объекта с помощью активного контекста активации: - если EXE ссылается на сборку, затем папка, содержащая EXE. Если код в DLL ссылается на сборку, затем поиск папки DLL.

Если вы хотите сохранить свою DLL в частном месте, разделяете несколько приложений (например), вы должны иметь требование Windows 7 или более поздней версии: -

Windows версии 6.1 (в противном случае известен как Windows Server 2008 или Windows 7) А позже будет дополнительно к папке модуля, поиск пути, указанного в качестве элемента PervicePath из зондирующего элемента в файле конфигурации приложения. Файлы конфигурации приложений всегда входят в той же папке, что и EXE или DLL, а имеются:

.exe.config или .dll.2.config

( Причина для .2. Есть ли потенциально много манифестов и конфиектов, встроенных в качестве ресурсов, и идентификатор ресурсов погрузчика ресурсов 1 ... 15. При поиске диска для манифеста файла Config, если идентификатор ресурса встроенного Ресурс был бы 1, идентификатор пропускается, но любой другой номер означает, что он становится частью имени файла).

score 20 · Answer 2

Так кажется невозможным перенаправить призывы к LoadLibrary с абсолютными путями с использованием манифеста.

После многих игр с проявлениями, кажется, что, как только вы попадаете, все плохие документации, манифесты на самом деле тупо просто.

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

'name attribute of file element' -> 'absolute path of manifest file' + 'name attribute of file element'

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

Итак, если мое приложение C: \ Foo \ foo.exe имеет зависимость к манифесту в C: \ Foo \ baa \ baa.manifest, а baa.manifest содержит файловый элемент <имя файла = "пустой .dll "/> , то контекст активации будет отображаться: « your.dll »->" C: \ foo \ baa \ project.dll "

так что любые вызовы LoadLibrary («your.dll») будет перенаправлена в LoadLibrary («C: \ Foo \ baa \ project.dll») .

Тем не менее, LODLIBRARY («C: \ urnpath \ project.dll») не будет перенаправлена!

Теперь, чтобы доказать свою точку зрения насколько тупо простыми файлами манифеста и контекстами активации являются. Если файл элемент baa.manifest был <имя файла = "C: \ retraPath \ project.dll" /> , и вы сделали LOBSLIBRARY («C: \ urnpath \ projects.dll» ) Вызов, вызов LoadLibrary будет перенаправлен на протяженность LoadLibrary («C: \ Foo \ Baa \ C: \ ruitpath \ bught.dll») , да, неработающий путь ...

Файловый элемент имеет неспокойный атрибут, называемый «LoadFrom», который делает то, что звучит так, и кажется, что он идеален, чтобы решить эту проблему. Использование LoadSrom, я смог перенаправить абсолютный путь на неотъемлемой вызовах, но, казалось, в странных способах прикрутите другие зависимости. Если кто-то знает больше о том, как работает «LoadFrom», я был бы очень заинтересован.

Так как я решил свою проблему в конце? Используя невероятно тяжелый подход DLL Trojaning, описанный на этическом хакере . По сути, вы создаете Dummy Kernel32.dll, которые перенаправляют все вызовы на оригинал KENERLL32.DLL, за исключением неполных вызовов, в которых вы помещаете собственную логику перенаправления. Затем в приложениях Mainest вы размещаете файловый элемент, который перенаправляет Kernel32.dll к вашему манекену. Веселье.

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

score 0 · Answer 3

Вы можете обойти это, используя Detours , обернув LoadLibrary . Ваша оболочка LoadLibrary сможет распознавать попытки загрузить вашу DLL и соответствующим образом переписывать путь.