(no subject)

[netp_npokon]

Словил вчера забавный эффект.

Я использую библиотеку mach_override, которая, как выяснилось, является самым надежным способом подменить системную функцию в Mac OS: она просто парсит начало функции, откусывает от нее нужное число инструкций и заменяет их на переход в пользовательскую функцию.

Эта штука хорошо работала нативно, но отказывалась подменять нужную мне функцию под gdb -- не могла распарсить байт 0xCC. При этом ни objdump, ни сам gdb такого байта в этой функции не видели, поэтому что-либо отладить представлялось невозможным.

Разгадка же оказалась простой: 0xCC -- это прерывание int3, которое gdb воткнул в функцию, чтобы по моей же просьбе поставить там breakpoint. И не признавался, справедливо полагая, что неча пользователю об этом знать.

Comments

[salnikov.livejournal.com]

gdb меняет бинарник исполняемого файла?

[netp-npokon.livejournal.com]

Если бы менял, то objdump бы как раз это заметил. Он меняет сегмент кода в памяти, причем при попытках прочитать из этого места средствами самого gdb (print, disassemble) возвращает старое значение.
Игорь хорошую ссылку подогнал.

[netp-npokon.livejournal.com]

Писать ничего не пишу, портируем помаленьку :)

[esyr.livejournal.com]

int3 это первый курс, емнип. Как давно это было.

[zero-sharp.livejournal.com]

Я на твоей лекции про валгринд про int3 рассказывал.

[netp-npokon.livejournal.com]

Я в курсе, да. Единственной новостью было то, что дебаггер не дает юзеру видеть этого прерывания, хотя программа его видит.

[akovalenko.livejournal.com]

(Наверное, очевидное, но...) проблема не в том, чтобы распарсить 0xCC, а в том, что на этом месте что-то лежало, и узнать что -- в общем случае невозможно (стало быть, и определить границу следующей инструкции -- тоже).

Правда, не знаю, какие у вас там прологи у системных функций -- если такие же однообразные, как в (каждой конкретной версии) ntdll.dll, оверрайдилку скорее всего можно научить не обижаться на gdb.

[netp-npokon.livejournal.com]

В данном случае на мысли о том, что что-то не так, меня натолкнуло именно то, что библиотека не смогла распарсить 0xCC. Там совсем плюшевый дизассемблер, буквально с десяток инструкций. Если бы смогла, то все было бы куда хуже -- уже из-за того, что следующая инструкция была бы испорчена.

Там для перехвата заменяются первые восемь байт функции, так что в общем случае помимо операций со стеком может попадаться всякий мусор, вплоть до инструкций jmp. При этом прологи различаются довольно сильно. Можно, конечно, замапить нужную библиотеку где-нибудь сбоку и сверяться с оригиналом, но это дороже, да и не к спеху.