SiliconImage vs. StarForce
которые не способны хранить в тайне
персональные данные пользователей своего форума
и которые при этом имеют наглость требовать
соблюдения тайны своей личной переписки.
![]() |
![]() |
![]() |
В этой статье описывается не отработанная/оттестированная технология, а всего лишь результаты моих собственных экспериментов. Я ни коим образом не призываю повторять их на Ваших собственных системах.
Особенно, если до сегодняшнего дня Вы ни разу не слышали о "PCI-регистрах", "адресах устройств" и прочих понятиях, которые впервые встретите в этом опусе.

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

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Не секрет, что в последнее время на рынке появились программные продукты (достойные, скорее, термина "полуфабрикаты"

- Если "железо" им не знакомо, то они общяются с ним, как и все добропорядочные программы, через системные драйвера.
- Если "железо" кажется им знакомым, то они пытаются работать с ним напрямую через свои самопальные дровишки, наглым образом обходя системные драйвера и драйвера производителей самого "железа".
Естественно, надежность вышеописанного подхода вызывает большие сомнения и опасения.
Далеко не всем пользователям (и я не исключение) нравится подобная ситуация и они всячески пытаются противодействовать такому произволу.
Один из вариантов заставить подобные сомнительные программы работать через системные драйвера -- скрыть от них истинное происхождение и назначение железа.
Такой трюк возможен, но, к сожалению, далеко не всегда.

Для начала неплохо было бы разобраться, как система определяет и идентифицирует устройства.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Большинство видеокарт, звуковух и прочих контроллеров независимо от исполнения (PCI, AGP, PCI-E) для системы выидны как PCI-устройства.
Каждое PCI-устройство обладает своей специфической памятью с особым доступом к ней (PCI Configuration Space), состоящей из 256-ти однобайтовых регистров (т.н. PCI-регистров).
Именно по некоторым из этих регистров (VendorID,DeviceID,ClassCode, иногда еще SubVendorID,SubSysyemID) операционная система и идентифицирует устройство. Будем в дальнейшем называть эти "некоторые регистры" идентификационными.
Взглянуть на содержимое PCI-регистров можно разными способами. Но самый популярный и удобный -- с помощью программы WPCRedit.

Скачать последнюю версию можно с сайта автора этой замечательной программы: http://www.h-oda.com/ (раздел Downloads)
Прямая ссылка на версию 1.4.
Последний всплеск интереса к этой утилите произошел во времена расцвета процессоров AMD K7. (Все, что вы хотели знать о режиме BUS Disconnect (part 2) by Герман Иванов -- настоятельно рекомендуется к прочтению)
![]() |
![]() |
![]() |
Но вернемся к сомнительным вражеским программам.
Они пользуются теми же способами для идентификации железа, что и операционная система. Информацию они получают из тех же регистров VendorID, DeviceID и ClassCode (+ иногда SubSystemID).
Т.е., чтобы скрыть от подобных зловредных программных продуктов истинное происхождение железки, необходимо каким-либо способом изменить содержимое упомянутых регистров.
Как правило для большинства устройств это невозможно.
Но из любого правила есть исключения

Примеры:
- Если мне не изменяет память, часть моделей видеокарт (а может и все) фирмы nVidia поддерживают смену некоторых PCI-регистров (DeviceID, например) через прошивку новых биосов.
- Некоторые видеокарты фирмы ATI так же поддерживают смену PCI-регистров через биос. Но только частично.
Для того, чтобы изменить некоторые биты того же DeviceID приходится поработать паяльником - Сетевые карты на базе чипов Realtek RTL8139 (не D) хранят информацию по некоторым своим регистрам (DeviceID, VendorID) в отдельной 128-ми байтной микросхемке флэш памяти, где до них при особом желании можно добраться
Одному из подобных примеров как раз и посвящена эта статья.
![]() |
![]() |
![]() |

![]() |
![]() |
![]() |
Полное описание моих злоключений есть в одной из записей.
В этой же статье я приведу лишь их укороченный вариант.
Начнем с того, что одна мерзопакостная программулина, имя которой мне лишний раз противно здесь упоминать

* в одном случае работала через системный дайвер,
* а в другом -- через свой собственный.
Отличались эти случаи лишь в настройками биоса для САТА-конроллера: [ RAID] / [ NON_RAID].
Заинтригованный, я полез смотреть PCI-регистры. Разница была лишь в регистрах, отвечавших за CodeClass (регистры с 2Сh по 2Fh)!!!
Причем, в первом случае класс кода был стандартный ИДЕшный (01/01/80), а во втором неопределенный, без стандартного программного интерфейса (01/04/00, вроде такой).
Собственно, после такого "открытия" я начал обращать пристальное внимание на класс-код.
Выяснилось, что в большинстве случаев упомянутая неназываемая программа работает напрямую с контроллерами, имеющими класс-коды 01/01/ 8A ( standard mode) и 01/01/ 8F ( enchansed mode для интеловских встроенных IDE/SATA контроллеров).
Зато код класса 01/01/ 85 (SATA на nForce3/4) ей оказался не по зубам !

В ходе дальнейших эксперименов так же выяснилось, что код класса, точнее код программного интерфейса, для встроенных IDE контроллеров от интела и н-видии можно менять (предварительно отключив сам контроллер через " Диспетчер устройств" ( !)) в ограниченных пределах: 8A/8B/8E/8F. Т.е. можно было изменять 0-й и 2-й биты (маска: 0101b).
Правда при значениях 8Bh и 8Eh контроллер определялся, и драйвера на него ставились (мелкософтовские и от производителя), но вот подцепленные к нему устройства (харды и сидюки) не виделись

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


В дальнейшем мой интерес привлек один из двух имевшихся у меня IDE/RAID контроллеров. От исследований Promise FastTrack100TX2 я сразу же (временно) отказался, т.к. это чуто не удалось пока заставить работать с CD/DVD приводами

А вот с IDE контроллером на SiliconImage SiI0680 я разобрался почти по-полной программе

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Свои разборки с IDE-контроллером SilliconImage SiI0680 я начал с поиска и прошивки IDE биоса (с поддержкой ATAPI).
Последнюю версию (3.2.10) нашел здесь (67Кб)(насчет "последней" могу и ошибаться

Универсальный прошивальщик для девайсов с силиконовскими чипами лежит здесь: { http://www.siliconimage.com/docs/SiI3x12A-PC%20Serial%20ATA%20(SATA)%20BIOS%20Flash%20Utilities.zip} .
Драйвера (версии 1.0.0.12, 113Кб) под перешитый в IDE девайс нашел там же.
Попытка в лоб изменить регистры, относящиеся к идентификации устройства, не увенчалась успехом. Но я не стал огорчаться.

Практика показывает, что отчаиваться можно только тогда, когда не удается найти даташит (полную спецификацию) на микросхему, использованную в устройстве, или ее предшественницу.
Как и подсказывало чутье, полный даташит на сам чип SiI0680 я не нашел.
Зато по наводке с форума ROM.BY удалось отыскать полное описание на его предшествекнника: SiI0649 !!!
Это уже полдела.
В этом описании страница 40 (6-5) содержала описание заветного регистра !
Им оказался регистр #4Fh. Его бит #2 позволял открывать/закрывать регистры кода класса на запись!

Осталось только проверить, сработает ли способ, предназначенный для SiI649, на моем SiI0680. На деле оказалось, что нифига не сработал.

Но это меня не смутило: раз возможность менять класс-код была на семействе 640-х чипов, то наверняка она осталась и на 680-м !
Решено было попробовать поискать этот чудо-регистр среди других регистров.
Перебор начал с нулевых регистров, переводя их значения в FFh и проверяя: не открылись ли на запись регстры класса кода.
В итоге нужный регистр-переключатель был найден !!!!!!
Им оказался регистр #40h бит #0.
К пущей радости выяснилось, что задание значения этого бита = 1 открывает доступ на изменение практически ВСЕХ ( !) идентификационных регистров, кроме VENDOR_ID.
А именно:
DEVICE_ID -> регистры #02h,#03h
CODE_CLASS:
BaseClass -> #0Bh
SubClass -> #0Ah
ProgramInterface -> #09h
SUBVENDOR_ID -> регистры #2Ch,#2Dh
SUBSYSTEM_ID -> регистры #2Eh,#2Fh




Что это дает ? Многое!
Простыми словами:
если есть какая-либо вредоносная программа или драйвер (типа старморса), которая вероломно вознамерится напрямую, в обход системных драйверов управлять устройством (IDE-контроллером),
то эту прогу/драйвер практически всегда (!) можно грубо обломить,
изменив вышеперечисленные идентификационные регистры !!!
Но это только пол-дела...
К сожалению, в подобной ситуации обломится не только "мерзкая программулька", но и операционная система, т.к. она тоже будет в затруднении: что перед ней за устройство и какие ему драйвера нужны ?
Но это затруднение легко разрешить, если пропатчить исходные драйвера, подогнав в них под нужные идентификационные данные.
(как это сделать с драйверами для SiI0680 будет подробно описано далее)
Конечно, если просто напросто требуется скрыть IDE-контроллер не только от глаз сомнительных программ, но и вообще от всей системы, то тогда патченьем драйверов можно и не заморачиваться.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Но это все в теории хорошо. А как же безболезненно реализовать все это на практике?
Разобьем задачу на 2 этапа:
1) модификация драйверов;
2) изменение идентификационных PCI-регистров контроллера.
Заранее договоримся, что изменять будем только DEVICE_ID c 0680 на 068 7 (ну и SUBSYS_ID тоже).
VEN_1095&DEV_0680&SUBSYS_06801095 => VEN_1095&DEV_068 7&SUBSYS_068 71095
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Рассмотрим на примере драйверов версии 1.0.0.12 (113KB).
Список файлов, идущих в архиве с драйверами:
pnp680.cat -- не не понадобится, вообще можно стереть, чтоб не путался
SilSupp.cpl -- изменять не нужно
SIISUPP.VXD -- файл для Win9x, пропускаем
следующие файлы изменения не требуют (надо объяснять почему ?

680 Dvr Rel Notes.doc
DriverLanguageMap.xml
readme.txt
TxtSetup.oem -- требуется только при установке винды (NT/XP) на диск, подсоединенный к контроллеру. Если такая необходимость возникнет, можно изменить строку:
id = "PCI\VEN_1095&DEV_0680&SUBSYS_06801095", "PnP680"
на такую:
id = "PCI\VEN_1095&DEV_068 7&SUBSYS_068 71095", "PnP680"
![]() |
![]() |
![]() |
SI680.inf -- один из ключевых файлов
Меняем все вхождения "0680" на "0687".
На будущее: замену нужно производить только там, где "идет речь" именно о Device_ID, а не о названии переменных.
![]() |
![]() |
![]() |
pnp680.mpd
pnp680.sys
Самый сложный этап. Практика показала, что эти два файла нужно патчить в обязательном порядке! К счастью, оказалось, что они абсолютно одинаковы.
Т.е. пропатчить достаточно лишь один из них, а второй просто скопировать.
Поскольку работе с дизассемблерами я не обучен, то пришлось обходиться лишь HEX-редактором.
Ищем в pnp680.sys все HEX вхождения "80 06".

Оно быстренько находится (обведено красным).

Предполагаем, что это наш DeviceID
На будущее замечаем рядышком замечаем вхождение "95 10" (обведено желтым). Скорее всего это наш VendorID. Такое соседство лишь подтверждает наше предположение.
На самом деле, в этом файле есть еще одно вхождение "80 06".
Но практика (критерий истины

Достаточно переправить первое вхождене с "80 06" на "8 7 06".
В первый раз я сдуру произвел правку прямо в хекс-едиторе.

Естественно, винда забраковала такой "драйвер", написав что он поврежден.
Дело в том, что каждый исполняемый файл защищен CRC, который, естественно, надо также пересчитывать после правки, как, например, это делает рива-тюнер при работе с патч-скриптами SoftR9x00.
Собственно, не зря я вспомнил RivaTuner, т.к. решил воспользоваться для выхода из сложившейся ситуации помощью именно этой замечательной программы.
Ничего не поделаешь -- не зная структуры SYS-файла приходиться пользоваться чужими наработками.

Несколько лет назад я уже прибегал к услугам ривы. Так что навык подгонки скриптов у меня уже имеется.
Рассмотрим структуру типичного патч-скрипта:
{RivaTuner\PatchScripts\ATI\SoftR9x00\SoftR9x00 w2k.rts}
[Common]
SrcFile= ati2mtag.sys
BakFile = ati2mtag.old
HlpFile= SoftR9x00.rth
MakeCRC = 1
Packed= 1
DstVar0= force RADEON 9700 capabilities
DstVar1= force RADEON 9500 capabilities
DstVar2= force RADEON 9800 capabilities
Src0= 68 C0 03 00 00 FF B0 00 00 00 00 E8 00 00 00 00 C1 E8 10
SCM0= FF FF FF FF FF FF FF 00 FF FF FF FF 00 00 00 00 FF FF FF
Dst0_0 = 66 8B 40 04 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
Dst0_1 = 66 8B 40 04 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
Dst0_2 = 66 8B 40 04 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
Src1= 83 F8 40 75 00 66 81 BD 00 FF FF FF 02 10 75 00 0F B7 85 02 FF FF FF
SCM1= FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
Dst1_0= 0F B7 85 02 FF FF FF 66 25 F0 F0 66 0D 04 0E 66 89 85 02 FF FF FF 90
Dst1_1= 0F B7 85 02 FF FF FF 66 25 F0 F0 66 0D 04 01 66 89 85 02 FF FF FF 90
Dst1_2= 0F B7 85 02 FF FF FF 66 25 F0 F0 66 0D 08 0E 66 89 85 02 FF FF FF 90
- SrcFile- файл, который патчим; под таким же именем записывается пропатченный в итоге файл;
- BakFile - имя, в которое переименовывается оригинальный файл перед модификацией
- HlpFile - необязательный файл с кратким описанием плагина; лежит в RivaTuner\Help\PatchScripts\*.rth
- MakeCRC - если =1, то производить пересчет CRC после модификации;
- Packed - если =1, то исходный файл может присутствовать в сжатой форме с расширением *.SY_
- DstVarX - X-й вариант выбора
- Src0 - первая исходная цепочка байтов, которую нужно заменить;
- SCM0 - маска;
* если равна 00h, то символ первого вхождения (расположенный выше, в предыдущей строке) безразличен, т.е. может быть любым;
* если равна FFh, то символ первого вхождения из строки выше обязан присутствовать в заменяемой цепочке; - SrcN - N-ая цепочка, которую необходимо заменить
- Dst0_0 - цепочка байтов для первого вхождения, на которую производится замена в случае выбора первого варианта;
- DstN_X - цепочка байтов для N-ого вхождения, на которую производится замена в случае выбора X-го варианта;
В нашем случае необходимо заменить строку, частью которой является вхождение " 80 06".
Длина строки может быть любой, но не слишком короткой.
Достаточно 3-х...4-х байт, но я взял всю строку из 16 байт:
" 95 10 75 2E 66 81 78 02 80 06 75 22 80 3D 54 50"

Итого, для единственного варианта выбора получаем:
{RivaTuner\PatchScripts\ATI\SoftR9x00\patch_pnp680_w2k.rts}
[Common]
SrcFile= pnp680.sys
BakFile = pnp680.old
HlpFile=
MakeCRC = 1
Packed= 0
DstVar0= force DEVICE_ID=0687h capabilities
Src0= 95 10 75 2E 66 81 78 02 80 06 75 22 80 3D 54 50
SCM0= FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Dst0_0 = 95 10 75 2E 66 81 78 02 87 06 75 22 80 3D 54 50
;Vendor_ID^^^^^ Device_ID ^^^^^ заменяемое и заменяющее вхождения!



реклама
Browsing for file pnp680.sys... selected 1, 0, 0, 12, 37031 bytes
Using native patch installation mode 0
WARNING: Certified patch script not found, using common patch script...
00000a90> matched sequence has been replaced
95 10 75 2e 66 81 78 02 80 06 75 22 80 3d 54 50
95 10 75 2e 66 81 78 02 87 06 75 22 80 3d 54 50
File has been successfully patched and saved as Pnp680.sys
Backup copy has been saved as pnp680.old
В эту же папку кидаем модифицированные Pnp680.sys, Pnp680.mpd и SI680.inf.
Все, драйвера готовы к установке!
Дальнейшая эксплуатация показала их полную работоспособность.
Модифицированные файлы выложены здесь (26Kb).
-
[18.04.2006]: Обновленный и более предпочтительный вариант лежит
здесь.(50Kb)
![]() |
![]() |
![]() |

Вот фрагмент оригинального кода:

Красным обведен предполагаемый DEV_ID, желтым - VEN_ID.
Тот же фрагмент после модификации патч-скриптом:

Судя по всему, мне повезло и я угадал правильно.

Измененный байт является не кодом, а данными.
Больше вхождений данных "680h" в тексте не наблюдается.
![]() |
![]() |
![]() |
ПРЕДУПРЕЖДЕНИЕ !
Перед установкой модифицированных драйверов весьма желательно удалить все следы старых, оригинальных драйверов !
Удаление драйверов -- дело не такое уж и простое, как может показаться.
Но в данном случае мене повезло, т.к. особых проблем не возникло.
Для удаления дров от SiI0680 необходимо:
- Отключить контроллер "Silicon Image SiI0680 ATA 133" в диспетчере устройств.
- Удалить это устройство
Удалить из системы файлы, входящие в драйвера. В данном случае требуется найти и уничтожить лишь модифицированные нами файлы (sys, inf):
- Найти и удалить в папке WINDOWS файл pnp680.sys. Обычно он распологается в папке "WINDOWS\SYSTEM32\DRIVERS\".
- Найти в папке "WINDOWS\INF" файл SI680.inf (его там может и не быть)
- Найти в папке "WINDOWS\INF" среди OEM*.INF файлов те, которые содержат в себе строку pnp680.sys. Вместо звездочки должно быть некое число.
Дело в том, что файлы OEM*.INF -- это те же SI680.inf, переименованные операционной системой. Вероятно, она хранит эти файлы на всякий случай, ведь места они занимают немного, а в случае острой необходимости помогут опознать устройство. Но нам в данном случае этого не требуется -- наличие подобных переименованных файлов только вредит нашей задумке
Если файлы не удаляются из под винды, то сделать это можно из под ДОСа, если на винте файловая система FAT32, или при загрузившись с CD-ROM'а с WinPE (или аналогичных по назначению загрузочных CD) в случае, если система использует NTFS.
Кстати, файлы удалять вовсе не обязательно -- достаточно перенести их в другое место или просто заархивировать

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
ПРЕДУПРЕЖДЕНИЕ !
Изменять идентификационные регистры устройства относительно безопасно только если это самое устройство (или удалено) отключено в "Диспетчере задач" !
Редактирование некоторых регистров устройства может обрушить вашу систему (в худшем случае) или привести к непредвиденной перезагрузке. Поэтому старайтесь не редактировать неизвестные для вас регстры. В противном случае готовтесь к худшему

![]() |
![]() |
![]() |
Сначала ручной способ:
I. Перед непосредственной модификацией регистров устройства в обязательном порядке
необходимо это самое устройство отключить в "Диспетчере устройств"!!!
После отключения IDE-контроллера SiI0680 в диспетчере если к нему подключен CD/DVD привод (а он наверняка уже подключен

Придется подчиниться.
После перезагрузки устройство будет уже отключено:

II. Собственно нужные PCI-регистры изменить несложно:
- запустили wpcredit
- выбрали нужное устройство
(по полям vendor_id/device_id, либо по координатам BUS/DEVICE/FUNCTION)
- изменили нулевой бит регистра #40h с 0 на 1
- модифицировали нужные идентификационные регистры
в нашем случае меняем:
байт #02h с 80h на 87h (этот байт часть device_id)
байт #2Eh c 80h на 87h (этот байт часть subsystem_id) - обращаем значение 0-го бита регистра #40h обратно в ноль
С настройкой регистров закончили.
III. Теперь удаляем в Диспетчере устройств контроллер, отключенный на I-м этапе.
Сразу в контекстном меню выбираем "Обновить конфигурацию оборудования".
Будет найдено новое устройство, для которого необходимо установить
пропатченные драйвера.
После установки драйверов обнаружится и подключенный к контроллеру сидиром!
Вуаля!

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

Лениво ? Конечно !
Для ленивых существует другой, более короткий путь

Полуавтоматический способ:
Самую рутинную часть метода (изменение регистров) можно существенно облегчить, если воспользоваться другой программой WpcrSet (автор у нее тот же, что и у WpcrEdit, и распространяются зачастую эти две утилиты в одном архиве)
Программа позволяет автоматически во время загрузки Windows изменять нужные нам PCI-регистры.
Перед тем, как использовать WpcrSet, необходимо установить используемый ею драйвер. Для этого запускаем идущий в комплекте файл INSTDD.EXE.


После перезагрузки запускаем WpcrSet.exe :

Выбираем Start и начинаем заносить адреса изменяемых регистров и их новые значения. Начнем с регистра #40:

Адрес устройства (bus/device/function) смотрится либо в WpcrEdit (левый верхний угол), либо в Device Manger'е (шина/устройство/функция):

![]() |
![]() |
![]() |
-
ВНИМАНИЕ: Адрес устройства вещь относительно непостоянная. Например, если переткнуть PCI-контроллер из одного слота в другой, то его адрес на шине PCI скорее всего изменится.
Поэтому всегда проверяйте адрес устройства после неренесения контроллера из одного слота в другой или при добавлении/отключении других PCI-устройств !!!
Этот недостаток можно было бы исправить, если бы устройство выбиралось не по адресу на шине, а по своим изначальным идентификационным данным (VendorID/DeviceID). Но к большому сожалению такого способа в WpcrSet не предусмотрено

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

![]() |
![]() |
![]() |
После задания всех изменений должна получиться примерно такая картина:

Ну вот и все. Можно перезагружаться.
После перезагрузки если оригинальные драйвера были полностью искоренены (бесследно удалены из системы), то винда найдет некий "контроллер запоминающего устройства":

Удаляем его. В Диспетчере устройств жмем "Обновить конфигурацию оборудования". Будет снова найдено наше устройство.
Если модифицированные драйвера еще не устанавливались, то ставим их.
Все, устройство готово к работе!
Недостаток этого способа: каждый раз после перезагрузки приходится удалять неопределенный "контроллер запоминающего устройства." Собственно, поэтому я и назвал способ " полу-автоматическим".
Дело в том, что во время загрузки винда обнаруживает наш контроллер SilicinImage раньше, чем WpcrSet изменяет в нем идентификационные регистры

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Полностью " автоматический" способ можно получить, если выполнять процедуру изменения регистров до старта операционки. Сделать это можно модифицировав:
* либо биос материнской платы;
* либо биос самого контроллера.
Само собой, второй вариант более безопасен, потому и более предпочтителен

Объем исполняемого кода займет скорее всего меньше килобайта, поэтому проблем с его размещением возникнуть не должно.
Теоретически можно поместить процедуру модификации регистров в загрузочном секторе диска, но я такими трюками никогда не занимался, потому и другим советовать не буду.

Если в случае с ручным и полуавтоматическим способами у вредоносных программ еще был шанс на успешное противодействие, то с внедрением "автоматического" варианта этот шанс резко устремляется к нулю. (им остается разве что драйвера блэклистить

Кстати, в случае модификации биоса самого контроллера говорить о каком-либо "способе" уже не приходится -- это будет полностью работоспособное и самостоятельное устройство, о существовании которого, правда, даже сам производитель может не подозревать

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Что я имею ввиду под идеальным контроллером ?
(в контексте данной статьи, естественно).
Устройство, с которым напрямую имеет возможность работать только драйвер операционной системы. При этом всем остальным программам приходится (хотят того их разработчики или нет) работать с этим устройством исключительно через драйвер операционной системы.
Вот некоторые характеристики, которыми, на мой взгляд, должен обладать идеальный PCI-контроллер:
- Возможность свободно изменять ВСЕ идентификационные PCI-регистры (VendorID/DeviceID/ClassCode/SubVendorID/SubSystemID).
- {bios setup} Возможность настраивать эти регистры на этапе POST при помощи специальной утилиты, прошитой в биос контроллера.
В флэшку практически каждого современного RAID-контроллера уже вшиты такие SETUP-утилиты. Нужно лишь добавить в них соответствующие пункты по выбору и изменению нужных идентификационных регистров. - Драйвера для идеального контроллера должны комплектоваться утилитой, позволяющей настраивать их на те же идентификационные данные, на которые настроен контроллер.
Т.е. занося данные в идентификационный регистр контроллера через сетап-утилиту, мы должны на те же самые данные настроить драйвера, чтобы они смогли идентифицировать железку. - {полиморфизм
} Желательно защитить драйвера устройства, чтобы затруднить возможность постороннему софту определить их наличие в системе. Это необходимо, чтобы по установленным драйверам невозможно было точно определить модель железки. Ну и от занесения в black-листы эта предосторожность тоже убережет.
Из всех известных мне на текущий момент контроллеров рассмотренный в этой статье SiliconImage SiI0680 наиболее близок к предъявляемым требованиям. Но не всем и не в полной мере: практически полностью выполняются только первое, но зато самое главное требование по изменению регистров! Реализация остальных возможна силами энтузиастов, если таковые вдруг объявятся.
Остается только сказать ОГРОМНОЕ СПАСИБО фирме-производителю столь гибкого в настройках продукта. Надеюсь, эта статья послужит дополнительной заслуженной рекламой продуктам SiliconImage. Ведь подобными замечательными свойствами обладают не только чипы SiI064x/SiI0680, но и широко распространенный SiI3112 (уже лично проверил, "золотой бит" тот же, что и для SiI0680: reg#40 bit0). Завтра собираюсь проверить SiI3114 -- подозреваю, что результат будет положительным.

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


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


---
Pskov

![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Дополнение от 24-04-2006:
Меня периодически спрашивают: "ЗАЧЕМ НУЖЕН ВЕСЬ ЭТОТ ОГОРОД ?".
Ответ на этот вопрос я поместил здесь.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Дополнение от 06-05-2006:
Вот модифицированный биос:
(Размер: 105.4 Кбайт)
Вроде работает.

Хотя времени на серьезное тестирование не было.
Пояснения к архиву (ReadMe):
цитата:
ВСЕ ОПЕРАЦИИ НЕОБХОДИМО ПРОИЗВОДИТЬ ТОЛЬКО В D O S !!!
ПРЕДУПРЕЖДАЮ!
Я не гарантирую 100% работоспособность системы после перепрошивки!
Все, что Вы делаете -- Вы делаете на свой страх и риск!
Я снимаю с себя всякую ответственность за возможные последствия!
======================================================
ЗАЧЕМ ЭТО ВСЕ НУЖНО ?
Файл R3210.687 содержит код, который будучи прошит во флэшку IDE-контроллера SiliconImage SiI0680A,
при загрузке системы на этапе POST изменяет его конфигурационные регистры
DeviceID и SubSystemID c 0680h на 0687h.
После прошивки R3210.687 для контроллера потребуется установить драйвера из папки DRIVERS.687.
ВНИМАНИЕ!
RAID, если он был настроен, может перестать функционировать!
КАК ПРОШИТЬ-ТО ?
Командная строка для прошивки:
UPDFLASH.EXE R3210.687
(далее со всем соглашайтесь [Y])
ЗАЧЕМ НУЖНА ПАПКА UNDO ?
Папка UNDO нужна для того, чтобы произвести обратную
прошивку биоса на оригинальный (смена ID с 0687h на 0680h)
Будет прошит оригинальный IDE-шный или RAID-овый биос.
---
xKVtor, май 2006
Кстати, используя примененный в данном случае принцип можно модифицировать практически любой биос.
В том числе биос видеокарт, наподобие того, как это делал Serj в своем Video BIOS extender.
![]() |
![]() |
![]() |
Дополнение от 15-05-2006: (накипело)
Я уже устал повторять.

По поводу IDE-шных контроллеров на nForce'ах (1/2/3/4/5) мне нечего сказать.
Так же как и про интеловские контроллеры.
Если что появится -- сразу отпишусь.
Единственное, что могу посоветовать владельцам плат с южными мостами ICH5 (обычно материнки на i848/i865), у которых HDD и CD/DVD-приводы висят на одном IDE-контроллере, но на разных шлейфах (каналах):
если вас ломает каждый раз при необходимости лезть в системник и выдергивать шлейфы, то вспомните, что в биосе практически каждой материнки (с ICH5) есть возможность переключить контроллер жестких дисков в COMBINED mode и тем самым скрыть один из IDE-каналов (на выбор).
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Линки по теме:
SiliconImage vs. StarForce
- Меняем порядок загрузки драйверов Windows.
- Как выполнить свой программный код до запуска Windows, если нет возможности разместить его в BIOS.
VIA vs StarForce
SiS vs. StarForce
![]() |
![]() |
![]() |
---
Обсудить эту и другие статьи/записи с моей персональной страницы можно в соответствующей ветке конференции.
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Сейчас обсуждают