ANTICHAT — форум по информационной безопасности, OSINT и технологиям

ничего там скопированого не было. все писал я.

2КЕЗ, да, вы телепат )

>>ничего там скопированого не было. все писал я.
я про код процесса, а не программы на C)

> не знаю, имхо код был просто скопирован

При инжекте у ТС с текущего процесса в адресное пространство другого по _одинаковым_ адресам копируется какой-либо код/+данные/+етц
иначе все слетело бы ещё задолго до вызова malloc()
о чем тут спорить можно ? : DDD

Почему, есть инструкция call, адресующая функцию относительно текущего EIP, она кстати и используется, данные все можно формировать на стеке, api функции подключать в ходе выполнения...

Не от EIP, а от своего месторасположения.

что тут написано и как это относится к бедному razzzar, которому уже все давно объяснили - я пока ещё не понял

есть большой кусок кода, сгенерированый компилятором, который при перемещении в другой процесс надо либо релочить, либо перемещать на тот же VA, где он и должен быть в процессе, либо записывать его VA-независимым, например, вместо call [addr] делать mov eax,[addr]\call eax.
тут, вроде как, неочем спорить больше.

"от своего месторасположения" это как? 0xE8 опкод инструкции вызова функции, адрес функции вычисляется как EIP + операнд.


Ну а почему именно такие варианты? Что мешает не использовать абсолютных адресов, формируя все данные на стеке (а глобальные переменные вынося в динамиечкую память, выделяемую уже в контексте "проинжектинного" процесса, подгружая все системные функции на лету и прыгая с функции на функцию 0xE8 call'ами (или вообще не прыгая, а делать все в __inline)

Это так, что можно вычислять как EIP+операнд в момент выполнения CALL, а можно - в общем случае - адрес инструкции CALL + её операнд. Так как заранее известно, каким будет EIP в момент выполнения инструкции (когда она где-то расположена в виртуальной памяти) - думаю, уж можно сказать, что адрес процедуры будет равен адресу инструкции CALL + её операнду. Да, процессору все равно что и где там расположено, но с точки зрения чисто-человеческой логики, можно сказать про адрес инструкции call, а не про EIP в момент её выполнения, который, по сути, является тем же самым. Ладно, ок, от EIP зависит - это правильно.

ну и?)) e8 call то должен быть расположен либо там, где и был, либо его надо корректировать. это и есть "использование абсолютных адресов"

Компилятор мешает. Я уже сказал, что можно использовать базонезависимый код - ты как раз и говоришь про такой. Который будет где угодно выполняться. Да, да, это формирование в стеке, глобальные данные в куче, может быть замена call mem на mov reg,mem\call reg и т.п. неудобства.
Как видно по первому посту в топике - компилятор c/cpp.
Вот он, к примеру, очень часто будет ставить свои __CRT_CheckESP и тому подобное.
И ещё много чего делать будет. Про __inline - без комментариев, это явно тут "ни приштопай ни пришей".
А так, если самому писать код - да без проблем, можно полно всего придумать.

Этого я так и не понял, почему? В непосредственном операнде стоит только смещение и ему глубоко фиолетово какой там EIP, если код весь копировать монолитно, что видимо является единственно-адекватным решением, все будет работать по любым адресам.

Кстати, чтобы call'ы имели такой вид, на сколько я понял, извращаться ненужно, я, например, смог получить call по абсолютному адресу только для 0xFF call'а при вызове функции через функциональную переменную (Borland C++), но что-то мне подсказывает что на MSVS тоже самое.

> Этого я так и не понял, почему?

А релоки в длл придумали просто так?
Проблема в том, что каким-то инструкциям нужна VA, а каким-то - смещение, относительно EIP. Поэтому - либо релочишь колы и джампы, либо mov'ы и все остальное.
Как у тебя CRT инициализируется с таким кодом:

?

где _osplatform == 0x42AF20

перенесешь код - будет уже совсем неправильный адрес.