Сейчас на форуме: vsv1, johnniewalker, Magister Yoda, Kybyx, r0lka (+5 невидимых) |
eXeL@B —› Крэки, обсуждения —› Отладчик на основе int xx |
Посл.ответ | Сообщение |
|
Создано: 19 августа 2010 19:08 · Личное сообщение · #1 Исследования показали, что заявленный ранее мной --> отладчик <-- менее устойчив, чем классический. Это все потому, что он вносит изменения в стек, вносит большие задержки в исполнение, программы пишутся с ошибками, которые без него себя не проявляют, и т.д., и т.п. Хотя на нем и правда можно объехать антиотладочные трюки, возникает множество других проблем, из-за которых приходится под каждый софт его переделывать. Отладчиком его не назвать, годится только под цели загрузки под собой с изменением нужных параметров, и то не для всех программ. Отдадчик на основе int 3 и аппаратных прерываниях более устойчив, но вся эта антиотладка не дает написать такой, чтоб он работал для всех защит. Сейчас мало помалу исследую ядро винды, и пока не обжился новым хардом, чтоб можно было вм поставить, пришла в голову еще одна идея. Бредовая или нет, судите сами. В idt находим свободный и вписываем новый шлюз, например 0xCD; в отлаживаемой программе вместо int 3-бряков будет int cd; исключения перехватываются через KiUserExceptionDispatcher; процесс создается не с флагом DEBUG_PROCESS, а как обычный процесс, но через native: проецируется секция, все как обычно, только никакого debug_port и перед NtResumeThread над сформированным образом процесса и его стеком производятся действия; отладчик получает уведомления из ядра, (возможные механизмы - apc, exception, объекты синхронизации). Как эта идея? int, я траву не курю, сегодня кофе молотого много выпил, сам варил. ----- IZ.RU |
|
Создано: 19 августа 2010 19:58 · Личное сообщение · #2 Не думаю, что хорошая идея. Бряки надо скрывать в любом случае из памяти. Какой-бы ни был бряк, его всё равно можно поймать расставив инициализацию переменных через проверки CRC памяти. И посмотрю я на вас, как это будет решено. Все хорошие идеи уже давно опубликованы. Надо просто сесть и реализовать, а не изобретать велосипед. Можно вообще сделать ring3 отладчик и при этом без единого драйвера, если не публиковать методы его работы, то проживёт долго. Можно с драйвером и тогда его поймать можно будет только задержками (а этот способ нормальный разработчик защиты применять не будет, из-за опасности срыва нормальной работы приложения из-за исключений). P.S. А под всеми видами защит имелся в виду 3-ий старфорс что ли? Или где ещё int3 используется? P.P.S. А причём тут кофе и вообще я? В том посте действительно был ответ не по вопросу, наверно я слишком неадекватно выразил эту мысль, прошу меня простить. |
|
Создано: 19 августа 2010 20:25 · Поправил: DenCoder · Личное сообщение · #3 Ну да, о проверке crc памяти я уже думал, это может быть единственным барьером. Но может быть, и не обязательно будет. Можно весь read перехватывать, что конечно замедлит работу, но известно как хукать rdtsc... визуальные задержки если только. Думаю, небесперспективно решение этой проблемы. Топик защищен за форумом, гуглом не найдешь, было б еще хорошо, чтоб новички не видели такие топики. С другой стороны, бога ради, пусть смотрят, кому дано понять, защита все равно проигрывает минимум один шаг. Невозможно справиться только с защитой, где usb-ключ (или любой другой носитель, или файл) содержит зашифрованный код, а в основе ключа шифра - hwid и/или данные пользователя. Хотя если сильно постараться... www.youtube.com/watch?v=eFV9-RuVYRU int пишет: P.S. А под всеми видами защит имелся в виду 3-ий старфорс что ли? Или где ещё int3 используется? Не, я не имел ввиду, что какой-то защите именно int 3. int пишет: P.P.S. А причём тут кофе и вообще я? В том посте действительно был ответ не по вопросу, наверно я слишком неадекватно выразил эту мысль, прошу меня простить. Просто пошутил, как и Вы ----- IZ.RU |
|
Создано: 19 августа 2010 20:35 · Личное сообщение · #4 DenCoder Постепенно вы придёте к тойже идеи что и я. Это отладка на уровне трап-процессинга(манипуляции не контекстом, а состоянием задачи, в NT это трап-фреймы). Тоесть например трассировочный останов обрабатывается кодом, управление который получает из KiTrap01() сразу за формированием трап-фрейма. Подобных точек в ядре необходимо перехватить множество. Это весьма сложная обработка, нужно учесть столь много нюансов, что мне не хватило терпения для реализации . |
eXeL@B —› Крэки, обсуждения —› Отладчик на основе int xx |