Comments 4
Почему никто не вспоминает о конфликтах перехвата? Тулза обязана определять, стоят ли на интересующих её функциях чужие хуки.
Если стоят — то есть несколько вариантов действия. Наиболее разумное — после выполнения своего хука вызвать чужой хук. Обычно хуки ставятся с помощью jmp near long или jmp [imm]. Если такая инструкция установлена, переносим её в надёжное место (пересчитав адрес в первом случае), после выполнения своего хука прыгаем туда.
Также можно убить чужие хуки. Для этого открываем образ нужной DLL (GetModuleFileName/CreateFile), читаем таблицу секций, рассчитываем адрес в файле чистой точки входа в функцию (не забывая, что библиотека может быть упакована, для этого нужно посчитать количество изменённых байт в окрестности точки входа в функцию и убедиться, что это разумная величина). Затем исправляем изменённые байты в ОЗУ. Правда, стоит помнить, что сняв несколько вражеских перехватов, можно вызвать нестабильную работу программы (например, сняли перехват с ZwClose, и теперь вражеский хук не сможет отслеживать закрываемые ресурсы, в результате получим как минимум утечку памяти через структуры данных чужой тулзы). Так что если снимать хуки — то как минимум со всей DLL-ки.
Также не стоит забывать, что после того, как мы установили хуки, на них может посягнуть чужая тулза. Для этого желательно перехватить VirtualProtect и не позволять включить доступ на запись для интересующих нас страниц. Когда же к ним полезет чужая тулза, ловить исключения, определять установку хуков и также вызывать их после своих.
Было бы куда лучше и безопаснее, если бы писаки хуков (вместо выдумывания очередных велосипедов) выработали общий стандарт, учитывающий, что хуков на функцию может ставиться несколько, чтобы не приходилось по всякому извращаться…
Если стоят — то есть несколько вариантов действия. Наиболее разумное — после выполнения своего хука вызвать чужой хук. Обычно хуки ставятся с помощью jmp near long или jmp [imm]. Если такая инструкция установлена, переносим её в надёжное место (пересчитав адрес в первом случае), после выполнения своего хука прыгаем туда.
Также можно убить чужие хуки. Для этого открываем образ нужной DLL (GetModuleFileName/CreateFile), читаем таблицу секций, рассчитываем адрес в файле чистой точки входа в функцию (не забывая, что библиотека может быть упакована, для этого нужно посчитать количество изменённых байт в окрестности точки входа в функцию и убедиться, что это разумная величина). Затем исправляем изменённые байты в ОЗУ. Правда, стоит помнить, что сняв несколько вражеских перехватов, можно вызвать нестабильную работу программы (например, сняли перехват с ZwClose, и теперь вражеский хук не сможет отслеживать закрываемые ресурсы, в результате получим как минимум утечку памяти через структуры данных чужой тулзы). Так что если снимать хуки — то как минимум со всей DLL-ки.
Также не стоит забывать, что после того, как мы установили хуки, на них может посягнуть чужая тулза. Для этого желательно перехватить VirtualProtect и не позволять включить доступ на запись для интересующих нас страниц. Когда же к ним полезет чужая тулза, ловить исключения, определять установку хуков и также вызывать их после своих.
Было бы куда лучше и безопаснее, если бы писаки хуков (вместо выдумывания очередных велосипедов) выработали общий стандарт, учитывающий, что хуков на функцию может ставиться несколько, чтобы не приходилось по всякому извращаться…
Я понмю, какой-то онлайн переводчик переводил threads как «нити». Не уверен, что этот термин корректен.
Если Вы сплайсите в точке вызова процедуры — Вы перехватите только ее вызовы из данной точки, если Вы сплайсите в точке входа в целевую процедуру — Вы перехватите все ее вызовы. Краткое содержание статьи.
Sign up to leave a comment.
Правильное применение сплайсинга при перехвате функций подготовленных к HotPatch