Собственно хоется, чтоб кинули в меня тутором или лучше линком на сорцы. Собственно проблема -Нужно "препарировать" image в памяти для запуска оного. Т.е. допустим из ресурсов засунуть непрепарированный образ в память, и там с ним сделать то, что делает LoadLibrary при загрузке. Нечто подобное делают всякие exe-пакеры. Может кто поделиться инфой по теме?

Нечто подобное делают только два известных мне ехе-пакера: ASProtect и Armadillo
Сложного ничего нэт - виделяешь памяти размером в ImageSize, копируешь туда заголовок и секции по VirtualAddress из заголовков. настраиваешь релоки, потом импорт и вызываешь точку входа - сбсно все.

а всякие UPX - разве такого не делает?
я понимаю что собсно и все - просто хотелось бы посмотреть чужой код , поменять что не устраивает и у себя заюзать т.к. самому это писать не особо улыбается. Помнится у меня на асме поиск+патчинье импортов занял порядка двух дней.

> Нечто подобное делают только два известных мне ехе-пакера: ASProtect и Armadillo

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

rst
Погоди, тебе что именно нужно?
1. Загрузить образ?
2. Настроить ТБЛ импорта?
Так кстати посмотри справку по LoadLibrary
Правда это только для NT но там есть флаг в параметрах позволяющий ТОЛЬКО загрузить ДЛЛ и ничего больше.
И потом в Win32 есть функции ImageXX
Может это тебе надо?

ImageHelp функции я смотрел - там такого нет. там можно только полазить по импортам, но это все ( может плохо смотрел ).
мне нужно :
1)разместить _НЕ_ПРЕПАРИРОВАННУЮ_ дллку или exe-шник в адрессном пространстве процесса.
2) сделать после этого все, что делаеть LoadLibrary после отображения :
- настроить релоки.
- настроить импорты
- подгрузить то, что нужно.
3) LoadLibraryEx - я смотрел - максимум что можно сделать - загрузить dllку без препарации - т.е. без настройки релоков и импортов. а мне нужно как раз наоборот - настройка релоков и импортов без загрузки дллки ( её я сам загружу ) .
4) как пример можно рассматривать нечто вроде такого: запуск двух разных exe-файлов внутри одного процесса как разных потоков.

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

я скажу по поводу последствий следующее:
1) ресурсы ( те которые LoadResource и UpdateResource )
2) FreeLibrary + WriteFile
3) Статические объекты.
4) Два вызова DllMain.
дальше можно додумать -)
как это решается:
1) Делается хук LoadLibraryEx и там проверяется.
Armadillo или ASProtect может быть так делают, но AFAIK всякие UPX - где кстати по-моему есть работа с таблицей импорта, не сжимают DLLки.. может быть я не прав.

если они (ASProtect и Armadillo) будут грузить таким макаром мои длл-ки и настраивать для меня таблицу импорта, то где гарантия того, что я в программе не вызову LoadLibrary для этой же длл-ки?

В догонку: можно вообще-то юзать LoadLibrary без проблем для этой затеи:
алгортим:
1) Загрузил нужные dll-ки через LoadLibrary
2) Пофиксил импорты в exe-шнике .
3) Вопрос: где здесь обход системы? - нет его-) Проблем с LoadLibrary потом не будет.

а нахрена вообще так извращаться с длл-кой?
такой подход дает всего лишь то, что длл будет загружена не в верхнюю память системой, а куда-то в другое место самой программой.
С точки зрения снятия защитного конверта, я думаю, дополнительных проблем это не составит, или я не прав?
Зачем это делает аспротект?

1) Загрузил нужные dll-ки через LoadLibrary
2) Пофиксил импорты в exe-шнике .
3) Вопрос: где здесь обход системы? - нет его-) Проблем с LoadLibrary потом не будет.

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

именно так протекторы и работают. а вот зачем грузить длл в пользовательскую память и какие плюсы это дает непонятно.
Повторяюсь ещё раз:
а) см пример выше - по поводу 2-х exe в одном процессе.
б) загрузить DLL не из файловой системы, а из ресурсов к примеру.
в) динамическая компоновка программы:
т.е. нужно то-то - взял вытащил из себя кусок кода, приготовил, заюзал, убрал - и все без мусора в ФС.

Ну блин, или я не понял первый аопрос, или вы не поняли мой второй ответ :)

1) Те длл что изает твоя прога протекторы грузят с помошью обычной LoadLibrary() и настраивают в соответствии импорт. Кхе, на самом деле протекторы делеют фэйковую таблицу импорта в которую кладуд вызовы всех нужных твое проге и протектору длл (просто импортят по одной функции из каждой либы а потом юзают GetModuleHandle когде будут настраивать импорт хосту) - это надо потому штаа в dll LoadLibrary не всегда работает - в DllMain() мелкомягкие запретили вызывать эту функцию, дабы загрузчику не снесло башню, если ты будешь грузить сам себя, ну кароче кто хотел тот понял =)
2) Грузить вручную длл (из ресурсов) описанным мной способом МОЖНО, и ничего не случится если ты потом загрузишь вторую копию с диска - будет у тебя два одинаковых модуля в процесся и ничего более. Проблем только в том что загруженная ручками длл не зарегистрирована в системе и не может использовать функций никаких функций со своим hInstance - GetProcAddress/LoadResource etc. применительно к ней будут просто ругаться. Это похоже никак не лечится. http://www.uinc.ru/scripts/load.cgi?files/dr.golova/TFakeDll.zip
3) UPX не использует такую технику по причение малости своего загрузчика (распаковщика) - его не сложно написать на position-independed асме. Большие протекторы (ASProtect/Armadillo) используют такую технику по нескольким причинам - 1. Добавляется еще один слой защиты - больше патчить кракеру; 2.Прокты крупные, и писать (а тем более отлаживать) их на асме крайне не удобно, а при таком подходе на асме пишется только маленький первичный загрузцик который распакует и запустит эту dll, а вся остальная логика защиты пишется на чем-нить более удобном (c++/delphi/etc) и кладется в эту dll - дешево и сердито.

"2) Грузить вручную длл (из ресурсов) описанным мной способом МОЖНО, и ничего не случится если ты потом загрузишь вторую копию с диска - будет у тебя два одинаковых модуля в процесся и ничего более. Проблем только в том что загруженная ручками длл не зарегистрирована в системе и не может использовать функций никаких функций со своим hInstance - GetProcAddress/LoadResource etc"
Так ли это? - ИМХО ( по-моему копался в функциях работы с ресурсами ) - там полностью User-Space и никакого обращения к внутренностям системы нет. Да и всякие hInstance - они обычно просто поинтеры. Правда меня в этом плане смущает то, что когда-то давным давно я пытался "обманывать" систему при работе с ресурсами - т.е. в заголовке PE менял адреса секции ресурсов - нихрена не получилось. Все-таки похоже что при считывании образа в память система че-то с ним да делает и последующие изменения образа уже не приводят к желаемым результатам.