Статья:
Загрузчик PE-файлов

Автор(ы): Максим М. Гумеров
Дата: 20.03.2003
Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

Авторы:
Максим М. Гумеров

Аннотация:
Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

Что конкретно автор собирался сделать? Зачем?
%%%
То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.
%%%

И что и в чем такая сложность?

%%%
Как сделать так, чтобы никто не заметил рядом с исполнимым файлом эту DLL? Ясно, что распространять ее вместе с файлом нельзя.
%%%

Распространять вместе с файлом нельзя? Это как? А вручную делать ее из ресурсов самого файла можно? Какой смысл, если все равно без нее работать приложение не будет?
Если для целей защиты от пиратства, так хороший хакер все равно найдет эту вашу ДЛЛ-ку под каким-нибудь отладчиком ядра и дизассемблирует ее прямо в памяти процесса.

Это больше похоже на умственную зарядку для души. Личное имхо.

#define QUOTE
Как сделать так, чтобы никто не заметил рядом с исполнимым файлом эту DLL? Ясно, что распространять ее вместе с файлом нельзя. Создание файла DLL из информации, хранимой в самом приложении (например, в виде ресурса) в %TEMP% или где-нибудь в GetTempXXX было признано решением, недостойным программиста.
#undef QUOTE

А с чего бы это? Использование недокументированных возможностей достойно?
Ни кто не мешает сделать темпоральный файл ТОЛЬКО С ОПИСАНИЕМ СЕКЦИЙ и на лету поместить в эти секции код, при этом все будет совершенно законно и точно по спецификации. А если уж использовать недокументируемые возможности то вполне можно было поместить модуль в список загруженных. Это двусвязный список, лежит он в PEB. Если интересно могу прислать код который это делает. НО надо помнить что это НЕ БУДЕТ работать в Win9x, в отличии от варианта с временным файлом.

Жалко, что на Паскале.

В чем-то Вы правы. Помимо прочего, это еще и зарядка. И анализ материала по PE-формату. И новая точка зрения на DLL — не "когда-она-уже-загружена", а наоборот.

И еще — так лучше понимаешь, как работает (или почему не работает ;) ) твоя DLL. Принципы загрузки лучше все же знать, чем не знать, согласны?

А вообще, данная работа имела вполне определенную практическую направленность. К сожалению, Вам я о ней прилюдно рассказать не могу.

>> И что и в чем такая сложность?
Если бы Вы знали, сколько раз я слышал эту фразу... Часто тянет ответить: что ж тогда на эту тему нет никакой цельной, законченной информации? Может, конечно, я сейчас препираюсь с гуру, которому и впрямь море по колено... Так, что ли?
Возможно, Вы просто не вчитались в контекст (см. дальше):

>>Распространять вместе с файлом нельзя? Это как?
См. предыдущую фразу статьи: нужно, чтобы DLL никто не заметил.

Очень полезная статья! Спасибо.
Солидарен на все 100% на счет Паскаля;-) Хотелось бы иметь этот загрузчик на С++. Жаль, что времени пока нет переписать самому...

Да понятно все с PEB. В другом дело (кстати, Вы верно заметили, что это будет несовместимо с 9x). Просто у меня там фактически лишь один undoc используется, да и тот, возможно, где-то все же описан — не все же, кто про него писали, сидели и дизассемблировали виндоус. А вообще — я принципиально против undoc'ов. Вот и все объяснение.

+++
Ни кто не мешает сделать темпоральный файл ТОЛЬКО С ОПИСАНИЕМ СЕКЦИЙ
+++
Ага. Давайте теперь, когда нужно из BLOB-поля вытащить doc-файл и внедренно его открыть, сохранять его в Temp, а потом грузить из файла. Так ведь и правда проще :)

А если серьезно — уж на что я плохо на C пишу, так и то могу перевести готовый код с C на Pascal... Думаю, и тебе будет не сложнее в обратную сторону перевести.

Тебе алгоритма недостаточно, чтобы его хоть на Перле написать, хоть на VB? Ценность статьи — в алгоритме, а не в коде. У меня другой вопрос — не удалось разобраться (хотя бы на уровне UNDOC), что именно мешает гетпросадрес загружать адреса функций?

Напишу параллельную линейку кода на C.
Только не прямо сегодня.

>Тебе алгоритма недостаточно
Не достаточно. Скажем так, алгоритм, в общих чертах, был известен давно по разрозненным источникам + голова... А вот времени на его реализацию, действительно, не было и не предвидется;-)
>Ценность статьи — в алгоритме
Не только! Еще и в том, что упомянутые источники были сведены вместе, систематизированы и критически проанализированы;-)

То же, что мешает и GetModuleHandle. То есть GetProcAddress, в отличие от функций работы с ресурсами, резет сверяться с PEBшными структурами системного загрузчика и очень удивляется тому, что он там обнаруживает. Точнее, чего он не обнаруживает :)
По совету Alexey Chen я скоро выложу новую версию, где для желающих добавлю фрагмент кода для обновления PEB.
Да и сейчас это не проблема — просто при настройке таблицы импорта можно вместо GetProcAddress вписать свою функцию-замену. Правда, все API так не наперехватываешься...

Здравствуйте, Максим М. Гумеров, Вы писали:

ММГ>Статья:
ММГ>Загрузчик PE-файлов

ММГ>Авторы:
ММГ> Максим М. Гумеров

ММГ>Аннотация:
ММГ>Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

Очень интересно, а главное понятно. Но одного я так и не разобрал:

Необходимо отметить следующий факт: RawDataSize может быть как меньше, так и больше VirtualSize (разумеется, возможно и равенство). Меньше бывает только в случае, когда секция содержит неинициализированные данные (т.е. такие, для которых в секции отводится место, но значения не загружаются из исходного файла, а устанавливаются равными 0).

Больше же может быть из-за того, что RawDataSize округляется вверх до ближайшего числа, кратного FileAlignment. Например, если размер секции 4090, а FileAlignment=512, и в секции нет неинициализированных данных, то VirtualSize=4090, тогда как RawDataSize=4096.

Поэтому при чтении инициализирующих секцию данных необходимо читать из исходного файла min(VirtualSize, RawDataSize) байт данных.

Почему?!
Поправьте меня, но насколько я правильно понял: VirtualSize — Размер данных в секции, до округления по верхней границе, SizeOfRawData — то же, но уже после округления, PointerToRawData — RVA для инициализирующих данных, VirtualAddress — RVA самой секции. Для неинициализированных данных отводится только место. Отводится оно в VirtualSize, затем округляется до SizeOfRawData. И как тогда SizeOfRawData может быть меньше VirtualSize?! Или SizeOfRawData это округление только инициализированных данных? И зачем нам тогда фактически 2 одинаковых адреса (VirtualAddress, PointerToRawData)? Есть еще мысль, что неиниц. данные располагаются сразу по VirtualAddress, а иниц. по PointerToRawData И SizeOfRawData -- округленные иниц данные. Только не кидайте в мануал, плиз, я там чуть-чуть запутался...


Ps. А если еще кто-то на С всю программу перевел -- слава ему и почет!

Извиняюсь, что поздно отвечаю — не увидел вопроса.

Поясняю.

Например, если размер секции 4090, а FileAlignment=512, и в секции нет неинициализированных данных, то VirtualSize=4090, тогда как RawDataSize=4096.

А если секция содержит, кроме того, еще и неинициализированные данные после этих инициализированных, то VirtualSize может быть хоть 111111 при том же RawDataSize, т.к. RawDataSize — это объем того, что вшито в PE-образ, т.е. в данном случае — округленный вверх объем инициализированной части секции. Вот вам как раз случай, когда RawDataSize<VirtualSize.

Понятно рассказал или только все запутал?

Slicer

Здравствуйте, Максим М. Гумеров,

Статья очень интересная, и с познавательной стороны и с практической (вот только если бы было не на Паскале

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

У меня к Вам вопрос. Будет ли вот такой псевдо-код работать?

{
HMODULE hLib =LoadLibrary ("hidden.dll") ;


// Делаем копию иимджа начиная с адреса hLib

// Останавливаем все потоки в процессе : SuspendThread() , чтобы кто-нибудь не занял виртуальную память

FreeLibrary(hLib) ;

DeleteFile ("hidden.dll") ;

// Выделяем память по адресу hLib в нужном кол-ве

memcopy ((void*) hLib , (void*) saved_image , sizeof(saved_image ) );

// Обратно запускаем все потоки: ResumeThread()


}

Идея следующая. Пусть штатный загрузчик сделает всю работу сам, затем мы сделаем копию памяти и выгрузим библиотеку — тогда уже никто не сможет "увидеть" с помощью ProcessBrowser или других spy что ваш процесс грузит такую то dll.
Потом снова выделяем память по тому же адресу и снова в нее пишем содержимое имиджа.
Чтобы какой-нибудь поток в промежутке между этими действами случайно не занял нужный нам кусочек памяти — останавливаем все потоки на короткое время.

Работоспособен ли данный метод или есть какие-то подводные камни?

Еще раз спасибо!

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>См. предыдущую фразу статьи: нужно, чтобы DLL никто не заметил.

Что значит никто? ... Детский сад, младшая группа.

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

Лучше стать автором чего полезного. Интереснее.
И денег больше в разы. Проверено.

Trust me.

Отвечаю с конца.

CS>Лучше стать автором чего полезного. Интереснее.
CS>И денег больше в разы. Проверено.
Стараюсь. Trust me. Но и исследованиями кто-то должен заниматься.

SW>>См. предыдущую фразу статьи: нужно, чтобы DLL никто не заметил.
CS>Что значит никто? ... Детский сад, младшая группа.
Кому как. Если знать, что искать — конечно, шансы найти большие. А если не знать? Насчет сигнатур — нет НИЧЕГО элементарнее, чем приделать криптование. После этого останется только уже в памяти искать. А вообще, у меня была конкретная задача, в детали вдаваться, само собой, не буду — и подход себя оправдал на 100%. И, судя по письмам, что приходят ко мне на ящик, такая надобность возникла не только у меня, и люди готовы юзать предложенную схему даже несмотря на все ограничения.

Slicer

Здравствуйте, Аноним, Вы писали:

А>Статья очень интересная, и с познавательной стороны и с практической (вот только если бы было не на Паскале
Ну извиняйте, с чем в основном работаю, на том и написал. Делал бы на C, багов было бы больше

А>Идея следующая. Пусть штатный загрузчик сделает всю работу сам, затем мы сделаем копию памяти и выгрузим библиотеку — тогда уже никто не сможет "увидеть" с помощью ProcessBrowser или других spy что ваш процесс грузит такую то dll.

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

Так что просто не вижу выигрыша. Да и самое главное — файл при этом появляется, хоть и ненадолго! А если у аккаунта, под которым запущена программа, нет прав писать в TEMP? (не знаю, бывает ли так, но теоретически, думаю, возможна ситуация, когда TEMP лежит на C, а C — R/O для всех, кроме админов).

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Далее, наша либа вполне может выгружать все используемые ею dllки.


Насколько я понимаю, при выгрузке нашей dll вызываются и FreeLibrary для связанных модулей. FreeLibrary decrements the reference count of the loaded dynamic-link library, т.е. это не значит что модуль сейчас же будет выгружен, просто на него уменьшится счетчик ссылок.

Кстати, сейчас парралельно возникла еще одна ветка :
http://www.rsdn.ru/Forum/Message.aspx?mid=506011&amp;only=1

Автор: c-smile
Дата: 14.01.04

что еще раз подтверждает "полезность" идеи. Это интересно как с точки зрения "защиты" своего кода, так и незаметного использования чужого.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Отвечаю с конца.

CS>>Лучше стать автором чего полезного. Интереснее.
CS>>И денег больше в разы. Проверено.
SM>Стараюсь. Trust me. Но и исследованиями кто-то должен заниматься.

SW>>>См. предыдущую фразу статьи: нужно, чтобы DLL никто не заметил.
CS>>Что значит никто? ... Детский сад, младшая группа.
SM>Кому как. Если знать, что искать — конечно, шансы найти большие. А если не знать? Насчет сигнатур — нет НИЧЕГО элементарнее, чем приделать криптование. После этого останется только уже в памяти искать. А вообще, у меня была конкретная задача, в детали вдаваться, само собой, не буду — и подход себя оправдал на 100%. И, судя по письмам, что приходят ко мне на ящик, такая надобность возникла не только у меня, и люди готовы юзать предложенную схему даже несмотря на все ограничения.

SM>Slicer

"Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL"

1) Сама концепция этой фразы этически не вяжется с духом RSDN (Это я уже модераторам свое ИМХО сообщаю)
2) Апликация испльзующая такой DLL embedding не для продаж за пределами России и Китая. Т.е. финансовый выход — ноль. Т.е. можно конечно сделать разовый проект для какого-нибудь заказчика в России. Но ему, этому заказчику, до фени вообще какие там DLL у тебя, верно? Тогда в чем сермяжность?

Т.е. практическая ценность исследований такого рода ассимптотически стремится к нулю.

Если же ты делаешь нечто на продажу, то гораздо(!) выгоднее и во времени и в нервах потратить 15-30 минут на следующее письмо авторам сокрываемой DLL примерно такого содержания:

Dear sir/madam.

Я собираюсь выпустить апликацию А в которой я бы хотел использовать Ваш компонент Б. Уж сильно он мне нравится бла-бла-бла....
К сожалению финансовые обстоятельства не позволяют мне в настоящее время оплатить....
Возможно ли...
И т.д.

Могу тебя заверить 99% авторов отнесутся с пониманием и станут тебя уважать заранее.
Причем сие уважение как бы качеством повыше чем "Слышь, пацан, ну ты крутой хакер".
Т.к. позволяет к тому же наладить партнерские отношения и пр. и пр.
Заодно чуть повысишь имидж российских разработчиков. Заодно заявишь серьезность намерений и пр.

Типа того. Это, кстати, из моего личного опыта.

Успехов в Пути.

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

Вот так. Оставляю вас гадать о том, для чего же я использовал этот подход. А статью написал просто в целях систематизировать отдельные знания о PE-формате и загрузке модулей, почерпнутые из различных источников.

Больше я в дискуссиях на тему этики и/или законности по данному сабжу не участвую. Я свое слово сказал — так все и было.

Slicer

Здравствуйте, c-smile, Вы писали:

CS>1) Сама концепция этой фразы этически не вяжется с духом RSDN (Это я уже модераторам свое ИМХО сообщаю)
Я знаю автора и знаю зачем он это использовал с пиратством это не связано.
Больше ни чего сказать не могу.

ЗЫ не забываем удалять избыточное цитирование.

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>А если серьезно — уж на что я плохо на C пишу, так и то могу перевести готовый код с C на Pascal... Думаю, и тебе будет не сложнее в обратную сторону перевести.

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

Подскажите пожалуйста, почему это работает только с ресурсов а например с потока не хочет? Вернее работает но Acceess Violation по выходу..

F := TMemoryStream.Create;
F.LoadFromFile('test.dll');
MyLibrary := xLoadLibrary(M.Memory, MyImports);
ExecMyProcedureFromDLL;
xFreeLibrary(MyLibrary);
F.Free;

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>Напишу параллельную линейку кода на C.
SW>Только не прямо сегодня.

А воз и ныне там... (с) Не помню кто!

Здравствуйте, sataron, Вы писали:

S>А воз и ныне там... (с) Не помню кто!

Крылов. Басня "Лебедь, рак и щука"

Здравствуйте, Максим М. Гумеров, Вы писали:

ММГ>Статья:
ММГ>Загрузчик PE-файлов

Автор(ы): Максим М. Гумеров
Дата: 20.03.2003
Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

ММГ>Авторы:
ММГ> Максим М. Гумеров

Хорошая статья.
После прочтения я задумался вот над чем: предоставляет ли предложенный метод загрузки возможность обойти такую фичу Windows XP/2003, как политика запрещения/разрешения запуска программ по хешу модулей. Если мы обходимся без LoadLibrary и GetProcAddress, то где еще винда может нас проверить? Может быть пора трубить об очередной дыре в безопасности Windows?

Здравствуйте, Максим М. Гумеров.
Статью прочел, может не внимательно, может не допонял чаво, но вот остался вопрос, а где всё-таки лежит двоичный код бибилиотеки, насколько я понял он лежит в ресурсах exe. Но в то же время в статье утверждается что хранить в ресурсах плохо.
Спасибо.

Здравствуйте, Максим.

Спасибо Вам, очень хорошая и полезная статья. Сейчас как раз разбираюсь и пробую перевести на Си. В финальной редакции XLoadLibrary Вы прибегли к xchg(a,b) путем a^b;b^a;a^b. Является ли это шагом осознанным (работает быстрее/выглядит нагляднее/другая причина) или так просто?

Спасибо за Ваш труд.

Сергей

//x-cipher ( at) mail ( dot) ru

Здравствуйте Максим.

Собственно сабж. Если эта штука равна 2 (как смещение имени в структуре IMAGE_IMPORT_BY_NAME), то почему об этом не упомянуто в статье?
Спасибо.

Сергей
//x-cipher ( at) mail ( dot) ru

Здравствуйте, Максим.

Вновь обращаюсь к Вам в надежде прочить ответ, на этот раз будучи зарегистрированным пользователем ресурса (вдруг это спасет ситуацию. Что такое PRVAs (похоже что массив указателей)? Я плохо понимаю в паскале — примерно как немец в английском — поэтому мне не допереть, как его правильно индексировать ( [i] ?= addr+i*4 ). На предыдущий вопрос ответ вроде бы нашелся.
Спасибо!

Сергей

//x-cipher ( at) mail ( dot) ru

XC>Вновь обращаюсь к Вам в надежде прочить ответ

Пардон, нужно читать "в надежде получить ответ"

Здравствуйте, X-Cipher, Вы писали:

XC> Что такое PRVAs (похоже что массив указателей)?

Ответы на практически все вопросы по PE формату есть в официальном документе от MS. На родном языке можно почитать туторы HardWisdom или перевод Iczelion'а (последние всегда лежали на wasm.ru, но что-то сейчас с сайтом, смотрите кеш гугла).

По Вашему вопросу в них много лишнего, но ознакомиться с ними очень полезно.

Здравствуйте, gear nuke, Вы писали:

[]

Спасибо!

Здравствуйте, Максим М. Гумеров, Вы писали:

ММГ>Статья:
ММГ>Загрузчик PE-файлов

Автор(ы): Максим М. Гумеров
Дата: 20.03.2003
Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

ММГ>Авторы:
ММГ> Максим М. Гумеров

ММГ>Аннотация:
ММГ>Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.


Обновленная версия спецификации.
Microsoft Portable Executable and Common Object File Format Specification
Updated: May 21, 2006
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

С некоторой натяжкой, на базе этого можно написать на С++. Пример загрузчика есть здесь (src/utils.hxx load_image) + здесь немного (хоть и не совсем по теме).

Здравствуйте, Максим М. Гумеров, Вы писали:

ММГ>Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

Извините, возможно я чего-то недопёр, но что мешало использовать для этих целей WinAPI LoadLibrary/GetProcAddress/FreeLibrary (пример "Using Run-Time Dynamic Linking" в MSDN)? Почему нужен был именно свой загрузчик?

Здравствуйте, Максим М. Гумеров, Вы писали:

ММГ>Статья:
ММГ>Загрузчик PE-файлов

Автор(ы): Максим М. Гумеров
Дата: 20.03.2003
Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.

ММГ>Авторы:
ММГ> Максим М. Гумеров

ММГ>Аннотация:
ММГ>Не вдаваясь в подробности, скажу лишь, что исследование было начато ради сокрытия использования программой на Delphi некоей DLL (написанной на VC++). То есть оператор видит один только Exe-файл, запускает его, а тот каким-то образом подключает функции, содержащиеся изначально (при компиляции проекта) в некоторой DLL.



А есть ли у кого нибудь готовый простой пример на Delphi?

Здравствуйте, Time, Вы писали:

T>Здравствуйте, Максим М. Гумеров.
T> Статью прочел, может не внимательно, может не допонял чаво, но вот остался вопрос, а где всё-таки лежит двоичный код бибилиотеки, насколько я понял он лежит в ресурсах exe. Но в то же время в статье утверждается что хранить в ресурсах плохо.
T> Спасибо.
навскидку — некогда перечитывать — вероятно, я имел в виду, что хранить в ресурсе И потом извлекать на диск и грузить — плохо. А в статье предлагается грузить напрямую в память, минуя создание дискового файла.

Slicer

А>Спасибо Вам, очень хорошая и полезная статья. Сейчас как раз разбираюсь и пробую перевести на Си. В финальной редакции XLoadLibrary Вы прибегли к xchg(a,b) путем a^b;b^a;a^b. Является ли это шагом осознанным (работает быстрее/выглядит нагляднее/другая причина) или так просто?

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

Slicer

Господа, я под впечатлением =)

http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_20974729.html

Меня перевели на C++ Жаль только, авторство не указали. RSDN такие вещи запрещает или нет? Просто интересно

Slicer

Здравствуйте, nzeemin, Вы писали:

N>Извините, возможно я чего-то недопёр, но что мешало использовать для этих целей WinAPI LoadLibrary/GetProcAddress/FreeLibrary (пример "Using Run-Time Dynamic Linking" в MSDN)? Почему нужен был именно свой загрузчик?

Ну, они вроде как из файла грузят. Перечитайте начало статьи.

Здравствуйте, sataron, Вы писали:

S>Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>>Напишу параллельную линейку кода на C.
SW>>Только не прямо сегодня.

S>А воз и ныне там... (с) Не помню кто!

См. мой сегодняшний коммент. Умельцы уже постарались, осталось приаттачить к статье =)

Здравствуйте, Alexey Chen, Вы писали:

AC>#define QUOTE
AC>Как сделать так, чтобы никто не заметил рядом с исполнимым файлом эту DLL? Ясно, что распространять ее вместе с файлом нельзя. Создание файла DLL из информации, хранимой в самом приложении (например, в виде ресурса) в %TEMP% или где-нибудь в GetTempXXX было признано решением, недостойным программиста.
AC>#undef QUOTE

AC>А с чего бы это? Использование недокументированных возможностей достойно?
А вообще, во многих ситуациях я бы согласился — ничего страшного в этом нет. Но обойтись без временного файла — всяко ведь более красивое решение, хотя бы с исследовательской точки зрения. Вот и получилось такое исследование.

Здравствуйте, X-Cipher, Вы писали:
XC>>Вновь обращаюсь к Вам в надежде прочить ответ
XC>Пардон, нужно читать "в надежде получить ответ"

На самом деле, я извиняюсь — доставка уведомлений о новых постах на РСДН у меня уже лет 6 как не работает. Бог знает, почему. Написали бы сразу на почту, указана ведь...

По этой же теме, но в другой ветке вопрос

Автор: explorus
Дата: 26.08.09

с загрузкой Win32 PE (exe) из памяти. Не могу одолеть Гляньте кому не лень, плиз...