СФ опрашивает порты встроенного IDE контроллера, которые изменить пока не получается (возможно, кто-нибудь знает что-либо по этому поводу?) Имеется в виду переназначение портов 170-177 и 1f0-1f7 (я думаю, это можно сделать через PnP BIOS или прямым вторжением в ESCD на этапе загрузки BIOS extension - например, сменить порты IDE на порты COM1/COM2 - система все равно получит от PNP верную информацию из ESCD и будет действовать сообразно полученным данным, а СФ обломается) - я проверял (отключал второй канал в BIOS и вешал на освободившиеся 170-177 CMD 0649 PCI RAID Controller - несмотря на обращение к нему через scsiport СФ успешно определяет на нем ATAPI девайс - хотя после изменения портов на соседние успехи в определении заканчиваются)

ECk
[Offtop]
Как там статья по SF3 поживает?
[/Offtop]

Для ECk

Хм. Я что имел ввиду.
Если будет написан драйвер, который будет вешаться на порты 170-177 и т.д. и в зависимости от настроек будет пропускать или непропускать запросы на эти порты.

Ведь можно же вести отладку по обращениям к портам.

Вопрос как я понимаю в том, что нужно как-то перенаправить вызовы sf на свою программу.

В самом крайнем случае поможет только правка материнской прошивки.

Для DenKor
На самом деле там все значительно ниже - запросы на эти порты идут не через драйвер, а прямой записью в порты из пкода СФ - таким образом, единственный путь заставить СФ двигаться официальными путями - переназначить порты IDE. К тому же, правка содержимого BIOS - едва ли удовлетворяющее всех решение (решение то нужно всем), а обращение к функциям PNP BIOS - практически generic way для этого.

Для ozzman
Статья пока не готова, т.к. они с каждой версией модифицируются, параллельно с написанием приходится поспевать за их стараниями. К тому же, там многослойный пкод - то есть, один код, помимо осуществления своих целей параллельно собирает на стеке и выполняет всякие мелочи вроде проверки через rdtsc через каждые два-три опкода во избежание трассировки, предварительно формируя из crc участка кода перед выполнением значение для всех следующих переходов внутри пкода.

Для EcK

Я где-то в конференциях видел как кто приводил пример в котором были указаны читаемые сектора и время доступа к ним. Т.е. я понимаю, что кто-то все таки перехватывал обращение sf по доступу к диску.
_http://forum.ru-board.com/topic.cgi?forum=55&topic=0519&start=540

Вот мне и интересно как он это сделал. И хочется сделать такой анализ самому на своей игре Князь Тьмы.

Если ты копался в коде программы, то можно ли сделать перехват портов (сбрасывается ли регистр cr4 в части перехвата обращений).

Для DenKor
До cr4 дело не доходит, т.к там на протяжении пкода активно юзаются dr0-dr7, в связи с этим для перехвата сначала придется избавляться от этого; вторая ложка дегтя - периодически занимаемые различными обработчиками int1 / int3 - я в принципе это обошел, разместив в драйверах вместо их обработчиков свои, восстанавливающие парный вектор (int 1 восстанавливает int3, int 3 восстанавливает int 1); плюс, если есть желание потрассировать после восстановления int1/int3 - нужно выдрать зубы у prosync1.vxd (я привожу все свои примеры применительно к работе под 9Х - в некоторых аспектах там проще исследовать СФ) - prosync1.vxd блокирует все IRQ - прямо через контроллер прерываний 8259 (порты 20-а0) (master&slave) - если в prosync1 не вырубить эту фишку, будет примерно следующее: ты всплывешь в Айсе и все - ни F8 нажать, ни Ctrl-D - IRQ клавиатуры на СФ, в таких случаях поможет только reset (или устранение препятствия в виде функции из prosync1, ответственной за это - если не ошибаюсь, юзаемая по DEVICE_IO_CONTROL).
К тому же, относительно номеров секторов, которые перехватывались драйвером - в данной версии СФ это не применяется (запись/чтение идут через прямой доступ к портам контроллеров IDE за исключением случаев, когда драйв/контроллер установлен как SCSI).
Другое дело, можно использовать для этого драйвер Uniata - в поисковике можно найти страницу, где и исходники и последняя версия - это универсальный драйвер для IDE/ATA/ATAPI контроллеров, поддерживающий несколько основных контроллеров - с его помощью можно пересадить обычный on-board IDE controller на scsi и убрать из поля зрения СФ - вот тогда запросы к нему будут полностью контроллируемые.

Некоторые дополнительные подробности - перед каждой операцией с портами встроенного IDE контроллера происходит проверка регистра cr4 на DE - и делается видимость использования dr0-dr3 (mov dr0-dr3,eax - но сохраненного там значения никто не использует вплоть до следующей записи в dr0-dr3). А в остальном - ничего нового там не придумано (вся процедура проверки на наличие ATAPI девайсов ограничена 0хEC (IDENTIFY_DRIVE) в порты контроллера по одному для каждого девайса master/slave) на обоих каналах - чтение происходит через rep insw. Наверное, можно установить GD и после обращения к dr0-dr3 устанавливать DE в cr4 (а после отлова каждой записи/чтения вновь его скидывать и устанавливать GD). Единственное "но" на сегодняшний день - на int 1 находится callgate для перевода ДЛЛ в ring0.

ECk

Изумительная работа. Молодец.

ECk
на сегодняшний день - на int 1 находится callgate для перевода ДЛЛ в ring0

это что же получается замечательная дырка в системе безопасности - любой может через старфорс пролезть в ядро?

Об этой дырке уже упоминали Sten и AsMax - репорт был отправлен куда-то там... Забыл. У них спроси.

Max
Обработчик int1/int3 находится в IDT только на время проведения проверки диска (причем, для int3 - несколько), хотя код для callgate находится в драйвере prohlp02.sys - теоретически можно, пользуясь кодом из этого драйвера устанавливать callgate, переходить в 0, а затем восстанавливать оригинальный обработчик (в драйверах сохранена копия оригинальной IDT) - более того: это можно делать через создание \\.\PRODRV06 - после создания на int1 установлен callgate. Единственное "но" - на время вызова CreateFile,"\\.\PRODRV06" надо прятать Айс (под 9Х хватает изменения в DDB идентификатора и символьного имени на любые другие, под NT/XP/2K не пробовал, но в драйверах видел открытие NTICExxxx из драйвера через IoCreateSymbolicLink - в части, предназначенной для ХР) - если драйвер находит Айс в памяти, CreateFile возвращает INVALID_HANDLE, если Айс спрятан - возвращает нормальный хэндл (для закрытия callgate хэндл можно просто закрыть).
Причем, дыра получается реальная (что под 9Х, что под ХР - т.к код для чтения портов находится в ДЛЛ, а она при загрузке в usermode).

Мдя, я тут тоже уже давно занимаюсь старфорсом 3 и всё как-то не сильно... Тут попала мне гама Panzers называется, с поломанным Starforce(именно поломанным). Заметил что в сломанном фале отсуствует 2 секции, .start и .brick, добавилась новая .revolt называается ))). Видно чуваки из револта его распаковали и сняли защиту....
Если интересно для изучения могу прислать оба ЕХЕ ориг и крякед...

Да забыл добавить, протект.длл и остальные драйвера старфорса п*х....(они не юзаються)

Причем, дыра получается реальная (что под 9Х, что под ХР - т.к код для чтения портов находится в ДЛЛ, а она при загрузке в usermode).

Да, ходили под NT в ring-0 через SF.
Правда, насколько я знаю, разработчики SF собирались код подписывать цифровой подписью, чтобы всякие левые вещи через эту дыру не просочились. И вроде бы в новых версиях это уже сделано.

Я сам не смотрел насколько это все эффективно реализовано.

там ДЛЛ с драйвером имеют нечто вроде протокола шифрованного - длина входного/выходного буфера по 40 байт, передаются: номер АПИ в драйвере (4 байта) и аргументы (не более 9 штук по 4 байта). Передаются в зашифрованном виде, но шифр детский :)
Через этот интерфейс доступны АПИ для маппинга кода из ring3 в ring0, установка callgate и адреса для выхода, установка обработчиков на любое из прерываний и т.д

Интересно, если эту дыру вместе с протоколом обмена опубликовать в сети, как долго они просуществуют в текущей версии? И сколько патчей им придется одномоментно выпустить? И насколько меньше разработчиков в дальнейшем воспользуются СФ?