Modem driver что это за драйвер
Обновлено: 05.07.2024
Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:
- Минипорт-драйверы (драйверы адаптера)
- Промежуточные драйверы (например, psched.sys)
- Драйверы протокола (например, tcpip.sys)
Минипорт-драйверы
- производит инициализацию своего устройства (адаптера)
- создание /включение/выключение/удаление сетевых подключений
- выдача клиенту или изменение параметров адаптера
- отправка пакетов
- получение пакетов
- оповещение ОС о состоянии адаптера
- перезагрузка и остановка адаптера
Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).
Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.
Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.
- LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
- FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера
Промежуточные драйверы
Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.
- организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
- фильтруют и перехватывают трафик
- маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)
Драйверы протоколов
Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.
К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).
Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).
Для чего нужен этот драйвер - LSI High-Definition Audio (HDA) Modem Driver ?
FuaD Искусственный Интеллект (154636) audio modem driver? странно)) может они отдельно требуют драйверы
Через Python в дебри
Конечно же я захотел сделать свой небольшой "тулкит" для различных исследований и экспериментов на базе такого драйвера. Причём на Python, мне уж очень нравится, как просто выглядит реализация сложных вещей на этом языке.
Первым делом нужно установить драйвер в систему и запустить его. Делаем "как положено" и сначала кладём драйвер (нужной разрядности!) в System32:
Раньше в похожих ситуациях я извращался с папкой %WINDIR%\Sysnative, но почему-то на моей текущей системе такого алиаса не оказалось, хотя Python 32-битный. (по идее, на 64-битных системах обращения 32-битных программ к папке System32 перенаправляются в папку SysWOW64, и чтобы положить файлик именно в System32, нужно обращаться по имени Sysnative).
Затем регистрируем драйвер в системе и запускаем его:
А дальше запущенный драйвер создаёт виртуальный файл (кстати, та самая колонка "имя" в таблице с анализом дров), через запросы к которому и осуществляются дальнейшие действия:
И ещё одна полезная программа для ползания по системе, WinObj
Тоже ничего особенного, открываем файл и делаем ему IoCtl:
Вот здесь чутка подробнее. Я долго думал, как же обеспечить адекватную обработку ситуации, когда таких "скриптов" запущено несколько. Не останавливать драйвер при выходе нехорошо, в идеале нужно смотреть, не использует ли драйвер кто-то ещё и останавливать его только если наш скрипт "последний". Долгие упорные попытки получить количество открытых ссылок на виртуальный файл драйвера ни к чему не привели (я получал только количество ссылок в рамках своего процесса). Причём сама система точно умеет это делать - при остановке драйвера с открытым файлом, он остаётся висеть в "Pending Stop". Если у кого есть идеи - буду благодарен.
В конечном итоге я "подсмотрел", как это делают другие программы. Выяснилось, что большинство либо не заморачиваются, либо просто ищут запущенные процессы с тем же именем. Но одна из исследованных программ имела кардинально другой подход, который я себе и перенял. Вместо того, чтобы переживать по количеству ссылок на файл, просто на каждый запрос открываем и закрываем файл! А если файла нет, значит кто-то остановил драйвер и пытаемся его перезапустить:
А дальше просто реверсим драйвер и реализуем все нужные нам вызовы:
Легко и непринуждённо в пару команд читаем физическую память
В чём суть, капитан?
В архитектуре x86 есть понятие «колец защиты» («Ring») – режимов работы процессора. Чем ниже номер текущего режима, тем больше возможностей доступно исполняемому коду. Самым ограниченным «кольцом» является «Ring 3», самым привилегированным – «Ring -2» (режим SMM). Исторически сложилось, что все пользовательские программы работают в режиме «Ring 3», а ядро ОС – в «Ring 0»:
Режимы работы x86 процессора
В «Ring 3» программам запрещены потенциально опасные действия, такие как доступ к I/O портам и физической памяти. По логике разработчиков, настолько низкоуровневый доступ обычным программам не нужен. Доступ к этим возможностям имеют только операционная система и её компоненты (службы и драйверы). И всё бы ничего, но однажды я наткнулся на программу RW Everything:
RW Everything действительно читает и пишет практически всё
Эта программа была буквально напичкана именно теми функциями, которые обычно запрещаются программам «Ring 3» - полный доступ к физической памяти, I/O портам, конфигурационному пространству PCI (и многое другое). Естественно, мне стало интересно, как это работает. И выяснилось, что RW Everything устанавливает в систему прокси-драйвер:
Смотрим последний установленный драйвер через OSR Driver Loader
Что такое Софтмодем и чем нам это грозит? Комментарий
Начать следует, пожалуй, с мифов о невероятных требованиях к вычисительной мощности устройства (процессора), необходимых для реализации модемных протоколов связи, зародившихся еще во времена процессоров i8086. Как показывает реальная практика сегодняшнего дня — требования к ресурсам процессора составляют примерно 10% для процессора класса Pentium II 400 MHz и около 40% для процессора Pentium 200 MHz при полностью программном софтмодеме. HSP модемы с собственным DSP обеспечивают еще меньшую нагрузку. Таким образом, уже с появлением следующего поколения центральных процессоров эти цифры могут быть заметно снижены. Что касается утверждения о бОльших потенциальных возможностях аппаратных модемов в части реализации новых возможностей и протоколов — увы, практика показала иное — если владельцам модемов Courier удалось безболезненно проапгрейдить их для поддержки протокола V.90, (владельцам спортстеров пришлось доплатить некоторую сумму, в дополнение к уже уплаченной при покупке модема), то в большинстве случаев пользователь аппаратных модемов был вынужден покупать новое устройство, как это происходило, например, с достаточно дорогими модемами фирмы Zyxel при появлении протоколов V.32->V.34->V.34bis->V.90. При этом, у существующего модема могло не хватить всего лишь нескольких процентов вычислительной мощности, однако жесткая ограниченность аппаратного решения заставляла полностью отказываться от возможности апгрейда. Яркий пример — фирма Digicom Systems, выпустившая в свое время модем серии Connection 96. Перспективы обещали быть радужными — при первоначальной максимальной скорости в 9600bps через некоторое время вышла версия микропрограммы с поддержкой скорости 14400bps, обещалось светлое будущее в виде апгрейда до протокола V34. И вдруг все кончилось — вычислительной мощности ADSP2115 хватило лишь для реализации скорости 19200bps протокола V32Terbo. То есть сначала покупателя заманивают обещаниями апгрейдов и прочих приятных возможносей, затем все это оказывется блефом, приводящей к уплате очередной суммы денег за такой модем. Это наглядно показывает всю выгоду изготовления аппаратных модемов как для
производителей, так и для продавцов.
Поступающие в продажу в последнее время софтмодемы можно довольно четко разделить на две категории - полный софтмодем, не имеющий собственного полноценного DSP, и включающий в себя генератор полного набора частот, необходимых для реализации протоколов, включая V.90, и цифровой фильтр входных и выходных сигналов модема.
Примеры — модемы, собранные с использованием чипсетов STMicroelectronics 75xx, PCtel 1789N/W и Rockwell HCF/SoftK56, например, AZtech MSP3880.
Ко второй группе софтмодемов можно отнести DSP-based модели,имеющие полноценный DSP, но отсутствующий контроллер, занимающийся реализацией интерфейса AT-команд, и работой по управлению DSP и компрессии данных.
Требуемая производительность этого контроллера весьма незначительна, и может быть оценена примерно как 4-х кратная по отношению к процессору i8086, работающему на частоте 4.77 MHz.
Типичные примеры — модемы на чипсете Lucent 164x. Готовые модемы на их базе производят, например, фирмы Genius GM 56PCI-L, FIC GM56PCI, Paradise WaveCom 56K PCI.
Что касается вопроса об остающихся софтмодему недостаточных ресурсов при выполнении к примеру, приложений виртуальной Ява-машины — это не cовсем так, на самом деле, говорить здесь следует скорее об остающихся ресурсах процессора для выполнения приложений Win32 после того, как софтмодем уже отберет себе необходимую для работы часть процессорного времени, так как в отличие от этих приложений драйвер модема работает с приоритетом ядра системы и процессорного времени может не хватить, например самой программе, выполняющей прием данных от модема и сохраняющей их на диске в виде файла. Также разработчиками фирм Motorola и Smart Link предприняты и запатентованы некоторые методы для предотвращения возможных проблем с драйверами софтмодемов, более того - программисты Motorola утверждают, что им удалось добиться обработки критических событий модема в режиме реального времени. Так же считают и специалисты фирмы Rockwell, реализовавшие технологию Latency Guard. Правда, нельзя не отметить — такие способы требуют скорее подготовки хакера, чем системного программиста, однако это связано с недостатками самой системы Windows, и другого выхода здесь просто нет.
Таким образом — сложности с падением скорости передачи данных при обычной работе с компьютером являются скорее надуманными, чем имеют под собой реальную основу. Что касается экстремального случая с возможным монопольным захватом ресурсов центрального процессора некорректно написанной программой — это, конечно же, приведет к разрыву связи софтмодемом, а аппаратный модем приостановит процесс приема-передачи данных. Кстати, при длительных задержках в этом процессе аппаратный модем связь конечно не разорвет, но вот сбои в протоколах верхнего уровня (например TCP/IP) не исключены — что также вполне может привести к необходимости повторного установления соединения. В связи с этим хочется обратить внимание вот на что: аппаратные модемы обеспечивают более высокую скорость передачи данных, чем софтмодемы, в том числе и из-за сравнительно неотработанных драйверов для последних, и разрыв может достигать в отдельных случаях сотен CPS. И здесь возникает еще одна проблема, близкая Российскому пользователю, работающему с повременной оплатой услуг Internet — при достаточно длительной работе с софтмодемом (месяцы, годы) экономия на его покупке может оказаться мнимой — если пользователь в основном занимается приемом/передачей файлов значительных обьемов, разница в оплате услуг интернет-провайдера при работе с аппаратным и софтмодемом может составить значительную сумму денег — и не в пользу последнего.
Касательно не всегда корректной рекламы — хотелось бы привести еще и такой пример — в качестве одного из преимуществ софтмодемов для переносных ПК, выполненных в виде PC CARD или MDC (Mobile Daughter Card) преподносится и существенная экономия энергоресурсов, связанная с тем, что у таких модемов ток потребления действительно чрезвычайно мал — это связано прежде всего с минимальной степенью интеграции применяемых в этом случае чипов. Однако скромно умалчивается о том, что для выполнения загрузки файлов аппаратному модему могут потребоваться лишь минимальные ресурсы процессора — к примеру, работающий в режиме энергосбережения на частоте 8MHz процессор ноутбука вполне справится с этой задачей, в то время как для нормальной работы софтмодема потребуется примерно пятикратное ее увеличение — в результате вместо экономии энергии получим ее повышенный расход.
Относительно сложностей защиты программного обеспечения при разработке собственных или доработке уже имеющихся драйверов для софтмодемов: действительно, вариант с драйверами для Российских телефонных линий не лишен привлекательности хотя бы потому, что при наличии исходных текстов драйверов от производителя их доработка сильно упрощается применением популярного и давно изученного кода x86 — нет необходимости изучать систему команд и сталкиваться с различными ограничениями специализированных контроллеров — как в случае с аппаратными модемами.
В связи с упоминанием автором статьи необходимости наличия в ПК звуковой карты для реализации голосовых возожностей софтмодема: в данном случае аппаратные модемы не имеют никаких преимуществ перед софтмодемами — разьемы для подключения телефонной гарнитуры имеются как на большинстве внутренних аппаратных модемов с поддержкой голосовых функций, так и на многих софтмодемах — таким образом никакой необходимости в наличии звуковой карты не возникает, если же имеются в виду внешние аппаратные модемы со встроенным качественным динамиком и микрофоном — то таких моделей — единицы. В случае с модемами AMR это также неверно — несмотря на отсутствие как гнезд для телефонной гарнитуры, так и в большинстве случаях встроенного динамика, эти модемы устанавливаются в слот материнских плат, уже имеющих AC-кодек, и, соответственно, разьемы на материнской плате для подключения внешних источников сигнала.
Что касается перспектив шины ISA — здесь явно ощущается прессинг, причем с двух сторон — как производителей чипсетов (Intel) так и операционных систем. Насколько мне известно — в версии OC Microsoft Millennium2000 поддержка шины ISA просто не предусмотрена — да и будут ли производители материнских плат в течении длительного времени идти на дополнительные затраты для установки недешевого моста PCI/ISA — сказать однозначно нельзя. Сегодня при принятии решения о покупке внутреннего модема на шине ISA покупателю следует весьма серьезно задуматься об оправданности такого шага, и в первую очередь рассмотреть возможные альтернативы.
О необходимости драйверов для софтмодемов — на мой взгляд,не стоит заострять на этом внимания, и не следует рассматривать как что-то экстраординарное — софтмодем такое же устройство, как например звуковая или видеокарта, и, по многочисленным откликам людей, использующих софтмодемы — те же звуковые карты, выпущенные сравнительно недавно, создают не меньше проблем, связанных с совместимостью и устойчивостью работы системы в целом. Возвращаясь же к надежности аппаратных модемов — из-за ошибок firmware они могут иногда просто зависать, и если для внешних модемов проблема решалась повторным включением питания — для возобновления работы внутренних моделей приходилось уже выключать весь ПК, что нередко случалось, например, с ранними версиями модемов USR Sportster на базе TMS.
Эти модемы вполне способны конкурировать с аппаратными
модемами нижнего ценового диапазона. Также следует обратить внимание на наличие у модема гнезд для подключения микрофона и наушников — в продаже имеются два вида моделей — представленные на рынке модели могут не иметь этой возможности, что при отсутствии в ПК звуковой карты сделает невозможной работу модема в качестве автоответчика.
2. Необходим осторожный подход при выборе полных софтмодемов, например, на чипах SiLabs, STMicroelectronics (драйверы фирмы Smart Link) — эти модемы могут создать неоправданные трудности как при установлении связи, так и при работе на линиях невысокого качества, а также отсутствием реализованной в настоящее время в драйверах упомянутой фирмы эмуляции COM-порта для работы в окне DOS операционной системы Windows.
3. Пользователь должен быть готов к возможным конфликтам оборудования при установке таких модемов и знать пути их решения — как показывают отклики читателей — наиболее частые проблемы - конфликты со звуковой картой при неверном распределении IRQ в системе, проблемы при конфигурации как адреса, так и прерывания модема для работы на необходимом COM-порту, установка модема в соседний с AGP слот PCI, отсутствие установленной поддержки PCI IRQ для не-Intel чипсетов (VIA, SiS, и т.п.) либо устаревшая версия драйверов для самого модема.
4. В некоторых случаях, в поставку с модемами в OEM-исполнении могут не входить, например, драйверы для OC Windows NT, как это бывает в случае с модемами Zoltrix Phantom. Это также требует от пользователя некоторых знаний для самостоятельного получения свежих версий ПО с сайта производителя.
В противном случае, весьма вероятно разочарование как от плохой работы приобретенного устройства, так и от возможной неудачной попытки заставить его работать без конфликтов с остальным оборудованием.
Читаем BIOS
В качестве примера применения нашего "тулкита", попробуем набросать скрипт чтения BIOS. Он должен быть "замаплен" где-то в конце 32-битного адресного пространства, потому что компьютер начинает его исполнение с адреса 0xFFFFFFF0. Обычно в ПК стоит флеш-память объёмом 4-16 МБ, поэтому будем "сканировать" адресное пространство с адреса 0xFF000000, как только найдём что-нибудь непустое, будем считать, что тут начался BIOS:
В результате получаем:
Вот так в 10 строчек мы считали BIOS
Но подождите-ка, получилось всего 6 мегабайт, а должно быть 4 или 8 что-то не сходится. А вот так, у чипсетов Intel в адресное пространство мапится не вся флешка BIOS, а только один её регион. И чтобы считать всё остальное, нужно уже использовать SPI интерфейс.
Не беда, лезем в даташит, выясняем, что SPI интерфейс висит на PCI Express:
И для его использования, нужно взаимодействовать с регистрами в BAR0 MMIO по алгоритму:
Задать адрес для чтения в BIOS_FADDR
Задать параметры команды в BIOS_HSFTS_CTL
Прочитать данные из BIOS_FDATA
Пилим новый скрипт для чтения через чипсет:
Исполняем и вуаля - в 20 строчек кода считаны все 8 МБ флешки BIOS! (нюанс - в зависимости от настроек, регион ME может быть недоступен для чтения).
Точно так же можно делать всё, что заблагорассудится - делать снифер USB пакетов, посылать произвольные ATA команды диску, повышать частоту процессора и переключать видеокарты. И это всё - с обычными правами администратора:
Немного помучившись, получаем ответ от SSD на команду идентификации
А если написать свой драйвер?
Некоторые из вас наверняка уже подумали - зачем так изворачиваться, реверсить чужие драйвера, если можно написать свой? И я о таком думал. Более того, есть Open-Source проект chipsec, в котором подобный драйвер уже разработан.
Зайдя на страницу с кодом драйвера, вы сразу наткнетесь на предупреждение:
В этом предупреждении как раз и описываются все опасности, о которых я рассказывал в начале статьи - инструмент мощный и опасный, следует использовать только в Windows режиме Test Mode, и ни в коем случае не подписывать. Да, без специальной подписи на обычной системе просто так запустить драйвер не получится. Поэтому в примере выше мы и использовали заранее подписанный драйвер от ASRock.
Если кто сильно захочет подписать собственный драйвер - понадобится регистрировать собственную компанию и платить Microsoft. Насколько я нагуглил, физическим лицам такое развлечение недоступно.
Точнее я так думал, до вот этой статьи, глаз зацепился за крайне интересный абзац:
У меня под рукой нет Windows DDK, так что я взял 64-битный vfd.sys , скомпилированный неким critical0, и попросил dartraiden подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin запущена с правами администратора
Драйвер из статьи действительно подписан, и действительно неким китайским ключом:
Как оказалось, сведения о подписи можно просто посмотреть в свойствах.. А я в HEX изучал
Немного поиска этого имени в гугле, и я натыкаюсь на вот эту ссылку, откуда узнаю, что:
есть давно утёкшие и отозванные ключи для подписи драйверов
если ими подписать драйвер - он прекрасно принимается системой
малварщики по всему миру используют это для создания вирусни
Основная загвоздка - заставить майкрософтский SignTool подписать драйвер истёкшим ключом, но для этого даже нашёлся проект на GitHub. Более того, я нашёл даже проект на GitHub для другой утилиты подписи драйверов от TrustAsia, с помощью которого можно подставить для подписи вообще любую дату.
Несколько минут мучений с гугл-переводчиком на телефоне, и мне удалось разобраться в этой утилите и подписать драйвер одним из утекших ключей (который довольно легко отыскался в китайском поисковике):
И в самом деле, китайская азбука
И точно так же, как и AsrDrv101, драйвер удалось без проблем запустить!
А вот и наш драйвер запустился
Из чего делаю вывод, что старая идея с написанием своего драйвера вполне себе годная. Как раз не хватает функции маппинга памяти. Но да ладно, оставлю как TODO.
Windows: достучаться до железа
Меня всегда интересовало низкоуровневое программирование – общаться напрямую с оборудованием, жонглировать регистрами, детально разбираться как что устроено. Увы, современные операционные системы максимально изолируют железо от пользователя, и просто так в физическую память или регистры устройств что-то записать нельзя. Точнее я так думал, а на самом деле оказалось, что чуть ли не каждый производитель железа так делает!
PCI Express Config Space
Немного отвлечёмся на один нюанс про PCIE Config Space. С этим адресным пространством не всё так просто - со времён шины PCI для доступа к её конфигурационному пространству используется метод с использованием I/O портов 0xCF8 / 0xCFC. Он применён и в нашем драйвере AsrDrv101:
Чтение и запись PCI Config Space
Но через этот метод доступны только 0x100 байт конфигурационного пространства, в то время как в стандарте PCI Express размер Config Space у устройств может быть достигать 0x1000 байт! И полноценно вычитать их можно только обращением к PCI Extended Config Space, которая замаплена где-то в адресном пространстве, обычно чуть пониже BIOS:
Адресное пространство современного x86 компа, 0-4 ГБ
На чипсетах Intel (ну, в их большинстве) указатель на эту область адресного пространства можно взять из конфига PCI устройства 0:0:0 по смещению 0x60, подробнее описано в даташитах:
У AMD я такого не нашёл (наверняка есть, плохо искал), но сам факт неуниверсальности пнул меня в сторону поиска другого решения. Погуглив стандарты, я обнаружил, что указатель на эту область передаётся системе через ACPI таблицу MCFG
А сами ACPI таблицы можно найти через запись RSDP, поискав её сигнатуру по адресам 0xE0000-0xFFFFF, а затем распарсив табличку RSDT. Отлично, здесь нам и пригодится функционал поиска по памяти. Получаем нечто такое:
На всякий случай оставляем вариант для чипсетов Intel
Всё, теперь осталось при необходимости заменить чтение PCI Express Config Space через драйвер на чтение через память. Теперь-то разгуляемся!
Выводы?
Как видите, имея права администратора, можно делать с компьютером практически что угодно. Будьте внимательны - установка утилит от производителя вашего железа может обернуться дырой в системе. Ну а желающие поэкспериментировать со своим ПК - добро пожаловать на низкий уровень! Наработки выложил на GitHub. Осторожно, бездумное использование чревато BSODами.
В Windows есть фича "Изоляция ядра", которая включает I/O MMU, защищает от DMA атак и так далее (кстати об этом - в следующих сериях)
Так вот, при включении этой опции, некоторые драйвера (в том числе RW Everything и китайско-подписанный chipsec_hlpr) перестают запускаться:
Прокси-драйвера
В итоге получается обходной манёвр – всё, что программе запрещено делать, разработчик вынес в драйвер, программа устанавливает драйвер в систему и уже через него программа делает, что хочет! Более того – выяснилось, что RW Everything далеко не единственная программа, которая так делает. Таких программ не просто много, они буквально повсюду. У меня возникло ощущение, что каждый уважающий себя производитель железа имеет подобный драйвер:
Софт для обновления BIOS (Asrock, Gigabyte, HP, Dell, AMI, Intel, Insyde…)
Софт для разгона и конфигурации железа (AMD, Intel, ASUS, ASRock, Gigabyte)
Софт для просмотра сведений о железе (CPU-Z, GPU-Z, AIDA64)
Софт для обновления PCI устройств (Nvidia, Asmedia)
Во многих из них практически та же самая модель поведения – драйвер получает команды по типу «считай-ка вот этот физический адрес», а основная логика – в пользовательском софте. Ниже в табличке я собрал некоторые прокси-драйвера и их возможности:
Результаты краткого анализа пары десятков драйверов. Могут быть ошибки!
Mem – чтение / запись физической памяти
PCI – чтение / запись PCI Configuration Space
I/O – чтение / запись портов I/O
Alloc – аллокация и освобождение физической памяти
Map – прямая трансляция физического адреса в вирутальный
MSR – чтение / запись x86 MSR (Model Specific Register)
Жёлтым обозначены возможности, которых явно нет, но их можно использовать через другие (чтение или маппинг памяти). Мой фаворит из этого списка – AsrDrv101 от ASRock. Он устроен наиболее просто и обладает просто огромным списком возможностей, включая даже функцию поиска шаблона по физической памяти (!!)
Неполный перечень возможностей AsrDrv101
Чтение / запись RAM
Чтение / запись IO
Чтение / запись PCI Configuration Space
Чтение / запись MSR (Model-Specific Register)
Чтение / запись CR (Control Register)
Чтение TSC (Time Stamp Counter)
Чтение PMC (Performance Monitoring Counter)
Alloc / Free физической памяти
Поиск по физической памяти
Самое нехорошее в такой ситуации - если подобный драйвер остаётся запущенным на ПК пользователя, для обращения к нему не нужно даже прав администратора! То есть любая программа с правами пользователя сможет читать и писать физическую память - хоть пароли красть, хоть ядро пропатчить. Именно на это уже ругались другие исследователи. Представьте, что висящая в фоне софтина, красиво моргающая светодиодиками на матплате, открывает доступ ко всей вашей системе. Или вирусы намеренно ставят подобный драйвер, чтобы закрепиться в системе. Впрочем, любой мощный инструмент можно в нехороших целях использовать.
Читайте также: