Выполнение системных функций в удалённом процессе

l_inc

Е8 - локальный вызов (near), ессно здесь не подойдёт
9A - far вызов
15FF - то что надо, но указывать надо не прямо на адрес функции, а на указатель содержащий адрес функции

Интересно, а кто же корректно завершит поток с указанием нужного значения выхода, которое ждёт удалённый процесс внедряющий шелкод?
Twister

Rel
Спасибо, полезный хэдер, доп. его некоторыми опкодами и только в путь

 

d2k9

Ещё и "естесственно"? Что в Вашем понимании "локальный"? Это обычный вызов. Только на байт (а с учётом указателя на все пять) меньше, чем FF 15.

Если бы Вы потрудились взглянуть на код, приведенный в посте 20, то стало бы ясно, кто его корректно завершит (на верхушке стека потока, созданного через Win32 API, в момент получения управления пользовательским кодом лежит адрес, ведущий практически прямо в RtlExitUserThread).

 

d2k9
P.S.

Боюсь, Вы слегка ошиблись при цитировании.

 

Twister

1. Да уж, критично:

Если можно сделать 6A 00, или есчо меньше для того кода через xor Reg32,Reg32/Push Reg32.
Можно задать смещение прямо в инструкции, при этом никакие опкоды затрагивать не нужно.
2. Это не шелкод, он ничего не переполняет. Это даже пикодом назвать нельзя. Это вручную компилируемый код.

 

l_inc
Ессно это переиначенная цитата - вы должны были понять намёк
И не надо перевирать - предложено было юзать E8 с адресом типа DWORD являющимся не относительным, а абсолютным.
Чтобы довести до вашего сознания: берёте записываете тот шелкод и вместо WORD call=15FFh делаете BYTE call=E8h. Убедитесь сами и доложите о результате.

 

d2k9

Очень смешно. Уверен, Вы и сами не верите в то, что написали.

Естественно намёк я понял. Было бы логично, если бы Вы также и поняли ответ. Похоже, я Вас переоценил.

Что перевирать? Где предложено? Цитату в студию.

Мда... Ваш последний шанс осознать свою глупость:
http://www.wasm.ru/forum/viewtopic.php?pid=347352#p347352
(E9 для jmp near аналогичен E8 для call near)
После этого "умных" предложений больше не будет. Чужую глупость я переношу вполне спокойно, но вот в сочетании с завышенным ЧСВ получается непробиваемая гремучая смесь.

 

используй вместо ebp другой регистр , плюс pushad/popad никто не отменял

 

Допустим так можно накидать тело шелкода - но ведь его ещё надо и в процесс записать удалённый. Ну тут можно вынести в отдельную declspec naked ф-цию и передавать на неё указатель для записи, но опять же получается надо писать дизасм движок для определения размера кода ф-ции для её копирования в удал. процесс - а ето гемор. Опять же можно посчитать вручную размеры опкодов, но чем это будет отличаться от выше приведённого кода? Тем, что это фиксированно и видонеизменяемо в процесса исполнения программы хоста, ничего ты уже не изменишь там, увеличивается размер кода (мы всё должны доставать сами), увеличивается гемор - так к чему же это?)

 

d2k9
Тогда в чём вопрос ?
Скачивайте два интеловских мана по опкодам и вперёд. А дизасм может быть нужен длин, для енума инструкций последовательно, полный нужен для создания графа. Вобщем не понятно в чём проблема.

 

Clerk
например нужно в удал процессе выполнить Sleep(2000);
будет проще динамически составить шеллкод, узнать в своем процессе адрес Sleep и заполнить простую структуру, чем писать шеллкод в котром будет поиск kernel32 поиск функции по хэшу и др извращения...если я правильно понял

 

karabas_barabas
Для этого не нужно описывать инструкции. А база этого модуля фиксирована для младших версий системы, в более поздных, таких как W7 может применяться ASLR/релокация, поэтому локально в удалённом процессе её искать придётся.

 

В рамках текущей сессии базовые адреса мапа всех системных либ во всех процессах одинаковы.

 

есть такое понятие - универсальность... но если код делать наотъебись, то канеш и такой вариант пойдет... что сложного то? находим базу, прочитав пеб целевого процесса... далее находим смещение функции в своем процессе относительно базы, прибавляем смещение к базе в целевом процессе, хардкодим... по-моему гораздо проще, чем вызывать GetProcAdress, и размер кода будет меньше...