Comments 64
По-моему, людей отпугивают не столько сложности разработки драйверов, как сложности получения на них сертификации от Microsoft.
Мне пришлось однажды по работе заниматься драйвером. Не с нуля разработать, а портировать под 64 бит. Это оказалось достаточно легко, но потом… Просто режим TestSigning работал в Windows 7, но в Windows 10 всё гораздо сложнее. Необходимо сначала особым образом вызвать перезагрузку системы, тогда при старте появится специальное меню. И там, в глубине, есть один пункт, который позволяет снять требование сертификации загружаемых драйверов. На один раз. При следующей перезагрузке процедуру необходимо повторить заново.
В конце концов всё заработало, и мы попытались связаться с Microsoft для выяснения стоимости и условий сертификации. Даже дозвониться до службы поддержки проблема — телефоны открыто не публикуются, а веб-интерфейс стремится перенаправить человека на форумы и т.д., где цены не публикуются, а условия указаны расплывчато. Ожидаемо, сотрудники телефонной поддержки даже не знали, что это такое — сертификация драйверов. После открытия бесчисленного количества тикетов и перенаправлений к другим сотрудникам в другие офисы и другие страны, наконец-то, удалось поговорить с кем-то, кто хоть чуть-чуть в курсе дела. Они обещали помочь, но… Перезвонили и сообщили, что «из соображений безопасности» до того, как наша фирма получит EV сертификат (который стоит около 2000$ и сам по себе не связан с Microsoft или сертификацией драйверов) с нами вообще не будут разговаривать, в том числе не назовут цену за получение ЭЦП драйвера от Microsoft.
Так и похоронили этот вопрос.
А у вас есть какая-либо информация о том, как подписать драйвер в Microsoft? Сколько это стоит, что для этого нужно? Правда ли, что нужно направлять железо, к которому разрабатывается драйвер, на тестирование в Microsoft?
Да, в Win10 есть режим (среди особых вариантов загрузки F8) «Отключить требование подписи драйверов», но у меня на указанной системе работало и просто после включения TestSigning (возможно, работает только в связке с отладочным режимом, честно говоря, не проверял).
По поводу сертификации ничего не могу сказать, никогда не было задачи разработать драйвер «в продакшн», но насколько я понял, главное условие — прохождение их тестов WHQL, про железо не слышал (странное требование, разработчик же может заглушку в железку прошить и толку от нее для MS примерно 0).
главное условие — прохождение их тестов WHQL
Тут вопрос, где они будут запускать эти тесты. Правила сертификации за последние годы несколько раз менялись в сторону ужесточения. Многие веб-страницы с информацией по теме (в том числе на сайте Microsoft) устарели.
Если я правильно понял результаты своего последнего поиска — то тесты должны исполняться на компьютере Microsoft. А поскольку драйвер не работает без железа — то в Microsoft необходимо выслать по почте железо, с которым будет работать драйвер. Может быть, вместе с компьютером. Там в тексте были слова «Submit your hardware». Может, их можно толковать как-то иначе, но бесплатно разъяснять сотрудники Microsoft отказались.
Мы бы и не против выслать в Microsoft железо. Но связанные с этим манипуляции со стороны Microsoft (вставить карточку в компьютер; включить; рисковать поломкой компьютера) требуют довольно высокой квалификации персонала и могут стоить немалых денег. Знать бы, какого порядка сумма. У нас просто решалась судьба проекта: сколько надо в него вложить денег для того, чтобы были дрова под новые версии Windows; и окупились ли бы эти вложения.
Если я правильно понял результаты своего последнего поиска — то тесты должны исполняться на компьютере Microsoft
Нет, все тесты исполняются у разработчика. Тестовая система собирает результаты, их потом нужно отправить в MS для сертификации.
Скорее всего, там есть какая-то базовая защита от подмены, но вряд ли серьезная. Большинство современных разработчиков драйверов не имеет ни хакерских способностей, ни желания ковыряться в чем-то без документации. Они просто более-менее изучили ядерные API и правила разработки, и пишут код так, чтобы он более-менее работал, даже не слишком понимая тонкости взаимодействия софта и железа. До типичного разработчика 80-90-х, который на все руки мастер, им очень далеко.
submission package подписывается с помощью ключа, привязанного к компании на dev portal
Да, только это не гарантирует подлинности результатов тестов.
Вы правы, так и есть. Это всё на веру, что драйвер приложенный в пакет и драйвер в результатах тестов один и тот же. Там были версии и хэши, насколько я помню, но их совпадения никто не проверял. Впрочем, нужно помнить, что hardware dashboard помнит все ваши отправки, а в cat вшиваются данные о вендоре, так что в теории MS легко может отследить факт подмены
О том и речь, что там нет абсолютной защиты. А главная цель attestation-signing, как я понимаю - этот самый учет, чтобы можно было оперативно отследить и заблокировать того, что вдруг начал гадить, умышленно или по недосмотру.
attested signing не сказать что далеко ушло дальше в данном вопросе, внешне всё то же самое, только пакета с тестами нет, да подпись на каталоге другого типа
Хм, а куда ему, по-Вашему, следовало бы уйти? :)
никуда, просто сложилось впечатление, будто вы считаете процесс аттестационной подписи более стойким к подобного рода хакам
А какого рода хаки, по-Вашему, вообще возможны в процессе аттестационной подписи?
имеется в виду, что раньше подразумевалось прохождение тестов и если пакет корректен и прикладываемые драйвера - целевые, то это хоть какой-то мизерный уровень их качества (ха-ха), в аттестационной это упразднили и всё на совести разработчика, что он согласен с условиями, где написано в духе "дайте слово что у вас драйвера не бажные" :) а так там как минимум можно любую либу подписать, не обязательно драйвер
Кстати, сейчас с подписыванием новая проблема - MS отключила многим (если не всем) разработчикам, зарегистрированным, как российские, доступ к Hardware Portal. Я с их поддержкой на эту тему бодаюсь уже месяц. Неделю назад получил последний ответ - "this issue it still investigated, you will be informed".
Зарегистрироваться как американец?
Лет десять назад такой совет еще худо-бедно котировался, а сейчас он выглядит, как минимум, недалеким.
Как по вашему малварщики получают EV сертификаты? Явно не на свой российский паспорт.
А они получают? Я так понял, что с этим теперь проблема, по крайней мере в Windows 10. Так что приходится им, наверно, таскать с собой легальный драйвер с известной уязвимостью, сначала запускать его, а потом передавать управление на себя.
И где/как я могу по поддельным иностранным документам получить EV-сертификат, который затем пройдет проверку в MS Hardware Portal?
Собственно, EV-сертификат у меня есть, но просто интересно.
Так на дропов оформляют, наверное. И EV сертификатов я давно уже в продаже не видел, только OV.
«Отключить требование подписи драйверов»Это, вроде, и есть testsigning on, просто однократный, до перезагрузки.
Эти варианты не эквивалентны. "testsigning on" разрешает установку драйвера с самоподписанным CAT-файлом (если он есть). Отключение проверки подписи, кроме этого, разрешает загрузку. В ядерном загрузчике своя политика проверки подписей.
By default, Windows does not load test-signed kernel-mode drivers. To change this behavior and enable test-signed drivers to load, use the boot configuration data editor, BCDEdit.exe, to enable or disable TESTSIGNING, a boot configuration option.
Корректнее сказать, что загрузка системы с «отключением проверки подписи» снимает требование подписи у драйвера вовсе, а «testsigning on» лишь ослабляет требования, разрешая загрузку самоподписанного драйвера (драйвер с отсутствующей подписью не будет загружен). В этом я был неправ, сказав, что это одно и то же.
Вообще, до середины прошлого года все эти подписи были по большей части бутафорией, т.к. можно было взять заведомо просроченный и отозванный сертификат (в интернете таких гуляет множество), подписать им драйвер и случалось чудо — система хоть и материлась при установке, но исправно загружала такой драйвер.
Как подписать:
1. По инструкциям с сайта MS развертываете у себя HLK (VHLK), минимум две машины — одна контроллер, на другой будут проходить тесты
2. Убеждаетесь что машины из п. 1 видят друг друга и тд
3. На ведомую машину (машины) ставите драйвер (и устройство, если оно не 100% софтверное)
4. Точно не помню — либо в самом HLK выбираете набор тестов, соответствующий вашему устройству, либо качаете нужный плейлист с сайта MS
5. Также бывают некорректные тесты, если есть errata — лучше об этом узнать и применить до запуска тестов
6. Запускаете тесты, идете спать
7. С утра материтесь, добавляете всякие ASLR и DEP, меняете memset на RtlZeroMemory и тд
8. Повторяете пункты 6-7 до успешного результата
9. Дальше, идете в партнерский центр MS, там есть какой-то типа hardware dashboard
10. Там по определенным правилам формируете submission package
11. Он валидируется какое-то время, если все ок — можете скачать уже сертифицированный драйвер
12. По-моему, это бесплатно. Но нужно регистрироваться как партнер MS вроде как, подтверждать бизнес и тд. Железо не нужно отправлять, только сам драйвер, и результаты тестов.
Согласен, сертификация - вещь в себе, тоже не хватало ресурсов в своё время. Есть еще несколько нюансов - в HCK/HLK студии есть автоматические фильтры, или автоматические эрраты - если тесты упали, не спешите расстраиваться, где-то в студии была кнопка вроде "apply filters", которая может "позеленить" их. Такие вещи иногда добавляются и поставляются на клиенты оригинальным образом - нужно с hardware dashboard выкачать архив в сиквел запросами и прокатать их в HCK/HLK используя соответствующую тулзу. Так что если вам выпишут такой фильтр (нам выписывали через premier support), то он не применится пока не примените скрипт. А еще в WLK (это древность, сейчас только для Windows Server 2008 R2 обоснованно для лого) есть тесты которые только красные и проходят только с ручной эрратой. Ручная эррата это Word документ, где описан номер эрраты и падучий тест - его надо приложить в результирующий пакет и сотрудник майкрософт через недельку вам его согласует.
В целом я бы не постеснялся сказать, что у меня огромный опыт в WLK/HCK/HLK для NDIS, ELAM и фильтров ФС. В своё время даже автоматизировали эти тесты, с горем пополам, но ручной по прогонам фактически ушёл. Могу помочь с вопросами по теме
Чтобы драйвер загружался в настольных (desktop) версиях Windows, достаточно attestation-signing через Hardware Portal, проводить тесты HLK не требуется. Но их всегда полезно прогнать (хотя бы в ручном режиме, выдрав нужные из MSI, чтобы не устанавливать всю эту громоздкую хрень целиком), чтобы не искать ошибки/глюки наугад.
ELAM это супер специфика, конечно, у них и подпись другая, нежели остальные от майкрософт
Это работает для всех версий, начиная с висты.
У них давно уже путаница везде. Я с прошлого года, как они отменили кросс-сертификаты, делаю SYS только с attestation-signing, плюс отдельный CAT под 6.x, подписанный моим EV-сертификатом.
Я задам только ещё один вопрос - подпись у вас SHA1, или SHA2? Насколько я помню, SHA1 больше не делают (по крайней мере там, где делали мы), а SHA2 поддерживается нативно только начиная с восьмёрки, на семёрку нужен патч, который, как показывает практика - есть примерно ни у кого.
У меня SHA2, SHA1 уже давно не выдают, а EV-сертификаты, насколько я помню, изначально выпускались только с SHA2.
Если кто-то сидит на семерке и не ставит обновление для поддержки SHA2 - не сам ли он себе злобный буратина?
развертываете у себя HLK (VHLK), минимум две машины — одна контроллер, на другой будут проходить тесты
А могут обе машины быть виртуалками? Когда я несколько лет назад изучал этот вопрос, контроллер требовалось ставить непременно на железную машину, причем непременно с серверной виндой. Но у меня так и не дошли руки все это полноценно развернуть - ограничился выдиранием отдельных тестов из MSI, и получением attestation signature у MS.
может быть всё на виртуалках - WLK/HCK/HLK, хотя формально только для HLK вроде бы заявлена поддержка виртуальных машин и даже поставлялся образ вм. У студий есть жёсткая завязка на имя хоста, если его поменять - всё развалится. Вероятно такие кейсы есть еще и поэтому не рекомендуют виртуалки. Но в целом всё работает без проблем
Еще вспомнились нюансы:
тесты есть натурально бажные. Какой-то тест на фильтры фс падал если на машине больше двух гигов памяти, воркараундилось зарезанием через bcd
апи студий жутко бажное и не оптимизированное. Все апи не потокобезопасны, апи выгрузки пакета вообще оперирует временным файлом, у которого всегда одинаковое имя в HCK - его не поменять, несколько пакетов разом выгружать нельзя. Иногда пакеты нельзя слить в один, есть такая фича в студиях - по слиянию результатов прогонов из разных проектов. Есть места, где можно дёрнуть не разогретые кэши и вызов упадёт, конкретно не помню уже, воркараундится каким-то слабо связанным вызовом выше по коду. В общем развлечений с реверс инжинирингом этого было много
есть тесты, которые проходят только на конкретной редакции оси, например на server core. Если у вас какие-то завязки на GUI - придётся один тест пускать там, остальные - на обычной редакции, затем сливать пакеты проектов в один
для WPF приходилось писать тулзы, чтобы драйверу можно было надиктовать правила фильтрации трафика. Также эти тесты примечательны тем, что там на лету нужно делать ini файл конфига для агента студии
агенты порой теряют связь до студии и машина вываливается из доступных к прогону. Решалось сбрасыванием статуса машины на студии и молитвами
некоторые тесты читают лог агента для ассертов, если его грохнуть - тест может повиснуть или упасть, точно помню так кто-то проверял критерий произведенного ребута, что можно было элегантно костылять перезапуском службы
некоторые тесты проверяют состояние хранилища SxS для ассерта вида "установка драйверов не ломает систему", самое смешное - что сломаться это хранилище может абсолютно независимо от разработчиков драйверов. Приходится восстанавливать с дистрибутивом винды или переустанавливать её. Траблшуталось по логам тестов
какой-то тест падал при наличии в системе русской локали, имя не помню, тоже что-то связанное с фильтрами фс
А уж насколько бажные там тесты звуковых драйверов... Я еще в середине 2000-х, когда пошла мода на Windows Logo, удивлялся количеству сертифицированных MS звуковых драйверов, которые глючили и падали на корректных запросах, выдавали некорректные результаты и т.п. И в десяточных HLK до сих пор есть несколько багов, не исправленных уже несколько лет, хотя я их трудолюбиво репортил.
Просто режим TestSigning работал в Windows 7, но в Windows 10 всё гораздо сложнее. Необходимо сначала особым образом вызвать перезагрузку системы, тогда при старте появится специальное меню. И там, в глубине, есть один пункт, который позволяет снять требование сертификации загружаемых драйверов. На один раз. При следующей перезагрузке процедуру необходимо повторить заново.
На постоянной основе это выполняется ровно так же, как в предыдущих версиях Windows:
bcdedit /set testsigning onПеред этим придётся выключить Secure Boot, о чём система любезно подскажет при попытке выполнить команду.
Эх, напомнило, как я в каком-то лохматом 89 или 90 году декомпилироаал драйвер клавиатуры Windows 3.1, модифицировал его, чтобы он мог печатать на русском, отладил и мы потом даже продавали его, как русификатор Windows)
Да, и все это примерно с нулем документации по драйверам.
Кстати, исходники ReactOS очень помогали. Хотя где-то на хабре видел комментарий одного из участников проекта о том, что им нельзя смотреть в утекшие исходники Windows, почему-то мне кажется, что настолько одинаково думать люди вряд ли умеют.
С VirtualKD удобно отлаживаться и в WinDbg. Заодно очень сильно возрастает скорость обмена (если драйвер выводит плотный поток отладочных сообщений, нужно извлекать из VM большие области памяти и т.п.).
Помнится лет 10 назад был шедевральный отладчик Syser Debugger, которым можно было прямо из-под работающей системы ковыряться в ядре. В современный версиях Windows ничего подобного уже нет?
"Ковыряться" в смысле "смотреть" можно тем же LiveKD, который делает моментальный снимок памяти. А чтобы трассировать собственное ядро, нужен полностью автономный отладчик вроде SoftICE, затраты на поддержку которого еще много лет назад были признаны не оправдывающими кажущихся преимуществ.
А зачем?
SoftICE был хорош для начала-середины 90-х, когда виртуальные машины только входили в моду, а держать отдельную железную для отладки ядерного кода было накладно. Уже в начале-середине 2000-х обе эти проблемы ушли, и стало намного удобнее/выгоднее работать с отлаживаемой системой "со стороны", подвергая ее настолько минимальному воздействию, насколько можно.
Ничего нет, только windbg. Syser пробовали реанимировать на почившем клабе, т.е. отреверсили, пропатчили ошибки, но проект заглох. Изначальный же автор - какой-то китаец, связаться с ним не удалось.
Отладка драйвера Windows