Загрузка виртуальной DLL из exe

Indy · **Добавлено:** Вс сен 25, 2011 3:32 am

pablov

Цитата:

Прошу в студию dll, которая не загрузится по моему способу

Так в том и дело, что у вас не загрузка, а простое проецирование, настройка импорта и фиксапов. Помимо этого в нтлдр есть есчо много всяких разных плюшек. GetModuleHandle() для вашего модуля не будет работать. Нотифи доставляться при создании тредов также не будет. Импорт бывает разный, также и модуль более сложный, чем пара директорий, например как же вы забыли про директорию конфигурации, где /safeseh :lol:

Цитата:

Что означает ручная настройка импорта?

Это ваша ImportProc(). Не ручная это когда нтлдр сам всё загружает.

pablov · **Добавлено:** Вс сен 25, 2011 1:50 pm

Ага, ага, но тем не менее работает :wink:

, в отличии от LoadLibraryM из PBOSL, которая половину dll не грузит.
Но в чем-то вы правы. Я не смог загрузить, ну или спроецировать библиотеку Cards.dll, т.к она вызывает функцию GetModuleFileNameA(...)
а та ворачивает нул, естественно инициализация не проходит:(

Indy писал(а):

как же вы забыли про директорию конфигурации, где /safeseh

Ткните пожалуйста носом, где эта директория

Indy · **Добавлено:** Вс сен 25, 2011 3:00 pm

pablov

Цитата:

Ткните пожалуйста носом, где эта директория

В вашем модуле её может и не быть. Но следует при загрузке все обрабатывать(а не только IMPORT и BASERELOC):

Код:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Directory Entries
 
#define IMAGE_DIRECTORY_ENTRY_EXPORT          0   // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT          1   // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE        2   // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY        4   // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC       5   // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG           6   // Debug Directory
//      IMAGE_DIRECTORY_ENTRY_COPYRIGHT       7   // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE    7   // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR       8   // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS             9   // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG    10   // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT   11   // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT            12   // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT   13   // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14   // COM Runtime descriptor

Модуль например может быть .NET, тогда DllMain там не используется, загрузчик вместо неё юзает CorExeMain(), загрузите mscoree.dll

. Из директории конфигурации берётся к примеру аффинитет потока. Есть специальные имена секций, которые загрузчик использует особым образом(.aspack etc.). При загрузке модуля он в разных структурах описывается, например вRtlpStkDllRanges, у вас функции типо RtlWalkFrameChain() работать не будут. Там подобных нюансов огромное число, посему нтлдр занимает большую часть ntdll.

Пётр · **Добавлено:** Вс сен 25, 2011 3:04 pm

Indy писал(а):

Модуль например может быть .NET

Разве их можно юзать как обычные DLL из native программы?
У меня чет не получалось.

pablov · **Добавлено:** Вс сен 25, 2011 3:38 pm

Indy
Я вообще-то не ставил задачу переписать штатный загрузчик винды, и уж тем более загрузку модулей на .NET платформе. То что получилось на выходе, думаю устроит 95% юзеров. Если есть идеи, давайте воплотим их в код и утрем нос буржуям.
К примеру на http://rsdn.ru/article/baseserv/peloader.xml#EDFAE мужик пишет: "Существует так называемый “новый стиль” привязки; в этом случае TimeDateStamp= -1, а таблица информации о привязках доступна через элемент IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT каталога каталога PEHeaders.OptionalHeader.DataDirectory."
Чета я тут начинаю мандражировать и тупеть
Нашел я dll где TimeDateStamp= -1, поправил свой код, но не уверен, будет ли он корректно работать с другими dll'ками. Хотя проверил, работает

Indy · **Добавлено:** Вс сен 25, 2011 3:54 pm

pablov

Цитата:

Если есть идеи, давайте воплотим их в код и утрем нос буржуям.

Я давно реализовал - трейсим нтлдр и эмулируем файловые секции. Лодер вместо файла на диске получает поток данных из нашей виртуальной проекции. В остальном загрузка происходит стандарным естественным путём. Это 100% совместимость с системой.

Пётр
Почему бы нет ?

Пётр · **Добавлено:** Вс сен 25, 2011 4:19 pm

Indy писал(а):

Почему бы нет ?

У них ведь нет экспортируемых функций, по крайней мере, с помощью GetProcAddress не получилось добраться до них.

pablov · **Добавлено:** Вс сен 25, 2011 4:31 pm

Indy писал(а):

Я давно реализовал

Indy код паапршу в студию, тока не на асме, ибо здесь форум PureBasic, а не Wasm.ru И давайте уже перейдем(те) на ТЫ. Мы общаемся на форуме, а не на светском рауте.
Вот я задал вопрос о "нововом стиле привязки" вы что-то молчите

Пётр писал(а):

У них ведь нет экспортируемых функций

У них есть экспортируемые функции (на то они и dll), тока там механизм экспорта другой

Indy · **Добавлено:** Вс сен 25, 2011 9:27 pm

pablov

Цитата:

код паапршу в студию, тока не на асме

Выше я дал код. Бинарь, хидеры, дамп и куча семплов. Только не нужно тут вспоминать кроссплатформенность - пе-формат виндовый. На линупсе fle etc. Я пишу только на масме. И только трояны, вирусы и драйвера. Остальное рассматриваю как ламерство(не в обиду сказано, просто моё мнение).

Цитата:

Wasm.ru

Аверлаб, да хороший был форум. У меня там тыщ 15%20 постов было :shock:

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

Пётр · **Добавлено:** Вс сен 25, 2011 9:32 pm

Indy писал(а):

Я пишу только на масме. И только трояны, вирусы и драйвера. Остальное рассматриваю как ламерство

Я конечно не придираюсь к словам, но при таком суждении, все что работает в режиме юзера (например, игры, разные там утилиты и т. д.) - ламерство. :shock:

pablov · **Добавлено:** Вс окт 02, 2011 8:26 pm

Indy писал(а):

В общем если хотите актуальную печеньку, то я дам

Давай. Я рассмотрю, сделаем как ты говоришь "печеньку", тока в PureBasic, приветствуются исходники на MASME тока с комментариями. И не надо тока заумных слов, Инди, все когда-то учились

Indy · **Добавлено:** Вс окт 02, 2011 10:10 pm

pablov
Значит давайте по порядку.
1. Нужна копия образа в памяти. Причём такая копия, что фиксапы(релоки) используются как в оригинальной проекции для секций данных. Например значение ссылки на переменную, для которой есть фиксап в обеих модулях одинаково. Способ загрузки выберите сами - опять же через нтлдр или вручную.
2. Релоцированный модуль не должен быть описан в лдр. Желательно вообще чтоб это была не файловая проекция.
3. Решаем что будем эмулировать. Выбор обширный, я юзал KnownDlls-секции. Можно файловые потоки эмулировать, или вообще функции проецирования. Определяем алго и находим приватные(Ldrp*) апи.
4. Патчим должным образом. Вся проекция наша, значит код наш и целостность модулей не нарушается. Дёргать загрузчик будем также из второй проекции.

pablov · **Добавлено:** Вс окт 02, 2011 11:12 pm

Хорошо,
по моему пункт #1 я выполнил, считаю что релокация(фискапы) (перестройка абсолютных адресов) выполнена
Импорт в dll я тоже исправляю корректно.
Да, я согласен, что GetModuleHandle(..) не будет работать для данной dll, и другие подобные функции не будут
Пункт №2 я вообще не понял
Так как я не понял предыдущие пункты (2) пока, здаюсь.
Инди, ну будь попроще

Indy писал(а):

Релоцированный модуль не должен быть описан в лдр. Желательно вообще чтоб это была не файловая проекция.

Что такое лдр? я конечно догадываюсь, но

Indy · **Добавлено:** Пн окт 03, 2011 6:39 am

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

Цитата:

Что такое лдр?

База данных нтлдр.

Volkoff · **Добавлено:** Пт фев 24, 2012 5:16 am

На правах "мыслей вслух".
Понадобилось переписать сабж под подгрузку в иной процесс, покопал в сторону штатных вариантов (переизобретать загрузчик, это кончно как "посадить дерево" там итп, но все же

)

Штатно мы имеем такую картину:
LdrLoadDll для загрузки либы цепляет ее файл NtCreateFile, делает секцию NtCreateSection, проецирует через NtMapViewOfSection, затем фиксапы, импорт итд, после чего происходит переход на DllEntryPoint.
Идея зацепиться на ранних стадиях обламывается в зародыше при NtCreateSection() без SEC_IMAGE.
Смотрел в сторону LdrProcessRelocationBlock, которая как раз и занимается релоками у проекции (LdrRelocateImage походу уже не юзается, по крайней мере у себя в ntdll.dll ее не нашел), "поплыл" где-то по пути на подготовительном этапе.

Вроде как раз Инди предлагал (известно где) способ с KnownDlls, но там движухи еще больше, нужно:

- создать секцию в \KnownDlls,
- спроецировать её в текущий процесс
- скопировать внедряемый образ модуля (+ выравнивание секций проекции на границу страницы)
- вызвать LoadLibrary с именем этой секции

В общем, на данный момент "велосипеды" актуальны, ибо едут.
Пока ламерские затыки в основных моментах, код пишется на одну страницу

вместо секция-сраница

хз насколько это принципиально, но трид не стартует по точке входа, несмотря на полное отсутствие системных варнингов да и каких-либо варнингов вообще.
Кусками код записывать и проставлять права не срастается, т.к. я по нубски "теряю адресацию" на моменте когда копирую хидер + остальные секции в выделенную пока еще в собственном процессе память и правлю релоки (ранее уже зарезервирована пямять в целевом процессе для расчета дельты).

Если вдруг кто захочет откомментировать мои размышления, сразу оговорюсь, излишне хитровыдуманные методы рассматривать смысла нет, не малвари пишем.
Отдельно для Инди, - неприкладной выброс "ядерной философии" не приветствуется, познавательные цели это хорошо, но тут треп не про "шашечки", а про "ехать", да и уровень не тот, сам видишь, вкуриваю азы

purebasic.info

Загрузка виртуальной DLL из exe

Кто сейчас на форуме