netp_npokon: (Default)
netp_npokon ([personal profile] netp_npokon) wrote2011-07-15 09:42 am

(no subject)

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

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

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

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

[identity profile] salnikov.livejournal.com 2011-07-15 10:21 am (UTC)(link)
gdb меняет бинарник исполняемого файла?

[identity profile] netp-npokon.livejournal.com 2011-07-15 01:29 pm (UTC)(link)
Если бы менял, то objdump бы как раз это заметил. Он меняет сегмент кода в памяти, причем при попытках прочитать из этого места средствами самого gdb (print, disassemble) возвращает старое значение.
Игорь хорошую ссылку подогнал.
(deleted comment)

[identity profile] netp-npokon.livejournal.com 2011-07-15 01:31 pm (UTC)(link)
Писать ничего не пишу, портируем помаленьку :)

[identity profile] esyr.livejournal.com 2011-07-15 07:59 pm (UTC)(link)
int3 это первый курс, емнип. Как давно это было.

[identity profile] zero-sharp.livejournal.com 2011-07-15 08:37 pm (UTC)(link)
Я на твоей лекции про валгринд про int3 рассказывал.

[identity profile] netp-npokon.livejournal.com 2011-07-16 07:37 pm (UTC)(link)
Я в курсе, да. Единственной новостью было то, что дебаггер не дает юзеру видеть этого прерывания, хотя программа его видит.

[identity profile] akovalenko.livejournal.com 2011-07-18 04:27 am (UTC)(link)
(Наверное, очевидное, но...) проблема не в том, чтобы распарсить 0xCC, а в том, что на этом месте что-то лежало, и узнать что -- в общем случае невозможно (стало быть, и определить границу следующей инструкции -- тоже).

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

[identity profile] netp-npokon.livejournal.com 2011-07-18 03:37 pm (UTC)(link)
В данном случае на мысли о том, что что-то не так, меня натолкнуло именно то, что библиотека не смогла распарсить 0xCC. Там совсем плюшевый дизассемблер, буквально с десяток инструкций. Если бы смогла, то все было бы куда хуже -- уже из-за того, что следующая инструкция была бы испорчена.

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