Доброе время суток!

Кусок программы (тестовый пока):



Далее в одной из функций пишу:


И в dwCodeSize получаю очень большое (явно неверное) значение. Идея взята (практически дословно) из BO2k, там прекрасно работает. Уже час бьюсь, так и не разобрался.

Где ошибка?

З.Ы. Подозреваю, что где-то в опциях компиляции, но никак не могу понять, где именно. Оптимизации вроде все по отключал. Среда: VS 2005.


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

nadge, 
с чего ты взял, что код функций располагается последовательно?

MAKCim, я видел работающий пример, идентичный моему - http://www.bo2k.com/, файл исходника называется process_hop.cpp. (Здесь код не привожу т.к. все полностью как у меня.)


ОК, переформулирую вопрос иначе. Что нужно сделать, чтобы код располагался последовательно?

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

Ни чё нельзя!!!

Единственное верное решение: использовать дизассемблер длин машинных инструкций:



Проект в аттаче.



Присоединённый файл ( Кол-во скачиваний: 10 )
 getfunclen.rar 4,79 Kb

Это невозможно сделать в рамках стандартных компиляторов. 

Это сообщение отредактировал(а) W4FhLF - 3.1.2008, 08:37

Относительно верное  В результате оптимизации в функции может быть несколько инструкций ret.

Damarus, верно, поэтому перед использованием всё-таки надо пихнуть программу в дизассемблер  

не знаю как в PE
но элемент таблицы символов ELF файла может содержать размер символа (функции)
при обычных настройках компилятора/компоновщика эта информация генерируется
в процессе работы программы ее можно получить
кроме того, почему нельзя сделать так

Кстати, ты наверное компилировал в debug? Попробуй в release. 

Ещё можно так:

W4FhLF, 
забыл учесть размер leave (или ручного аналога)

MAKCim, в моём случае его небыло.

Ну, в вышеприведенном BO2k как-то же сделали?


И так и так, хотя release не особо тщательно проверял. Перепроверю.


Кстати, хороший вариант. 

Только в моем случае довольно неудобный, т.к. функций таких будет штук 30, если не больше. 

Знаю только, что VS _обычно_ не меняет порядок, но даже если порядок не меняется между процедурами может идти мусор, так что этот способ не рулит. 




Но разве удобней пихать туеву кучу пустышек вместо этого? 

Note: Зачем нужна "angy_StartOfHappyCode"? Можно сразу брать &HappyCode.

Предполагалось написать примерно так:


Т.е. весь код должен быть вместе, а не каждая ф-ция по-отдельности. В таком случае пустышки весьма удобны хотя бы для наглядности.

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

хочешь сказать, что 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-заголовку образа в памяти и получить адрес и размер секции. Её и копируем в нужный процесс. Относительное расположение в ней элементов можно найти разностью адреса функции в нашем процессе и уже вычисленного адреса секции.