Comments 16
Не знаю, что там у вас непонятно, вот моя же разжеванная статья, написанная триста лет назад. Все то же самое, только на С, а не на паскале.
Ваша статья хорошая, не спорю.
Правда у Вас рассмотрен исключительно сплайсинг, я же попытался рассмотреть данный вопрос немного более обширно. Надеюсь получилось ;)
Правда у Вас рассмотрен исключительно сплайсинг, я же попытался рассмотреть данный вопрос немного более обширно. Надеюсь получилось ;)
Кстати немножко по Вашей статье, я заметил в ней небольшой недочет (правда не принципиальный).
Это немного не верно, минимальный размер функции которую действительно нельзя перехватить равен одному байту, но в данном случае это будет RET и смысл в его перехвате попросту отсутствует.
Для двубайтовых функций есть диапазон в 256 байт.
Т.е. места достаточно для JMP SHORT, при условии что в ближайших 127 байтах сверху или снизу, будет неиспользуемые 5 байт для JMP NEAR OFFSET.
Кроме того, если размер функции меньше 5 байт, перехват просто невозможен.
Это немного не верно, минимальный размер функции которую действительно нельзя перехватить равен одному байту, но в данном случае это будет RET и смысл в его перехвате попросту отсутствует.
Для двубайтовых функций есть диапазон в 256 байт.
Т.е. места достаточно для JMP SHORT, при условии что в ближайших 127 байтах сверху или снизу, будет неиспользуемые 5 байт для JMP NEAR OFFSET.
Ms-Rem №2?
Хм, уже второй раз сравнивают, что-ж за беда? :)
Общее направление просто похожее :)
Общее направление просто похожее :)
Вообще-то сравнение с Ms-Rem должно льстить, если оно заслужено, ИМХО.
Это я понимаю, но тут двояко…
Я постараюсь объяснить свою позицию.
Ms-Rem очень отличный специалист и энтузиаст своего дела.
Но он больше придерживается позиции взлома ПО и практически не рассматривает в своих статьях методы противодействия.
Почему придерживается?
Да если честно, я считаю что он просто сошел со сцены и стараюсь не верить в ту историю с аварией.
(по крайней мере очень сильно стараюсь не верить ибо ходят слухи не первый год, что это не так).
Я же работаю немного с другой стороны баррикад, где приходится знать всю эту «подноготную» плюс немножко еще, чтобы опережать хотя-бы на шаг.
Ms-Rem очень отличный специалист и энтузиаст своего дела.
Но он больше придерживается позиции взлома ПО и практически не рассматривает в своих статьях методы противодействия.
Почему придерживается?
Да если честно, я считаю что он просто сошел со сцены и стараюсь не верить в ту историю с аварией.
(по крайней мере очень сильно стараюсь не верить ибо ходят слухи не первый год, что это не так).
Я же работаю немного с другой стороны баррикад, где приходится знать всю эту «подноготную» плюс немножко еще, чтобы опережать хотя-бы на шаг.
Статья написана грамотно. То, что вы находитесь по нашу сторону баррикад тоже радует, но тема несколько потрепанная. Кроме Ms-Rem на русском языке и на делфях про это писал в своей книге Олег Зайцев. Так что читая вашу статью невольно кажется, что читаешь реферат — компиляцию из уже существующих широко известных статей… как-то так.
Пожелание от себя на будущее: постарайтесь найти изюминку. Статья должна рождаться после того, как вы насобирали каким-то образом немного этого изюма и хотите поделиться с общественностью. Ведь у вас не туториал для новичков, а статья на Хабре в профильной ветке…
Почитал ваш блог и нашел статью про уход от перехвата CreateFile() — вот это примерно то, что нужно, только все равно не совсем то, ведь по сути ваша статья это рассказ о том, что вы видели в дебаггере, когда трассировали эту функцию по f7 и как это закодить на делфи…
Может вам присмотреться к вирусам и с вашими хорошими кодерскими/реверс умениями сможете много чего накопать и сделать много полезного в деле борьбы с малварью?
Пожелание от себя на будущее: постарайтесь найти изюминку. Статья должна рождаться после того, как вы насобирали каким-то образом немного этого изюма и хотите поделиться с общественностью. Ведь у вас не туториал для новичков, а статья на Хабре в профильной ветке…
Почитал ваш блог и нашел статью про уход от перехвата CreateFile() — вот это примерно то, что нужно, только все равно не совсем то, ведь по сути ваша статья это рассказ о том, что вы видели в дебаггере, когда трассировали эту функцию по f7 и как это закодить на делфи…
Может вам присмотреться к вирусам и с вашими хорошими кодерскими/реверс умениями сможете много чего накопать и сделать много полезного в деле борьбы с малварью?
Статья в целом хорошая — для новичков в самый раз, однако в методе «7. Перехват сплайсингом точки входа функции.» — вы допустили существенный недочет.
Использование lock xchg является плохим тоном вот почему:
— если в начале перехватываемой функции сразу за основным телом следуем XMM инструкция — то вы получите проблему
— если на один исполняемый образ ссылаются более 1 активного потока выполненияэ
Также на счет jmp short — да это хорошо, однако только в контексте текущего потока и в дополнение лимитировано на длину прыжка, что не всегда возможно. Для сверх коротких процедур проще использовать точки останова, они работают в любом случае.
Для решения этих проблем атомарного перехвата в многопоточной среде используют метод такого плана:
1) декодирование первых 8 инструкций точки входа в функцию
2) выравнивании по 8 байтам, все инструкции которые не вошли в размер замены переносятся в буферный блок для дальнейшего вызова
3) недостающие инструкции заменяются через NOP
4) через CMPXCHG8B производят атомарную замену кода (кстати HotPatch так и работает)
P.S. Вы забыли про еще один метод — это трассировка через регистры отладки (правда ограничего по количеству и наличию прав в системе)
Использование lock xchg является плохим тоном вот почему:
— если в начале перехватываемой функции сразу за основным телом следуем XMM инструкция — то вы получите проблему
— если на один исполняемый образ ссылаются более 1 активного потока выполненияэ
Также на счет jmp short — да это хорошо, однако только в контексте текущего потока и в дополнение лимитировано на длину прыжка, что не всегда возможно. Для сверх коротких процедур проще использовать точки останова, они работают в любом случае.
Для решения этих проблем атомарного перехвата в многопоточной среде используют метод такого плана:
1) декодирование первых 8 инструкций точки входа в функцию
2) выравнивании по 8 байтам, все инструкции которые не вошли в размер замены переносятся в буферный блок для дальнейшего вызова
3) недостающие инструкции заменяются через NOP
4) через CMPXCHG8B производят атомарную замену кода (кстати HotPatch так и работает)
P.S. Вы забыли про еще один метод — это трассировка через регистры отладки (правда ограничего по количеству и наличию прав в системе)
— если в начале перехватываемой функции сразу за основным телом следуем XMM инструкция — то вы получите проблему
— если на один исполняемый образ ссылаются более 1 активного потока выполнения
Эмм, так ведь это применяется только в случае HotPatch. т.е. когда мы имеем функцию которая всегда начинается с двубайтовой инструкции и предваряется пятью нопами. Т.е. что будет в начале MOV EDI, EDI, что вместо нее будет JMP SHORT -7, на XMM инструкцию это никак не повлияет. То-же относится и к лимитированию по длину прыжка — у нас всегда есть пять нопов перед процедурой.
Что-же по поводу CMPXCHG8B то именно для данной ситуации он ИМХО избыточен, но вот если у нас нет первой двубайтовой инструкции и нопов спереди, то его использование более чем оправдано.
Ну а Dr регистры — это все-же отладчик, это уже немножко вне рамок статьи :)
По поводу сплайсинга: хотелось бы поделится замечательной библиотекой MinHook, содержит дизассемблер длин команд и прочие умные штуки для корректной установки хуков, поддержка x32/x64 кода.
Все-таки лучше пользоваться проверенными решениями от разработчика OS…
Sign up to leave a comment.
Реализация перехвата вызовов API