SiS vs. StarForce

для раздела Блоги



SiS против старфорса




Продолжение цикла статей про надувательство старфорса при помощи смены некоторых идентификационных PCI-регистров IDE/SATA-контроллеров.



Похоже, мне все-таки одному придется тянуть лямку исследователя в данном направлении:


Не могу не напомнить: я не несу ответственность за то, что вы учините со своим железом начитавшись моих "статей"!




SiS-овские чиспеты сейчас можно встретить в основном на бюджетных материнках с интегрированной графикой. Продукция фирмы Silicon Integrated Systems мало распространена на сегодняшнем рынке чипсетов. Наверное, даже меньше, чем VIA. По крайней мере в России.

Поэтому мне пришлось приложить определенные усилия, чтобы раздобыть для своих опытов мамку на чипсете производства SiS. Ею оказалась ASUS P4S800-MX SE с южным мостом SiS964.




Поскольку <выборка> оказалась не очень представительной, я не могу гарантировать, что приведенная в этой статье информация будет применима ко ВСЕМ контроллерам, интегрированным в другие <южники> производства SiS.



Почему именно SiS ? Все очень просто.

Я обратил внимание на то, что в режимах [RAID] и [Native] (режим устанавливается в биос) регистры DeviceID и код класса SATA-контроллера отличаются. Получалось, что БИОС имеет возможность управлять этими регистрами. Т.е. изменение этих регистров возможно! Оставалось только выяснить: каким образом ?

Замечу сразу, что не удалось найти никакой документации на южные мосты SIS, вышедшие за последние несколько лет. А в документации на <старинные> модели южников информация по изменению идентификационных регистров напрочь отсутствовала:

Поэтому исследования пришлось проводить <методом научного тыка>. Т.е. все результаты были получены исключительно на основе практических изысканий. Вполне вероятно существуют еще какие-то дополнительные возможности по смене идентификационных регистров, до которых я не "докопался" в ходе экспериментов.

Итак, выяснилось, что...



  • DeviceID встроенных IDE/SATA контроллеров можно изменять при при помощи бита 7 регистра #57.

    Но не спешите радоваться, т.к. на выбор предоставляется только ДВА возможных значения.

    Таблица: зависимость DeviceID от значения бита 7 регистра #57.

    Bit 7
    Reg #57
    IDESATA
    05518h0180h
    15513h0181h


    ДО:



    ПОСЛЕ:





  • Можно менять подкод (SubCode) класса (регистр #0Ah). Выбор опять же из двух вариантов в зависимости от значения бита 0 регистра #57.

    Bit 0
    Reg #57
    SubClass Code
    (Reg #0A)
    001h
    104h


    ДО:



    ПОСЛЕ:




    Внимание!

    Возможность смены подкласса кода существует только для SATA-контроллера! Попытка перевести в единицу бит #0 регистра #57 на IDE-контроллере (DevID=5513h) приведет к потере операционной системой IDE-шного жесткого диска с последующей самопроизвольной перезагрузкой!

    В том, что нулевой бит регистра 57 на IDE-контроллере не отвечает за SubClass, я убедился изменяя этот бит в чистом ДОСе, предварительно отключив в БИОСе все IDE-накопители и загрузившись с дискеты.


  • Доступен для изменения регистр программного интерфейса (P.I.F., регистр #9), точнее, два его бита: #1 и #3.

    Сразу предупреждаю, что этой возможностью лучше не пользоваться!

    Но для справки все же приведу здесь описание того, как это можно проделать.

    За состояние бита 3 регистра #09h (P.I.F.) отвечает бит 3 регистра #50.
    За состояние бита 1 регистра #09h (P.I.F.) отвечает бит 3 регистра #52.

    Т.е. если установить бит 3 в регистрах #50 и #52, то в единицу установится соответствующий бит (#1 или #3) в регистре #09h (P.I.F.).

    И наоборот, можно из P.I.F.=8Ah (1000 1010 b) получить P.I.F.=80h (1000 0000 b), если сбросить соответствующие биты регистров #50 и #52 в ноль



    Bit 3
    Reg#50
    Bit 3
    Reg#52
    P.I.F. (bin)P.I.F. (hex)
    001000 0000 b80h
    011000 0010 b82h
    101000 1000 b88h
    111000 1010 b8Ah



    ПРАКТИКУМ:



    Ну а теперь настала пора рассмотреть возможные случаи применения полученных экспериментальным путем данных на практике.

    В каких случаях имеет смысл использовать приведенную в статье информацию?

    Случай, пожалуй, только один: когда Ваш CD/DVD-привод подключен к IDE-контроллеру.

    При этом изменив идентификационные регистры можно ввести вредоносные программы в заблуждение не прибегая к отключению IDE-контроллера (физическому, через БИОС или через Диспетчер устройств). Это особенно актуально, если системный загрузочный жесткий диск подключен к тому же IDE-контроллеру.

    Изменение идентификационных регистров SiS-овских IDE-шных контроллеров позволит обломить большинство вредоносных программ (со старморсом во главе), рвущихся к прямому управлению дисками в обход системных драйверов.

    Правда, опять же, как и в случае с VIA, придется учитывать баг старфорса версий 3.4.6.x, <благодаря> которому он не смотрел на идентификационные регистры тех устройств, к управлению которыми приступал.

    Но это не повод для печали, т.к. по информации с bestmedia, с данными версиями стара прекрасно справляется StarForceNightmare версии 1.12.



    Почему не имеет смысла изменять регистры SATA-контроллера? Дело в том, что многие вредоносные программы (например, старморс) до сих пор не рискуют работать с SiS-овским SATA-шным контроллером напрямую, даже если он находится в Native IDE mode. Кстати, это касается так же интегрированных SATA-контроллеров других производителей (например, nVidia), программный интерфейс которых (P.I.F.) так же равен 85h.



    Специально для тех, кто не совсем все понял, рассмотрю практический примерчик.

    Итак, допустим у Вас сложилась одна из следующих ситуаций:

    Ситуация 1:

    1. CD/DVD-привод подключен на IDE-контроллер.
    2. На этот же контроллер подключен системный жесткий диск.
    3. Требуется спрятать привод от зловредных программ, но SFNightmare не помогает, а отключение всего контроллера по понятным причинам (см.пункт 2) невозможно.


    Ситуация 2:

    1. CD/DVD-привод подключен на IDE-контроллер.
    2. Необходимо заставить зловредные программы работать с этим приводом через системные драйвера.
    3. В качестве вредоносного софта, приложения выступает не старфорс версии 3.4.6.х. (Не забываем, что эта версия содержит ошибку, суть которой в том, что старморс не проверяет идентификационные регистры контроллера, которым собирается напрямую управлять). Если это условие не выполняется, то качаем с инета обновление.

    Примечание: В ситуации 2 безразлично, куда подключен системный жесткий диск.

    Расписываю по шагам:

    Лезем в Диспетчер устройств и выясняем PCI-адрес нашего IDE-контроллера. Он (контроллер) обычно называется "SiS 5513 IDE UDMA controller"



    Жмем свойства и на первой вкладке видим искомый PCI-адрес.



    Выяснение PCI-адреса нужного IDE-контроллера необходимо в случае, если этих контроллеров на материнской плате несколько (IDE+SATA, например).

    Скачиваем прогу WPCREDIT, запускаем ее.

    Жмем "Ctrl+D", либо в меню выбираем "Edit > Device", либо жмем на пиктограмму (седьмая слева).



    В появившемся списке выбираем устройство по PCI-адресу (в красной рамке).

    В моем случае это:

    Bus (шина) = 0
    Device (устройство) = 2
    Function (функция) = 5

    У Вас эти значения могут отличаться от моих.

    Контролируем правильность выбора устройства по надписи "IDE Controller" в правом верхнем углу.

    Выбираем регистр #57 (строка с этим регистром обозначена как 50, а столбец - 07). Должна получиться примерно такая картина:



    Бит 7 регистра 57 подсвечен белым и обведен красной рамкой.
    Чтобы изменить DeviceID устройства (обведен голубой рамкой), необходимо изменить этот бит с 1 на 0.
    Изменяем. Жмем кнопку "Set" справа.
    Подтверждаем изменения.

    Чтобы убедиться в том, что DeviceID изменился с 5513 на 5518, необходимо опять нажать Ctrl+D и выбрать из списка наш контроллер:




    Ну, вот, пожалуй, и вся процедура. Как видите, ничего сложного.
    При необходимости можно вернуть все в исходное состояние.

    Дополнение от 31.03.2006:

    Благодаря необычайной личной заинтересованности учаcтника форума acaN? была найдена информация о способах смены регистра DeviceID IDE-контроллера на некоторых других южниках от SiS.

    Цитирую (практически полностью) мое сообщение в форуме на эту тему:
      acaN?
      цитата:
      "Fortunately the 5513 can be 'unmasked' by fiddling with some config space
      bits, changing its device id to the true one - 5517 for 961 and 5518 for
      962/963."

      Т.е. Device ID меняется...


      Спасибо за ценнейшую наводку.

      Оказывается, DeviceID меняется на SiS962 / SiS963 так же, как и у SiS964 (который в моей статейке рассмотрен)
      Т.е. нужно сбросить в ноль бит 7 регистра 57h.

      На SiS961 / SiS961B теоретически DeviceID должен поменяться
      после установки в единицу бита 4 регистра 4Ah.

      По твоему скриншоту это будет выглядеть примерно так:



      Остается лишь кнопочку EDIT нажать
      Только учти, что сразу изменения DeviceID ты не увидишь.
      Для проверки выбери опять устройство через "Select device..."



      На SiS961 / SiS961 rev. B вместо 5518h будет 5517h.

      ЗЫ: Вот документ, на основании которого я делаю такие предположения.



    Пользуясь случаем, выражаю acaN? свою благодарность за содействие в решении данного вопроса!

    Теперь на практике осталось выяснить следующее:

    1. Меняются ли SubCode и P.I.F. контроллеров на упомянутых южниках (961/961b/962/963) таким же способом, как в этой статье, или нет ?

    2. Проверить описанные в статье способы смены регистров на новых южниках (SiS965 / SiS966).




    Обсудить эту и другие статьи/записи с моей персональной страницы можно в соответствующей ветке конференции.

    Telegram-канал @overclockers_news - это удобный способ следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
    Оценитe материал

    Возможно вас заинтересует

    Популярные новости

    Сейчас обсуждают