Re: 5 байт самомодификации

From

Gennady Mayko ()

To

Vladimir Ivanov

Date

2002-10-22T14:49:31Z

Area

SU.WINDOWS.NT.PROG

From: "Gennady Mayko" <gennady.mayko@broadcom.com>

Добрый день!

 VI> From: "Vladimir Ivanov" <vivanov@tmsoft-ltd.kiev.ua>

 VI> Hi!

 >> Проблемы могут быть, если длина перехватываемой функции меньше 5 байт.
 VI> Здесь,
 >> конечно, нужно действовать по другому.

 VI> Еще проблемы могут быть, когда копируемые инструкции содержат команду
 VI> перехода.... Тогда тоже нужно действовать более "интеллектуально".
 VI> Detours, например, такие ситуации определяет и отказывается патчить
 VI> функцию.
 VI> Код, который мы переносим, может содержать и другие инструкции
 VI> привязанные к месторасполажению. Может быть дальше в теле функции есть
 VI> jmp в область, которую мы патчим.... Наверное, список таких ньюансов на
 VI> этом не кончается...
 VI> Чтобы все такие случаи корректно обработать, ИМХО нужно очень и очень
 VI> постараться...
--
Да, это так.

 >> >2. на момент модификации существует поток, приостановленный
 >> >осле выполнения непоследней из этих инструкций.
 >> И это можно обойти несколькими способами. Наиболее простой -
 >> "административный" - требовать, чтобы никакие другие потоки в этот момент

 VI> не

 >> выполнялись. Если так не получается, тогда написать "мини-отладчик",

 VI> который

 >> будет запускаться перед модифицируемой программой (это легко сделать
 >> установками в registry); сделает необходимые изменения и запустит

 VI> программу на

 >> выполнение.

 VI> С отладчиком, идея хорошая. Еще, в этом плане, может быть полезно что-то
 VI> вроде CreateProcessWithDll в Detours.
 VI> При выполнении патча в уже работающем процессе, можно, например, сделать
 VI> и так:
 VI> после копирования кода, но непосредственно перед выполнением патча,
 VI> пробегаться по контекстам соседних потоков и, если нужно, переставить EIP
 VI> (как и ранее говорю только о x86) на соответствующий адрес в
 VI> скопированный
 VI> код (естественно придёться помучаться с Suspend/Resume, повторными
 VI> проверками и т.п.). В дополнение к этому - проставить перед пробеганием
 VI> по потокам - замену всех 5 байт 0xCC (бреакпойнтами), с реализацией
 VI> похожей логики перестановки EIP в обработчике бреакпоинта.
--
Думаю, что это не так просто гаранитровано остановить уже "бегущие" thread'ы
процесса "изнутри" какого-то одного из них. После "остановки" одного thread'a,
другой, еще бегущий, теоретчески может его перезапустить...

Использование команд процессора INT 3 (0xСС), UD2, недокументированной ICEBP
(атомарно вставленных в начале функции), совместно с "мини-отладчиком",
который и будет заменять код, поможет гарантировать, что первый же thread,
"наткнувшийся" на такую команду, перебросит управление "мини-отладчику" и
заморозит остальные, которые в этот момент, естественно, не выполняют
следующие команды.
Еще один вариант получения управления в "мини-отладчике" - это использование
отладочных регистров процессора.

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

Можно даже скомпилировать весь или часть проекта с опцией /Gh и в функции
_penter делать необходимые действия в зависимости от состояния стека. ;-)

 VI> С уважением,
 VI> Владимир Иванов

--
С уважением,
Геннадий Майко.

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)