Загрузка DLL по адресу в памяти.

← →
Oleg_D (2003-01-16 02:59) [0]

Как можно динамически загрузить библиотечный файл, из памяти по её адресу.

← →
Digitman (2003-01-16 08:45) [1]

С использованием станд.сист.загрузчика - никак. Сист.загрузчик полностью контролирует все этапы загрузки и инициализации PE-модуля, и параметры загрузки недоступны для изменения на уровне прикладного процесса.

← →
Oleg_D (2003-01-17 01:01) [2]

Хочу уточнить вопрос.

Библиотечный файл с расширением *.DLL открываю с помощью FileOpen(), создаю объект- проецируемый файл с помощью CreateFileMapping() и проецирую объект в адресное с помощью MapViewOfFile(). А дальше требуется динамически загрузить этот файл имея указатель на область памяти, в которую спроецирован этот файл, чтобы воспользоваться ей методами?

← →
Alex Konshin (2003-01-17 02:44) [3]

А наоборот никак? Сначала загрузить, а если уж нужен файл маппиниг, то можно достать тот, что система уже создала через Native API.
У dll есть любимая область загрузки, если эта область свободна в твоей виртуальной памяти, то dll будет замаплена в эту область, если же нет, то будет выделена другая область, но тогда уж dll не будет шарится.
Может объяснишь чего намудрить хочешь?

Просьба: в следующий раз сразу задавай уточненный вопрос. Оригинального вопроса я лично не понял.

← →
Digitman (2003-01-17 08:40) [4]

Если ты имеешь ввиду нечто вроде LoadLibrary(), которая вместо штатного параметра - пути к файлу получает параметр-адрес в ВАП процесса (т.е. вирт.адрес, по которому в ВАП твоего процесса уже лежит считанный тобой образ файла), то - никак.

← →
Oleg_D (2003-01-17 19:45) [5]

Мне собственно нужно уберечь файл от дизассемблирования.
Поэтому на диске я его собрался хранить в закодированном виде, а перед использованием соответственно нужно раскодировать. Как это сделать, не помещая обратно на диск?

← →
paul_shmakov (2003-01-18 04:48) [6]

посмотрите как это делают пакеры (например, upx - он доступен в исходниках). именно это вам и нужно. на диске все храниться зашифрованным, а расшифровывается при загрузке.

← →
Oleg_D (2003-01-21 15:37) [7]

У меня тут возникло небольшое продолжение вопроса, что если библиотечный файл промэппировать в память с помощью CreateFileMapping(), после этого к нему можно получить доступ через LoadLibrary(). И какие флаги надо задать в CreateFileMapping().

← →
Digitman (2003-01-21 15:57) [8]

> промэппировать в память с помощью CreateFileMapping(), после
> этого к нему можно получить доступ через LoadLibrary()

С чего это ты так уверен ?

← →
Oleg_D (2003-01-21 18:21) [9]

Я неуверен, я просто пытаюсь найти способ изменить файл перед загрузкой, не записывая эти изменения на диск. Если кто-нибудь знает где можно найти пример на Паскале, подскажите.

← →
Digitman (2003-01-22 08:22) [10]

> файл перед загрузкой, не записывая эти изменения на диск

А зачем перед загрузкой-то ? Ну загрузил выполнил ты LoadLibrary(), получил хэндл, этот хэндл есть базовый адрес загруженного модуля в ВАП процесса, изменяй права доступа на нужные страницы ВАП (распределенные системой под модуль) и правь их прямо в вирт.памяти сколько угодно ! И ничего записывать в файл не нужно)

← →
Phil (2003-01-22 11:01) [11]

2 Alex Konshin
>> У dll есть любимая область загрузки, если эта область
>>свободна в твоей виртуальной памяти, то dll будет замаплена в >>эту область, если же нет, то будет выделена другая область, >>но тогда уж dll не будет шарится.

В NT - будет.

← →
Игорь Шевченко (2003-01-22 12:23) [12]

Phil (22.01.03 11:01)

> В NT - будет.

Каким образом, DLL загруженная не по предпочтительному базовому адресу будет разделяемой в NT ?
У нее после такой загрузки будут модифицированы страницы кода, она будет спроецирована на SWAP-файл и т.д.

← →
Oleg_D (2003-01-22 12:28) [13]

Я думал об этом.
Загружал библиотеку с помощью
HLib:=LoadLibraryEx(" .dll",0, LOAD_LIBRARY_AS_DATAFILE);
Чтобы не запускать её.
А определить адрес библиотеки в памяти не получается, как это можно сделать?

← →
Игорь Шевченко (2003-01-22 12:29) [14]

> HLib:=LoadLibraryEx(" .dll",0, LOAD_LIBRARY_AS_DATAFILE);
> Чтобы не запускать её.
> А определить адрес библиотеки в памяти не получается, как
> это можно сделать?

HLib - это ее стартовый адрес :-)

← →
Oleg_D (2003-01-22 12:39) [15]

Я знаю что это не адрес, но каким образом его определить?

← →
Digitman (2003-01-22 12:39) [16]

> Игорь Шевченко

Игорь, ну не путай человека)

> Oleg_D

> Загружал библиотеку с помощью
> HLib:=LoadLibraryEx(" .dll",0, LOAD_LIBRARY_AS_DATAFILE);
> Чтобы не запускать её.
> А определить адрес библиотеки в памяти не получается, как
> это можно сделать?

HLib = вбсолютный базовый адрес загруженного образа PE-модуля в ВАП процесса

LOAD_LIBRARY_AS_DATAFILE
If this value is given, the function does a simple mapping of the file into the address space. Nothing is done relative to executing or preparing to execute the code in the mapped file. The function loads the module as if it were a data file. You can use the module handle that the function returns in this case with the Win32 functions that operate on resources. Use this flag when you want to load a DLL in order to extract messages or resources from it, and have no intention of executing its code.If this value is not given, the function maps the file into the address space in the manner that is normal for an executable module. The behavior of the function is then identical to that of LoadLibrary in this regard.

Как ты собираешься передавать управление ф-циям этого модуля в результате загрузки с этой опцией ? Кроме как отображение на ВАП процесса никаких "подготовительных" действий с образом библиотеки в памяти LoadLibraryEx() не сделает !

← →
Oleg_D (2003-01-22 12:49) [17]

Я считаю что получив этот адрес можно провести модификацию её в памяти (Расшифровать),
а затем запустить её например с помощью LoadLibrary() при этом не будет же она грузиться снова,
а просто получит ссылку на первую загруженную библиотеку.

← →
Mystic (2003-01-22 13:10) [18]

Можно не кодировать, а написать Dll на Vb с опцией "компилировать в P-код".

← →
Digitman (2003-01-22 13:16) [19]

что значит "расшифровать" ?

каким образом предполагаемая тобой собственная логика шифрации/дешифрации соотносится, например, с форматами станд.секций PE-модуля ? без наличия которых в момент загрузки LoadLibrary() попросту вернет крит.отказ в загрузке модуля ?

каким образом ты собираешься после дешифрации корректировать размер образа в памяти (так чтобы это было корректно для всех сист.механизмов) ?

как и каким образом ты собираешься после дешифрации выполнять fixup references, обрабатывать relocation table и самостоятельно реализовать пр. и пр. обязательные действия над PE-модулем, предусмотренные для обычных случаев сист.механизмом загрузки, в случае если загрузка была выполнена тобой явно с опцией LOAD_LIBRARY_AS_DATAFILE (т.е. сист.загрузчик загрузил образ в ВАП и более ничего не сделал из вышеперечисленного ) ?

Ты вообще представляешь себе хотя бы в общих чертах, что происходит с образом PE-модуля при станд.загрузке и станд.инициализации ?

← →
Oleg_D (2003-01-24 18:47) [20]

>HLib - это ее стартовый адрес

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

← →
[NIKEL] (2003-01-24 22:48) [21]

я так и не понял о чем речь идет :)

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

← →
R4D][ (2003-01-26 11:35) [22]

А почему бы просто не запихать твою dll куда-нибудь в %SYSTEM%, да еще и назвать ее как-нибудь типа GD132.dll(вместо I- 1). На практике от этого половину взломщиков, как ветром сдует. Если этого мало, то можно при загрузке извлекать библиотеку из своего исполняемого фаила, а при выключение удалять ее из %SYSTEM%. Тогда взломщик не сможет диссасемблировать ее, т.к она будет занята твоим процессом. От этого спасает только RESET, да диссасемблирование твоего исполняемого фаила и последующего поиска там кода библиотеки, что предпологалось и при твоем варианте.

← →
Digitman (2003-01-26 12:43) [23]

см. VirtualProtect()

Загрузка DLL по адресу в памяти. Найти похожие ветки