Какова задача в общем?

хочешь сказать, что ret был сгенерирован до твоего кода?

Создать (относительно большой) базонезависимый код для запуска его в адресном пр-ве другого процесса, куда его сперва нужно будет скопировать.

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

может я что-то не так понял?






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

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


Самое интересное другое - ведь получается же такая штука в приведенном мною примере с back orifice 2k. Там тот же VC++ используется. Опции компилятора изучал, переносил в свою программу - не помогло.





Это сообщение отредактировал(а) nadge - 3.1.2008, 22:05

развей мои сомнения - приведи небольшой кусок из твоего "базонезависимого кода".

Не только. А если это не cdecl функция?  99% она на retn будет заканчиваться.

Added: точнее, если stdcall, по крайней мере.


Просто у функции нет параметров 

Добавлено @ 00:40

Угу. Да и большинство компилеров. Но (!) в дебаге будет сгенерена табличка стабов вида jmp <функция> - они и будут вызываться кругом. Нафига это не помню - но где-то когда-то читал разъяснение.


И плох сомнительностью своей работы  Впрочем всё-таки отталкиваться ИМХО лучше от него, но учитывать его потенциальную нестабильность  Так чё насчёт релиза?

Это сообщение отредактировал(а) Любитель - 4.1.2008, 01:15

Про нестабильность - это точно.

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

Пока не могу сказать, что проблема решена - надо еще потестировать. Но вроде все ОК. 


Всмысле, собрать как релиз? Само по себе это не помогло. Хотя щас все так собираю, для отладки пользуюсь софтайсом.

И не должно... Просто с дебагом по идее вообще не прокатит, из-за этих стабов для функций.

Актуально сейчас или нет, но изложу ещё один вариант. Он будет несколько корректнее в плане того, чтобы перенести весь необходимый код.
Целевые функции стоит выделить в отдельную секцию (используя #pragma code_seg либо #pragma section).
Чтобы это счатье выдрать -  чуть больше работы нужно будет, чем в уже приводившихся способах, зато надёжней. Просто напросто нужно пробежаться по PE-заголовку образа в памяти и получить адрес и размер секции. Её и копируем в нужный процесс. Относительное расположение в ней элементов можно найти разностью адреса функции в нашем процессе и уже вычисленного адреса секции.