Блог

Команда windbg tct выполняет программу до тех пор, пока она не достигнет call инструкции или ret инструкции. Мне интересно, как отладчик реализует эту функциональность под капотом.

Я мог бы представить, что отладчик сканирует инструкции из текущих инструкций для следующего call или ret и устанавливает соответствующие точки останова в найденных инструкциях. Однако я думаю, что это маловероятно, потому что он также должен был бы учитывать jmp инструкции, чтобы было произвольное количество возможных call или ret инструкций, в которых необходимо было бы установить такую точку останова.

С другой стороны, мне интересно, предоставляет ли процессор x86/x64 функциональность, которая вызывает исключение, которое отладчик будет перехватывать всякий раз, когда процессор собирается обработать call ret инструкцию или. Тем не менее, я не слышал о такой функциональности.

Я бы предположил, что это повторяется несколько раз, пока следующая инструкция не будет вызовом или повторением, вместо того, чтобы пытаться выяснить, где установить точку останова. (Что в общем случае может быть так же сложно, как решить проблему остановки.)

Возможно, это можно оптимизировать, сканируя вперед по «прямолинейному» коду и устанавливая точку останова в следующей jmp / jcc / loop или другой инструкции по передаче управления (например xabort ), а также улавливая сигналы/исключения, которые могут передавать управление обработчику SEH.

Я также не знаю о какой-либо поддержке HW для взлома определенного типа инструкций или кода операции: отладочные регистры x86 DR0..7 позволяют аппаратным точкам останова по адресам кода без перезаписи машинного кода int3 , а также аппаратным точкам наблюдения (для отслеживания загрузки/хранения данных по определенному адресу или диапазону адресов). Но не фильтрация по коду операции.