wasilissk
Цитата:
Щелчков то может быть не 4. Вобщем первым я узнал об этом методе из постов на руборде. Смотрите анналы. Дело было давно, и rubord-вец писал что он вообще всю таблицу импорта полностью подделывал. Я тогда не стал спрашивать зачем же именно всю таблицу, но очевидно у него были на то основания. Брейкпоинт как мне известно это инструкция прерывания внедрённая прямо в код. Помоему int3 и то есть это записанные конкретные байты туда где их быть не должно. Как вариант - не выполнять такую функцию где брейкпоинты. Как вариант - можно "затрахать" прочитав перед этим ini файл и много чего другого. Всё таки ближе к телу. Перечисленные аргументы.
1. 2. Изучать в дебажнике статические вызовы легко и удобно. А так жне осуществлять их поиск.
3.
Цитата:
Ну и что что он не забыл? Он во все программы сразу же пихает брейкпоинты на эту функцию? Отлично, тогда наверно псевдополезный затрахиватель поможет ему понять, что туда надо ставить брейкпоинт только в тот момент когда будет выполнятся реально полезный код. А так как с географией вызовов по процессу туго, сложно будет поставить ещё один брейкпоинт чтобы попасть в тот момент когда нужен брейкпоинт на реальный код.
Перед этим хакеру надо изначально подозревать все программы, потом тратить время на затрахиватели, потом убедиться что куча баги действительно должна быть может быть взята только хитростью. А потом уже пересмотреть правильно ли он сделал когда подозревал что программа делает VirtualProtect? Может это очередная веселуха или замануха.
4.
Цитата:
Hook не возможен. При статической линковке организуется таблица импорта, при загрузке организуется таблица JMP адрес DLL и на эти JMP указывают вызовы статических функций. Hook это операция записи в таблицу JMP своих адресов. Операция по подмене реального кода на свой собственный для перехвата с последующим востановлением затираемых инструкций называется иначе но по сути это тот же Hook. Но при динамичнеской загрузке адрес хукаемой функции находится в хипе процесса и ни как не связан с кодом программы. На каком предположении вы сделаете вывод что пачка байтов в хипе это и есть тот адрес который надо подменить? Hook - в таком виде не возможен.
Добавлено:
ЗЫ
Кстати ладно, поделюсь... Самые полезные затрахиватели это те которые работакют при перерисовке окон. Вы переключаетесь из дебаггера в окно программы, она перерисовывается и в любом случае вы получаете дополнительный полезнай брейк, далее видите окно дебаггера и так прыгаете некоторое время туда сюда.
Добавлено:
Ну и если уже у вас вся таблица импорта под рукой то можно сыграть очень красивую и многоголосую музычку в самые разные места.
Цитата:
на эти функции в четыре щелчка.
Щелчков то может быть не 4. Вобщем первым я узнал об этом методе из постов на руборде. Смотрите анналы. Дело было давно, и rubord-вец писал что он вообще всю таблицу импорта полностью подделывал. Я тогда не стал спрашивать зачем же именно всю таблицу, но очевидно у него были на то основания. Брейкпоинт как мне известно это инструкция прерывания внедрённая прямо в код. Помоему int3 и то есть это записанные конкретные байты туда где их быть не должно. Как вариант - не выполнять такую функцию где брейкпоинты. Как вариант - можно "затрахать" прочитав перед этим ini файл и много чего другого. Всё таки ближе к телу. Перечисленные аргументы.
1. 2. Изучать в дебажнике статические вызовы легко и удобно. А так жне осуществлять их поиск.
3.
Цитата:
Ага, а при динамической, хакер сразу как бы забывает, что есть такая функция
Ну и что что он не забыл? Он во все программы сразу же пихает брейкпоинты на эту функцию? Отлично, тогда наверно псевдополезный затрахиватель поможет ему понять, что туда надо ставить брейкпоинт только в тот момент когда будет выполнятся реально полезный код. А так как с географией вызовов по процессу туго, сложно будет поставить ещё один брейкпоинт чтобы попасть в тот момент когда нужен брейкпоинт на реальный код.
Перед этим хакеру надо изначально подозревать все программы, потом тратить время на затрахиватели, потом убедиться что куча баги действительно должна быть может быть взята только хитростью. А потом уже пересмотреть правильно ли он сделал когда подозревал что программа делает VirtualProtect? Может это очередная веселуха или замануха.
4.
Цитата:
Hook на что невозможен? На вызов API функций? Уверены?
Hook не возможен. При статической линковке организуется таблица импорта, при загрузке организуется таблица JMP адрес DLL и на эти JMP указывают вызовы статических функций. Hook это операция записи в таблицу JMP своих адресов. Операция по подмене реального кода на свой собственный для перехвата с последующим востановлением затираемых инструкций называется иначе но по сути это тот же Hook. Но при динамичнеской загрузке адрес хукаемой функции находится в хипе процесса и ни как не связан с кодом программы. На каком предположении вы сделаете вывод что пачка байтов в хипе это и есть тот адрес который надо подменить? Hook - в таком виде не возможен.
Добавлено:
ЗЫ
Кстати ладно, поделюсь... Самые полезные затрахиватели это те которые работакют при перерисовке окон. Вы переключаетесь из дебаггера в окно программы, она перерисовывается и в любом случае вы получаете дополнительный полезнай брейк, далее видите окно дебаггера и так прыгаете некоторое время туда сюда.
Добавлено:
Ну и если уже у вас вся таблица импорта под рукой то можно сыграть очень красивую и многоголосую музычку в самые разные места.
Можно даже не сомневаться что он умеет когда GetProcAddr(GetProcAddr) возвращать себя. И можно не сомневаться что он сделан на основе хука изначального статического, потому что без изначального статического не узнать ни одного динамического. Осталось только дотянуться до реального GetProcAddr, чтобы гадкий хакерский способ перестал работать. Предложу самостоятельно подумать как это сделать. Был бы у меня BoundChecker мне было бы легче найти его уязвимость. 
Любой нестандартный подход (если он часто используется) рано или поздно становится стандартным =)