Если бы менял, то objdump бы как раз это заметил. Он меняет сегмент кода в памяти, причем при попытках прочитать из этого места средствами самого gdb (print, disassemble) возвращает старое значение. Игорь хорошую ссылку подогнал.
(Наверное, очевидное, но...) проблема не в том, чтобы распарсить 0xCC, а в том, что на этом месте что-то лежало, и узнать что -- в общем случае невозможно (стало быть, и определить границу следующей инструкции -- тоже).
Правда, не знаю, какие у вас там прологи у системных функций -- если такие же однообразные, как в (каждой конкретной версии) ntdll.dll, оверрайдилку скорее всего можно научить не обижаться на gdb.
В данном случае на мысли о том, что что-то не так, меня натолкнуло именно то, что библиотека не смогла распарсить 0xCC. Там совсем плюшевый дизассемблер, буквально с десяток инструкций. Если бы смогла, то все было бы куда хуже -- уже из-за того, что следующая инструкция была бы испорчена.
Там для перехвата заменяются первые восемь байт функции, так что в общем случае помимо операций со стеком может попадаться всякий мусор, вплоть до инструкций jmp. При этом прологи различаются довольно сильно. Можно, конечно, замапить нужную библиотеку где-нибудь сбоку и сверяться с оригиналом, но это дороже, да и не к спеху.
Comments 7
Reply
Игорь хорошую ссылку подогнал.
Reply
(The comment has been removed)
Reply
Reply
(The comment has been removed)
Reply
Правда, не знаю, какие у вас там прологи у системных функций -- если такие же однообразные, как в (каждой конкретной версии) ntdll.dll, оверрайдилку скорее всего можно научить не обижаться на gdb.
Reply
Там для перехвата заменяются первые восемь байт функции, так что в общем случае помимо операций со стеком может попадаться всякий мусор, вплоть до инструкций jmp. При этом прологи различаются довольно сильно. Можно, конечно, замапить нужную библиотеку где-нибудь сбоку и сверяться с оригиналом, но это дороже, да и не к спеху.
Reply
Leave a comment