Volodya Очень много раз тебя спрашивали о том будет ли 3й выпуск "упаковщиков" , на что ты отвечал, что ведутся работы по их созданию, но уже прошло довольно много времени, а их нету! Повторный вопрос: Когда же они будут?
EvilsInterrupt Такие статьи пишутся либо в юношеском запале, либо в старости от нечего делать. Первый этап пройден, жди второго...
volodya Слушай, доверь черновик, тому, кто этого достоин, а кто достоин созовем Вече. Вобщем если это возможно сделать, то думаю не только я бы обрадовался выходу очередных "упаковщиков" удачи в коде
volodya Коректная обработка RDTSC невозможна, поскольку при записи в MSR регистр, старшая часть (старшие 32 бита) обнуляются (это из мануалов Intel). Т.е. если защита привязана к значению TSC, то ... Writing to the time-stamp counter with the WRMSR instruction resets the count. Only the low order 32-bits of the time-stamp counter can be written to; the high-order 32 bits are 0 extended (cleared to all 0s).
volodya Есть 2 обьяснения. Первое: Контингент не теряет надежды увидеть релиз. Сам факт появления черновика не сильно подкрепляет эти надежды. Второе: не дочитали ещё
Не нужно ничего писать в MSR регистр, можно просто сделать rdtsc привелигированой инструкцией, ловить исключения и эмулить rdtsc как угодно (справедливо только для ринг3 кода).
Советовал бы добавить, что в случае наличия ядерного отладчика (windbg) исключение может идти из KiDispatchException в KiDebugRoutine. Это также можно использовать для перехвата исключений в своем трейсере (ядерном конечно, а не юзермодном как описывается в статье).
volodya > "Заметим, что перед использованием RDTSC необходимо чистить конвеер процессора" Видимо ты не следил за развитием темы IsDebuggerPresent (вот и не уследил - "тема закрыта или никогда не существовала" Чистить конвеер и вычислять всякие subtime совершенно никчему - задержки обработки исключения даже без отладчика настолько велики (единицы-десятки тысяч тактов), что всякая мелочь тут никакой роли не играет. А на P4 с HT "ловить блох" вообще не имеет смысла, т.к. разброс результатов из-за "квазипараллельного" выполнения двух потоков составляет десятки и сотни тиков. Важнее: 1) Обеспечить инициализацию памяти (данных и кода), чтобы не нарваться на page fault. Для этого стоит a) предварительно что-то прочитать или записать в используемые переменные, b) можно вызвать исключение без измерения rdtsc, чтобы обеспечить инициализацию и загрузку в кэш кода обработки исключения 2) Измерять задержку обработки исключения несколько раз и брать минимальное значение - при этом значительно снижается вероятность нарваться на переключение контекста - ведь "мы работаем в многозадачной системе" Ну и разница между измерениями без отладчика и с отладчиком достигает сотни раз, поэтому достаточно надежно работает фикс.порог обнаружения. Желающие могут проверить - вот рабочий примерчик (fasm+exe), который я приводил в безвременно почившей теме IsDebuggerPresent: _80909998__Rdtscdbg.zip
leo Видимо ты не следил за развитием темы IsDebuggerPresent Хорошая была тема Нашел кусок ветки в архиве от 29.11.2004, но там тока 4 страницы. Гугл помнит, что было 6 страниц, мож у кого полная версия есть? Помницца как раз в конце мы это и обсуждали. 1710102850__IsDebuggerPresent.rar
