Привет, есть небольшой вопрос по поводу использования Trap Flag в целях трассировки кода своим же кодом (через отлов #DB с помощью VEH, SEH). Как быть во время перехода в long mode? (Wow64Transition, Heaven's Gate, however) Я просто теряю управление, если продолжаю выставлять TF в обработчике исключений, где-то после jmp far 33:... валится. Может кто имел подобный опыт? К слову, под отладчиком все хендлится как я и ожидал, после возврата с гейта код продолжает получать управление, под обычным запуском валится.
Два режима, 32 подчиненный. Соответственно обрабатывать нужно в 64. Когда происходит переключение контекста, а это касается любых переключений, оно должно выполняться атомарно, во время загрузки окружения(настройка контекста соотв режиму) не должно быть никаких переключений. Если работа с кодом эмулятора(32 режим совместимости), тогда переключения контекста требуют специальной обработки. Перед прямым переключением режима(far 33) трассировка прекращается и начинается вновь после возврата из сервиса и обратных вызовов(исключения, gui, apc). Что бы получить управление при возврате из сервисов заменяется адрес возврата; так как возможны рекурсивные вызовы, используется стек адресов возврата. Отладчик это сам все делает.
Ahimov, Девствительно. Глянул сорцы x64bdg, тут перед переключением режима идет установка BP на адрес возврата. Надо ток такой код с мультипотоком подружить Можно еще сам отладчик детектить https://github.com/x64dbg/x64dbg/blob/development/src/dbg/debugger.cpp#L3079
shanya0xff Если кодовую память можно изменять, тогда лучше ветвление записать, что бы лишних исключений небыло. А для чего свое трассировать ?
shanya0xff Интересно на каком принципе строится защита, трассировка кода ведь дает лишь последовательность инструкций. Занять отладочный механизм, такое наврядле чем то поможет - отладчик отпустит исключение в зависимости от исходного состояния cpu.TF Эффективным может быть профилирование(замер относительных интервалов времени).
