Встретил только что вот такую штуку:

push    dword ptr [edi]
mov     byte ptr [edi], 0C3h
call    edi
pop     dword ptr [edi]

, и теперь не могу понять, что эта штука делает. Точнее, умом-то я понимаю, что не должна она ничего делать, но всё равно сомневаюсь.

Могут ли быть случаи, когда такой код нельзя "безболезненно" игнорировать? Один такой случай я представляю (исключение при доступе к [edi]), здесь дело точно не в этом. В чем еще может быть смысл такого кода, кроме простых попыток (кстати, успешных) заморочить голову?

Этот код не только записывает в [ESP-4] содержимое [EDI], еще и в [ESP-8] адрес инструкции POP
Возможно еще, что исключение при доступе к [EDI] будет при execute, а не при записи.

[S_T_A_S_: еще и в [ESP-8] адрес инструкции POP]

Дык он записывает адрес POP c помощью call edi, а по адресу в edi ставит ret 0, коим этот адрес сразу со стека и снимает, так что смысла я не вижу в этом.... хммм... или чего-то непонял :)))

Никак RET его не снимает. Число записано в память, там и остается. Пока не записать туда другое число.
Возможно, вызывается обработчик исключения, и ему передается [EDI] как параметр. Который там еще и изменится.

Хотя тут сложно что-то без контекста утверждать.

Это вовсе не "патч самого себя" - это весьма стандартная попытка "обмануть" generic трейсеры/дамперы - если edi указывает в первую секцию PE файла, то не умный трейсер может подумать что это вызов OEP и попытаться снять и реконструировать дамп (который будет в этот момент естесно мертвым)
Конкретно описанная конструкция характрена для AS и компании. Учите мат часть кароче, и не забивате себе мозги размышлениями о том какие адреса сохраняет этот вызов - это фуфло и провокация :)

S_T_A_S_
Никакие обработчики исключения не установлены, никакие отладочные регистры не используются, и так далее, и так далее...

Dr.Golova
Насчет AS - ты знал, ты знал! Вот только указывает edi не в первую секцию файла, да и вообще не в секцию файла - а в выделенный (и частично заполненный кодом) буфер. Хотя... пожалуй, и тут ты прав - смещение внутри буфера равно 0x1000 :)

Насчет фуфла и провокации - это понятно. А вот зачем такая провокация нужна - большое спасибо за разъяснения.

Насчет матчасти - можно уточнить, о чем идет речь? А то я тут как пещерный человек, все по старинке, в лоб... уже 11 скриптов для иды написал :) И, если верить моей интуиции, их еще как минимум штук 30 написать придется :(

P.S. Получается, что ни о каком конвеере речи даже не идет. Если бы конвеер заранее загружал команду по адресу edi, то все это дело падало бы очень громко :)

P.P.S. Однако, с выходом SP2 для XP всем пользователям AS несладко придется - это же придется обновить версию протектора, потом перепаковать свои продукты, потом раздать их честным обиженным клиентам... ;-D

Касательно SP2 - я думаю очень многие протекторы так работают, как SP2 просто не позволит работать. Тот же самый lm и прочая и прочая. Ох чуствую будет большая буря... А многие софтверные гиганты - к примеру Quest, DiscussData и NetIQ используют эти протекторы. Так что мелкософту, если все будет так как там написано придется несладко.

RobinFood

Мои коментарии относились не к конкретному применению этого кода,
а к этому:

понимаю, что не должна она ничего делать

Т.е. я просто хотел сказать, что код меняет 8 байт в памяти.
То, что это фуфло и провокация - другое дело :)


и о каком конвеере речи даже не идет

Да. Хотя процессоры могут выполнять команды out of order, здесь выполняют сначала MOV, а потом CALL.
Поскольку есть зависимость - результат выполнения 2й команды зависит от первой.

S_T_A_S_
А! Наконец-то до меня дошло, о чем ты. Этот код меняет 8 байт на стеке :)

Ну, в данном случае это не страшно. Да и я уже очень давно не видел (если вообще видел когда-либо) извращений с использованием "неиспользуемых" участков стека, т.е. кода наподобие

sub esp, 0x100
push eax
add esp, 0x104
mov ebx, [esp-0x104]

Это хорошо, что не страшно :)
Просто в последнем примере DWORD заносится явно, а в первом - один явно, а второй нет.

ЗЫ
А как давно я таких вещей не видел :( Так и хочется порой что-нибудь "поисследовать"