|
| Посл.отвђт | Сообщенiе |
|
|
Дата: Июн 20, 2004 22:41:36 Как известно, многие протекторы любят пихать в DR-регистры мусор или обнулять их. Меня заинтересовал такой вопрос: как бы им руки то поотрывать? Сиречь - запретить порчу DR-регистров. Покопавшись там-сям наткнулся на интересную вещь: GD флаг в DR7. Когда он установлен, протектор не сможет нам напакостить в DR-регистрах, но вот незадача: Процессор очищает GD флаг при вхождении в debug exception handler, чтобы разрешить handler'у доступ к отладочным регистрам. Приехали. Протектор из ринга3 как раз и использует SEH, чтобы получить доступ к DR. Замкнутый круг. Стал я думу думать дальше... В принципе, можно написать трейсер, которые будет проверять флаг GD. Если флаг сброшен, значит кто-то вошел в exception handler, меняем флаг обратно и протектор обламывается. Но вот незадача - современные протекторы мой трейсер просто уроют своими антиотладочными приемами :(. Вобщем интересно было бы выслушать ваши мнения... |
|
|
Дата: Июн 20, 2004 22:45:14 Было бы неплохо тебе искать по форуму, перед тем как вопросы задавать-то... 1) Поиск по форуму 2) http://reng.ru/board/viewtopic.php?t=1454&sid=fe6c1dec42af0c2dbba233b37980cbf6 Потом продолжим обсуждение... |
|
|
Дата: Июн 21, 2004 02:31:56 1) делал 2) читал, давно правда... мысли интересные, но после 2-й страницы пошел флейм :) Кстати, ты получил какое-нибудь общее решение (реализацию)? p.s. меня радует то, что про бит GD я сам дошел(ну, еще интеловские мануалы помогли :)) и сей метод для моей задачи подходит. |
|
|
Дата: Июн 21, 2004 20:15:47 Кстати, ты получил какое-нибудь общее решение (реализацию)? Идея AsMax кажется мне единственно верной. Реализации нет. Пока :) |
|
|
Дата: Июн 22, 2004 02:12:30 ozzman А если протектор не просто обнуляет DR-ы, а чего-то в них для себя полезное еще хранит?.. |
|
|
Дата: Июн 22, 2004 03:26:33 Если бы ты читал линки, этого вопроса бы не возникло :) |
|
|
Дата: Июн 22, 2004 03:29:03 so what? меня интересует только запись в них мусора и обнуление. |
|
|
Дата: Июн 23, 2004 14:50:40 ozzman Есть три варианта: 1. Прога обнуляет отладочные регистры 2. Сохраняет в них что-то, а позже эти значения проверяет 3. Реально использует ДРх че тут можно сделать... 1. перехватываешь NtContinue и в нем сбрасываешь CONTEXT_DEBUG_REGISTERS в ContextFlags. 2. перехватываешь KiUserExceptionDispatcher и перед вызовом пользовательских обработчиков засовываешь на стек значения ДРх из промежуточного буфера. в NtContinue, если установлен флаг CONTEXT_DEBUG_REGISTERS, сохраняешь значения ДРх в промежуточный буфер и сбрасываешь CONTEXT_DEBUG_REGISTERS 3. если прога использует все четыре регистра, тогда ой!, если не все, то задача [почти] сводится к п. 2 |
|
|
Дата: Июн 23, 2004 15:40:51 · Поправил: Max если прога использует все четыре регистра, тогда ой! тут теоретически тоже есть решение, но практически реализовывать его я не пробовал (пп. 1 и 2 реализуются на ура), ибо связано это с бааальшим гемороем вообщем, идея следующая... 1. делаем как в п. 2, то есть не даем проге менять значения регистров, в тоже время кладем их на стек, если прога вдруг захочит их проверить 2. при попытке установки брейкпоинтов в NtContinue, ставим страницам с брейкпоинтами NoAccess, вместо реальной установки брейкпоинтов 3. при срабатывании эксепшена на закрытой странице анализируем адрес - если это адрес брейкпоинта (на самом деле тут все намного сложнее), то имитируем срабатывание брейкпоинта, если нет, то тут начинается... :) убираем NoAccess, выполняем инструкцию в режиме трассировки, после чего ставим NoAccess. тут могут быть быть всякие заморочки, когда инструкция с одной закрытой страницы лезет за данными в другую закрытую страницу вообщем, полная 屁股, хотя чиста теоретически тут могут быть перспективы [added] вах, у нас появился автоматический цензор :)) прикольно! |
|
|
Дата: Июн 23, 2004 16:48:08 ozzman чё то я не понял, ну так, ты же запихиваешь свой обработчик #DB взамен перед системным, дак и сматри оттуда, кто к ним прорывается (к DR) и чего с этим делать. Был же ведь примерчик на васме. там исходничик ring0.sys есть. Всё по уму сделано и никаких проблем, не знаю, я делал подобным образом (хихи, если вообще полностью не передрал:) ), конфликтов ни с чем не возникало. Помоему это напрасные крики... хотя, я могу и ошибаться |
|
|
Дата: Июн 24, 2004 14:53:01 · Поправил: RobinFood Max убираем NoAccess, выполняем инструкцию в режиме трассировки, после чего ставим NoAccess. У меня уже была такая идея, хотя и с немного другой целью. Я долго и упорно обходил грабли, пока не наступил на последнюю из них: во время вызова функций ядра (через int 2e / sysenter) тоже могут происходить обращения к защищенным с помощью NoAccess страницам. Но отладчик в ring3 об этом уведомлять не будут, просто функции будут возвращать ошибку. А писать свой ring0 отладчик - до этого я еще не дорос, и дорасту нескоро :( Так что по крайней мере для меня - полная 屁股 и никаких перспектив. Особенно если вспомнить про многопоточность... В-вах :) и правда цензор :) |
|
|
Дата: Июн 25, 2004 15:43:13 во время вызова функций ядра (через int 2e / sysenter) тоже могут происходить обращения к защищенным с помощью NoAccess страницам кто бы мог подумать... :) а когда это происходит? может когда апишным функциям передаются ссылки на данные, расположенные в закрытых страницах? |
|
|
Дата: Июн 25, 2004 15:53:04 кто бы мог подумать... :) Я подумать не мог, поэтому для меня это было ба-альшой неожиданностью. а когда это происходит? может когда апишным функциям передаются ссылки на данные, расположенные в закрытых страницах? Скорее всего да, но... нужно учесть что далеко не все функции документированы. Например, недокументированный (по крайней мере я ничего найти не смог) int 2e вызывается из недр RegisterClassEx. |