Я думаю,многим известно,что StarForce перехватывает прерывания для своих нужд и не даёт таким образом нормально работать SoftIce. Я решил написать мини-драйвер(исходник и сам,приложены),который бы мог оперировать адресами обработчиков прерываний(примерно так,как это описывал ASMax в одной из своих статей про старые версии протектора). Для начала я ограничился только считыванием адресов обработчиков. И тут же встал косяк: в присутствии StarForce мой драйвер возвращает мне адреса обработчиков словно они перехвачены SoftIce,в то время как они должны быть и есть перехвачены протектором.В общем,некорректно работает. Ведь IDT должна быть одна для всех процессов??И данные о таблице,полученные из одного процесса,должны быть действительны и для любого другого,не так ли?? Теперь же ситуация получается следующая: защищённое приложение висит зацикленое в памяти.Загружается SoftIce,который командой idt показывает правильные адреса обработчиков(прерывания 1 и 3 перехвачены протектором).Я запускаю свой мини-драйвер,который мне показывает,что прерывания 1 и 3 всё ещё перехвачены отладчиком SoftIce,что неверно. Собственно,вопрос: как быть??Почему так происходит?? Надеюсь,что кто-нибудь сможет это всё как-то прокомментировать. P.S. ОС -- Win2kSP4 P.P.S. Версия протектора очень древняя -- 1.0.0.1 -- судя по защитной библиотеке.
...это как?? Тут попробовал также утилиту от Dragon'а -- R0cmd. Так та тоже показывает,что прерывания перехвачены отладчиком,когда они на самом деле должны быть перехвачены протектором.Мистика какая-то. Жалко,что нельзя попробовать это дело на XP, т.к. на этой ОС защищённая игра вообще не запускается,перезагружая компьютер.А других игр со StarForce у меня к сожадению нет.
DillerInc Загружается SoftIce,который командой idt показывает правильные адреса обработчиков(прерывания 1 и 3 перехвачены протектором). Утверждение неверно. При загрузке SoftIce перехватывает эти прерывания, а выводит информацию ту которая была до перехвата. Для реальных искользуй IceExt и комманду !idt Не проверял, но попробуй не пользовать idt а просмотри таблицу в памяти.
Старфорс модифицирует таблицу страниц защищаемого процесса так, что его IDT отличается от общесистемной.
PROFi Спасибо,проверим с IceExt. ...а как мне на неё ещё можно выйти??Я имею ввиду с помощью моего драйвера.Я так понимаю,что использование команду SIDT -- это единственный вариант узнавания базового адреса таблицы... Agent666 Я пробовал делать следующим образом.В исследуемый процесс внедрялась моя DLL,которая потом вызывала мой драйвер.Последний возвращал результат,который вроде показывал,что прерывания перехвачены протектором,но адреса были какие-то как бы неверные... В общем,буду ещё смотреть.
Похоже,что Agent666 прав. Когда защищённое приложение висит в памяти в зацикленом состоянии и жрёт всё время процессора,то активированый отладчик остановится наверняка в контексте этого процесса. Тогда с помощью команды !idt мне выводится,что прерывание 1 и 3 перехвачены протектором(адреса 01820000h и 01830000h соответственно).Если же я в то же время прервусь в каком-нибудь другом процессе,например,с помощью бряка на WinAPI-функцию и тогда в отладчике введу команду !idt,то последняя покажет мне,что прерывания перехвачены отладчиком(адреса 8201C01Dh и 8201C03Ch соответственно).Вот такая вот загагулина. Меня смущает однако другое. Как я уже описывал выше,я внедряю свою библиотеку в адресное пространство исследуемого процесса и из неё вызываю свой драйвер.Драйвер считывает адреса обработчиков 1 и 3 и возвращает их обратно в библиотеку.Так вот адреса эти странные: 02490000h и 024А0000h соответственно для первого и третьего прерывания.Но они же отличаются от тех,что мне выдаёт команда !idt...?!Почему так происходит?? EDIT. Значит так.Опытным путём было установлено,что адреса,полученные моим драйвером из внедрённой библиотеки,верные.StarForce видимо потом сам изменял свои адреса обработчиков.То ли он так реагировал на загрузку отладчика в память,то ли на завершение моего удалённого потока,то ли у него там свои какие-то манипуляции происходили.
DillerInc я внедряю свою библиотеку в адресное пространство исследуемого процесса и из неё вызываю свой драйвер. ССчас жже. DeviceIoControl ассинхронная функция, и драйвер ее обрабатывает в любом контексте если использовать буферезированный ввод-вывод. Об этом нельзя забывать.
...я так понял,что данная функция может быть асинхронной,только если использовать структуру Overlapped.И вообще к чему это всё?? ...а можно подробнее: что,как,куда,для чего...??Дело в том,что я только начинаю иметь дело с нулевым кольцом,поэтому многие вещи для меня туманны.
Starforce вешает свой обработчик на int1 (#DB, отладочное прерывание) и проверяет к тому же не прибил ли его кто. Но, мы просто снимаем бит присутсвия в дескрипторе для него и вместо #DB происходит #NP. Залепив небольшой драйвер отлаживаем любимым дебагером star.
...здорово звучит,но я пока не могу проследить весь ход мысли. Допустим,что мы снимем седьмой бит в KIDTENTRY первого прерывания.Я так понимаю,что протектор должен тогда выкинуть "Segment not present exception" -- прерывание номер 11. А вот как мы должны его обработать...??
tylerdurden Хорошо,попробую разобраться.Если что,я спрошу тут что-нибудь.В любом случае спасибо за информацию.
...а можно ли,находясь не в защищаемом процессе,как-то выйти на IDT,которая находится в защищаемом процессе??
DillerInc Думаю заюзать драйвер - приаттачиться к процессу , тем самым мы будем находиться в контексте процесса в который мы приаттачились. А дальше можно его зозохать .
TermoSINteZ Я сейчас пробую делать следующим образом: библиотека,внедрённая в исследуемый процесс,запускает драйвер и потом общается с ним через DeviceIoControl.Так вот в драйвере я считываю IDT дважды.Первый раз в теле DriverEntry,которая выполняется в контексте процесса System,и воторой раз в теле DispatchControl,которая выполняется в контексте исследуемого процесса,который запросил операцию ввода-вывода. Я просто интересовался,есть ли какой-то иной способ...
Дада, именно. #pragma pack(2) struct IDTR { WORD Limit; PVOID Table; } Idtr; #pragma pack() ... DriverEntry(..) { __asm sidt[Idtr]; ... }
