VIA vs. StarForce

13 марта 2006, понедельник 01:49
для раздела Блоги


Заметка является продолжением статьи "SiIiconImage vs StarForce"
(настоятельно рекомендую перед прочтением этой статьи ознакомиться с предыдущей).

!!! FOR POWER USERS ONLY !!!


Предупреждение!


В этой статье описывается не отработанная/оттестированная технология, а всего лишь результаты моих собственных экспериментов. Я ни коим образом не призываю повторять их на Ваших собственных системах.
Особенно, если до сегодняшнего дня Вы ни разу не слышали о "PCI-регистрах", "адресах устройств" и прочих понятиях, которые впервые встретите в этом опусе.

Статья рекомендуется исключительно для ознакомительных целей !
Иначе вреда от ее применения на практике будет больше, чем от программ, методы противодействия которым здесь описываются.

Разумеется, я снимаю с себя всякую ответственность за все то, что Вы учините со своим железом, прочев это мое скромное творение !

Также заранее прошу прощения за все допущенные грамматические ашипки, очепятки и неточности некоторых формулировок.




После появления предыдущей статьи кое-кто упрекнул меня в ее малой практической ценности. Мол, контроллеры на чипах SiliconImage есть сегодня далеко не в каждом компе.

В свое оправдание могу сказать, что я не ставил перед собой задачу в одной статье привести исчерпывающие практические рекомендации по всему существующему железу.

Я лишь показал направление дальнейших исследований - поиск возможностей для изменения идентификационных PCI-регистров различных IDE/SATA-контроллеров.

А реализация идеи на продуктах SiliconImage - это лишь иллюстрация, частный случай.

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

И уже начинаю опасаться, что мне одному придется тянуть лямку исследователя.

Что ж, если прошлая статья была интересной, но малопрактичной, то в этой наоборот - практики будет предостаточно. А вот с интересом... как получится.





Итак, как все наверное уже догадались, в этой заметке речь пойдет об интегрированных IDE/SATA контроллерах фирмы VIA.

Конечно, сегодня продукция этого брэнда не так популярна, как несколько лет назад. Но несмотря на это VIA все еще продолжает удерживать неплохую долю рынка чипсетов, отставая по этому показателю только от Intel'а и от nVidia. А если говорить о бюджетном сегменте, то у VIA кроме Intel'а серьезных конкурентов пожалуй и нет

Так что о практической ценности материала, изложенного в данной статье, можно особенно не беспокоиться. Найти ему применение будет проще, чем в случае с SiliconImage.



Как, надеюсь, всем известно, в современных чипсетах контроллеры жестких дисков физически располагаются в так называемом "южном мосте" ("south bridge").

Мне довелось потестировать материнские платы на чипсетах от VIA с тремя различными южными мостами:

  • VIA VT8233
  • VIA VT8237R / VIA VT8237R Plus (в чем их отличие, выяснить пока не удалось)
  • VIA VT8251




    Примечание: Буква R в обозначении подразумевает поддержку контроллерами, встроенными в эти южники, RAID-овых функций.

    На рынке подержанного железа сейчас еще можно встретить материнки с южными мостами VT8235, и даже с VT8231 (не вижу смысла вспоминать маркировку еще более ранних изделий).



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

    Ну, не буду томить и сразу перейду к рассказу о результатах моих скромных изысканий.

    Особенность #1


    Первое, что удалось выяснить:

    По крайней мере, начиная с версии южника VT8237 для встроенных контроллеров жестких дисков можно изменять подкласс (SubClass) устройства (регистр #0Ah).

    Чтобы получить возможность изменять этот подкласс, предварительно необходимо сбросить в ноль бит 7 регистра #45h.



    В документации про этот трюк упоминается, но только в отношении SATA-контроллеров. На практике оказалось, что он прекрасно срабатывает и на IDE-контроллерах!

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



    * для IDE-контроллера в пределах от 00h до 0Fh.
    * для SATA-контроллера в пределах от 00h до FFh.

    Почему для SATA диапазон больше, чем для IDE, я не знаю. Самому интересно

    Совершенно случайно обнаружился еще один интересный момент:

    • если изменить регистр подкласса (#0Ah) в любое значение, не равное 04h (например, FFh), то значение регистра программного интерфейса (#09h) автоматически устанавливается в 8Fh !

    • если установить значение подкласса (регистр #0Ah) равным 04h, то значение регистра программного интерфейса (регистр #09h) автоматически устанавливается в 00h !




    Особенность #2.


    Далее выяснилось следующее:

    У контроллеров, встроенных в южные мосты начиная по крайней мере с VT8233, можно свободно менять некоторые немаловажные идентификационные регистры !

    Начнем с того, что для этих регистров существуют регистры-двойники.

    Внося изменения в регистры-двойники, мы тем самым изменяем сами идентификационные регистры !!!

    Вот список соответствий:
    НазваниеРегистрыРегистры-двойники
    DeviceID02h, 03hD2h, D3h
    RevisionID08hD0h
    SubVendorID0Ch, 0DhD4h, D5h
    SubSystemID0Eh, 0FhD6h, D7h



    В 16-ти битном виде:


    К сожалению, идентификационный регистр VendorID, как и в случае с SiliconImage, изменить невозможно. По этому параметру встроенные контроллеры от VIA до <идеального контроллера> так же не дотягивают

    В документации регистры-двойники называются backdoor регистрами. Кстати, упоминание о них (причем, без каких-либо пояснений об их истинном назначении) есть только в доках для VT8233. Из документации для последующих чипов эта интересная деталь загадочным образом испарилась.



    Замечание:

    Как оказалось, внешние PCI-контроллеры на чипах VIA VT6421 обладают теми же самыми способностями (возможность менять подкласс устройства и некоторые идентификационные регистры), что и контроллеры, интегрированные в чипсет.





    Вот только адреса регистров-двойников у VT6421A несколько иные:

    НазваниеРегистрыРегистры-двойники
    DeviceID02h, 03hEAh, EBh
    RevisionID08hE8h
    SubVendorID0Ch, 0DhECh, EDh
    SubSystemID0Eh, 0FhEEh, EFh


    Вполне допускаю, что замечание справедливо и для других ВИА-шных чипов, например, VT6410. К сожалению, сам проверить не могу.

    Правда, ценность обнаруженных свойств для внешних PCI-контроллеров пока невысока - редкая вредоносная программа рискнет работать с ними напрямую



    Практические замечания:

    1. Драйвера контроллеров никак не отреагировали на смену идентификационных регистров DeviceID, RevisionID, SubVendorID, SubSystemID.

      Т.е. винда продолжала жить своей жизнью и зависать или выпадать в BSOD не собиралась. Можно было сколько угодно копировать файлы с одного диска на другой, с сидирома на диск, и т.д.

      С одной стороны, это меня сильно озадачило.
      А с другой - очень порадовало, т.к. отпала необходимость отключения устройства в Device Manager'е.

    2. Единственное, от чего системе могло поплохеть - от смены программного интерфейса (регистр #09h) с 8Ah на 8Fh или наоборот.




    Практические испытания:

    Практические испытания проводились на нескольких продуктах, защищенных с помощью старфорса. Эта <защита> печально известна своим маниакальным стремлением к управлению железом напрямую, в обход системных драйверов.

    Конфигурация:

    В проводимых экспериментах CD-RW привод был подключен к IDE-контроллеру на материнской плате. В некоторых экспериментах жесткий диск висел на том же самом IDE-контроллере, в других - на SATA контроллере. На результатах это никак не сказалось.

    Испытывалось несколько материнок с разными южными мостами. Вот примерный список (на самом деле подопытных было немного больше):

  • EPoX 8KHA+ (VT8233)
  • ECS K8M800-M2 rev:2.0 (VT8237R)
  • MSI K8MM-V MS-7142 ver.1 (VT8237R Plus)
  • ASRock P4VM800 (VT8237R Plus)
  • ASUS P5V800-MX rev:1.01 (VT8251)

    Порядок проведения эксперимента:
    1. Запускалась винда.
    2. Запускались исследуемые программные продукты (с образа либо с оригинального диска в приводе, подключенного через другой RAID-контроллер).
      Результат запоминался.
    3. Затем внаглую менялись идентификационные регистры контроллера с помощью WPCREDIT.
    4. Запускались исследуемые программные продукты (с образа либо с оригинального диска в приводе, подключенного через другой RAID-контроллер).
      Результат запоминался и сравнивался с результатом пункта 2).


    Результаты исследований:

    Игры со старфорсом версий 3.5.10.x и более новые до изменения регистров настоятельно требовали переставить диск в другой привод.



    Но после модификации регистров становились более сговорчивыми и уже не надоедали своими дурацкими предложениями переставить диск туда, куда им заблагорассудится.

    Игры со старфорсом версий 3.4.6.x требовали переставить диск в другой привод невзирая на состояние идентификационных регистров контроллера.



    Последнему факту можно найти следующее объяснение.
    Судя по всему старфорс во время запуска игры не проверяет (!) состояние регистров контроллера.

    С одной стороны, нам от этого немного грустно.
    Но с другой стороны, еще более грустно должно быть разработчикам старфорса, т.к. подобная неразборчивость в будущем рано или поздно выйдет им боком. Баг это или фича ? Скорее всего первое.

    Спрашивается: откуда тогда в последнем случае старфорс берет информацию ? Сие мне не известно. Можно предположить следующее:

    • Либо из реестра. Наверняка там хранятся данные по идентификационным регистрам устройств на момент запуска винды.

    • Либо на этапе загрузки операционной системы драйвера старфорса сами опрашивают контроллер и запоминают его идентификаторы. А в дальнейшем вероятно используют для работы с контроллером только его PCI-адрес (шина/устройство/функция).

    Можно ли как то исправить ситуацию ? Вероятно, да. Если для защищенных продуктов существует обновление, содержащее так же обновленную/исправленную систему защиты. Качайте, устанавливайте, проверяйте.

    Но напомню: любом случае недоразумение под названием "старфорс" можно будет обойти так, как описано в предыдущей статье. Т.е., если пропатчить:

    • драйвера контроллера;

    • BIOS материнской платы, чтобы еще на этапе POST он менял нужные идентификационные регистры интегрированного контроллера.


    Кстати, сам код БИОСа вручную ковырять необязательно. Можно просто попробовать добавить в него дополнительную PCI-ROM'ку. Для многих БИОСов это практически стандартная процедура. Похожие модули уже присутствуют в БИОСах материнок со встроенными RAID-контроллерами на борту. Существуют даже специальные утилиты, позволяющие проделать операцию "вживления". Например, для биосов производства AWARD обычно используют тулзу под названием CBROM. (подробности см. на http://www.rom.by)

    Но это уже совсем другая история...




    У тех немногих, кто осилил статью до этого момента , наверняка возник вопрос: сможет ли приведенная здесь информация пригодиться на практике ? И имеет ли смысл со всем этим связываться ?

    Все зависит в первую очередь от конфигурации Вашей системы и от того, что Вы хотите получить в результате.

    • Если, например, у Вас в системе стоит SATA-жесткий диск и IDE-привод (или наоборот), то для того, чтобы спрятать привод, нужно лишь отключить контроллер, к которому он присоединен, в биосе или диспетчере задач.

      Т.е. приведенная в статье информация Вам в данном случае не понадобится

    • Если у Вас привод висит на IDE и требуется лишить вредоносные программы прямого доступа к нему (например, ради возможности использовать RMPS), то тогда да, советы из этой статьи вам помогут.

    • Если Вам требуется то же, что и в предыдущем пункте, но CD/DVD-привод висит на SATA, причем в биосе материнки отсутствует возможность перевести SATA в режим [RAID], то статья должна Вам помочь.

    • Если же у вас и системный жесткий диск, и привод подключены одновременно к IDE-контроллеру (неважно, на один канал или на разные), то в этом случае статья Вам просто необходима.

      Скрыть привод от системы не удастся, т.к. одновременно "исчез" бы и системный жесткий диск. Зато, изменив регистры, как описанно в этой статье, можно добиться того, чтобы вредоносные программы не лезли к IDE-контроллеру напрямую, а работали с ним через системные драйверы.


    И еще разок повторюсь:

  • Если простое изменение регистров не помогает, имеет смысл скачать с сайта издателя обновление к запускаемой программе.

  • Для достижения 100% эффекта, потребуется модифицировать биос и [желательно] драйвера.



    Приложение:

    Начиная с версии VT8237, южный мост стал совмещать в себе целых два контроллера жестких дисков: SATA и IDE.

    При этом в WPCREDIT они оба иногда (если SATA в режиме nonRAID/IDE) отображаются как IDE-контроллеры.

    Чтобы при редактировании не запутаться и случайно не отредактировать регистры "не того" контроллера советую первым делом заглянуть в "Диспетчер устройств" и выяснить адрес нужного контроллера на шине PCI. И только потом уже лезть в WPCREDIT.



    Можно обойтись без "Диспетчера устройств", если обратить внимание на то, что интегрированный во все южные мосты IDE-контроллер (виден в диспетчере обычно как "VIA Bus Master IDE controller") всегда имеет один и тот же DeviceID равный 0571h.

    Таблица соответствия чипов и DeviceID встроенных контроллеров.

    Chip NameSATAIDE
    VT8233---rev=06
    VT8237RDevID=3149h, rev=80rev=06
    VT8237R PlusDevID=3149h, rev=80rev=06
    VT8251RDevID=3349h, rev=00rev=07
    VT6421ADevID=3249h, rev=50---


    * Для встроенного IDE-контроллера DevID всегда равен 0571h



    И напоследок хочу передать огромное СПАСИБО:

    1. Участникам обсуждения предыдущей статьи на форумах Overclockers.ru и ROM.by. Благодаря проявленной вами заинтересованности в этой теме у меня нашлись силы на написание еще одного опуса

    2. Как обычно, фирме Comsel (Псков) за предоставленное для нечеловеческих экспериментов оборудование.




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

    Оценитe материал
  • Возможно вас заинтересует

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

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