Что такое kernel driver

Обновлено: 02.07.2024

Современные приложения и игры отличаются большим размером и детальной прорисовкой графики. Соответственно, работа с ними требует от ПК особой мощности. Часто пользователи сталкиваются, что во время работы и игрового процесса возникает Windows ошибка kernel – критический сбой в процессе работы. Некоторые компьютеры показывают BlueScreen – синий экран смерти, в некоторых случаях устройство перестает откликаться на любое действие.

Через Python в дебри

Конечно же я захотел сделать свой небольшой "тулкит" для различных исследований и экспериментов на базе такого драйвера. Причём на Python, мне уж очень нравится, как просто выглядит реализация сложных вещей на этом языке.

Первым делом нужно установить драйвер в систему и запустить его. Делаем "как положено" и сначала кладём драйвер (нужной разрядности!) в System32:

Раньше в похожих ситуациях я извращался с папкой %WINDIR%\Sysnative, но почему-то на моей текущей системе такого алиаса не оказалось, хотя Python 32-битный. (по идее, на 64-битных системах обращения 32-битных программ к папке System32 перенаправляются в папку SysWOW64, и чтобы положить файлик именно в System32, нужно обращаться по имени Sysnative).

Затем регистрируем драйвер в системе и запускаем его:

А дальше запущенный драйвер создаёт виртуальный файл (кстати, та самая колонка "имя" в таблице с анализом дров), через запросы к которому и осуществляются дальнейшие действия:

И ещё одна полезная программа для ползания по системе, WinObj

И ещё одна полезная программа для ползания по системе, WinObj

Тоже ничего особенного, открываем файл и делаем ему IoCtl:

Вот здесь чутка подробнее. Я долго думал, как же обеспечить адекватную обработку ситуации, когда таких "скриптов" запущено несколько. Не останавливать драйвер при выходе нехорошо, в идеале нужно смотреть, не использует ли драйвер кто-то ещё и останавливать его только если наш скрипт "последний". Долгие упорные попытки получить количество открытых ссылок на виртуальный файл драйвера ни к чему не привели (я получал только количество ссылок в рамках своего процесса). Причём сама система точно умеет это делать - при остановке драйвера с открытым файлом, он остаётся висеть в "Pending Stop". Если у кого есть идеи - буду благодарен.

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

А дальше просто реверсим драйвер и реализуем все нужные нам вызовы:

Легко и непринуждённо в пару команд читаем физическую память

Легко и непринуждённо в пару команд читаем физическую память

Прокси-драйвера

В итоге получается обходной манёвр – всё, что программе запрещено делать, разработчик вынес в драйвер, программа устанавливает драйвер в систему и уже через него программа делает, что хочет! Более того – выяснилось, что 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 физической памяти

Поиск по физической памяти

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

Ошибка kernel. Общие сведения о неполадке

Ошибка Kernel-Power имеет кодировку 43. Возникновение такой проблемы означает, что у компьютера выявлено нарушение мощности ядра системы. Она относится к 63й категории, что означает невозможность Windows обрабатывать одновременно большое количество запросов и выполнять сложные операции. Именно это объясняет процесс торможения и подвисания современных компьютерных аркад.
На самом деле, выяснить точные проблемы возникновения Kernel-Power достаточно сложно, даже официальный сайт Майкрософт не предоставляет конкретных данных.

Существует ли лечение?

В случае, когда ПК зависает, отказываясь реагировать на любую команду мыши или клавиатуры, помогает только режим перезагрузки, попасть в который можно только с помощью длительного нажатия и удерживания кнопки питания. Но это не гарантирует дальнейшую бесперебойную работу. Вероятнее всего, что первые несколько минут/часов система проработает без нареканий, а затем повторно появится проблема.
Опытным путем стало понятно, что полная переустановка системы тоже не помогает. Отсюда напрашивается вывод, что проблема находится на уровне взаимодействия системы, ПО, ОЗУ, ПЗУ и жесткого диска. Действительно, прочитав рекомендуемые требования на упаковке диска с игрой, можно обнаружить что требования, предъявляемые к «железу», для того чтобы игра установилась, запустилась и шла ровно и плавно достаточно высокие. Кроме этого, рекомендуется проверить все ли шлейфы подключены к разъемам нет ли заломов, а также стабильность работы блока питания.

Windows ошибка kernel. Настройка Биоса

Одной из причин, вызывающих Kernel-Power является критический перегрев процессора. Это может случиться по двум причинам:

  • Его слишком сильно разогнали
  • Он не предназначен для сильных нагрузок
  • Высохла термопаста
  • Плохая система отвода тепла

Первое действие, которое нужно выполнить в таком случае, это проверить исходные данные ЦП и снизить все завышенные показатели, непосредственно связанные с разгоном. Так как для большинства обычных пользователей такие манипуляции выполнить достаточно трудно, в этом случае рекомендуется просто сделать откат до базовых заводских настроек.
Если вы используете не ноутбук, а простой компьютер, то можно достать материнскую плату и на некоторое непродолжительное время вынуть батарейку. Можно попробовать перевести Clear CMOS из положения «1-2» в положение «2-3» меньше чем на минуту, а затем вернуть его в исходное положение. Это тоже приведет к полному сбросу. Правда, этот способ тоже не гарантирует решения проблемы.

Тестирование центрального процессора

При повторном обнаружении Kernel-Power стоит провести тестирование центрального процессора ПК. Для этого скачивается и распаковывается специальная программа Everest. С ее помощью можно выяснить какие компоненты дали сбой. Правда, сделать восстановление через утилиту невозможно. Оптимально провести тестирование при помощи Prime95. Выбираете Just Stress Testing в опциях раздела Torture Test.

Сбой работы Kernel-Power может быть связан с ошибками в работе оперативной памяти. Проверить память можно несколькими способами. Первый – при помощи стандартной системной программы, введя в командную строку «mdsched»,и запустив перезагрузку системы с ее тестированием. Выполнить это можно только при условии, что вы зашли через учетную запись Администратора.
В случае, если проверка не выявила никаких неполадок можно прибегнуть к физическому способу – поочередно извлекать из своих слотов планки оперативной памяти каждый раз выполняя перезагрузку ПК. Если после определенного извлечения компьютер работает нестабильно, значит проблема кроется в ней, и стоить заменить ее на идентичную.

Проблема с жестким диском

Еще одна распространенная проблема заключается в том, что многие жесткие диски плохо стыкуются в 64-х битной операционной системой. Чаще всего этим страдают винчестеры бренда Seagate, установленные в большинстве современных бюджетных ноутбуков.
Для проверки необходимо скачать и установить HDD Life или HDD Health, запустить соответствующую проверку. В редких случаях может потребоваться обновление прошивки жесткого диска до последней версии. Если неполадки заключаются в винчестере, решения может быть два – замена жесткого диска или ремонт в соответствующих сервисных центрах. Правда, он не дает гарантий, что через некоторое время вам не потребуется приобретать новый жесткий диск.
Можно попробовать самостоятельно восстановить битые кластеры жесткого диска при помощи пакета утилит HDD Regenerator, но и она не гарантирует восстановление жесткого диска в его первоначальное состояние.

Проблема звуковых и видеокарт

Такая проблема зачастую возникает в случае, если на ПК были установлены две звуковые или видеокарты. Установленные программы пытаются работать с обеими, что приводит к сильнейшим сбоям на программном уровне. Для решения данной проблемы следует удалить один из чипов или правильно настроить параллельную работу двух карт.

Драйвера сетевой карты

Появление ошибки Kernel-Power может быть спровоцировано не обновлёнными вовремя драйверами сетевой карты или неправильная их распаковка и установка. В этом случае можно попробовать сделать следующее:

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

Обновление системы

Для того, чтобы постараться избежать появления многих системных ошибок, рекомендуется разрешить Windows обновлять элементы самостоятельно в автоматическом режиме. Проблемы, связанные с «железом», это не решит, а вот системных избежать удастся.
Зайдите в Центр обновления Windows, поставьте галочку напротив нужного режима. В этом случае, предпочтение стоит отдать полной автоматизации, чтобы избежать ручных действий.

Kernel-Power представляет собой серьезную и непростую ошибку, конкретные причины которой установить пока не удалось. Если ни один из вышеперечисленных методов не дал положительного результата, или проблема пропала на короткий промежуток времени, а затем появилась снова, рекомендуется обратиться в сервисную службу.

Windows: достучаться до железа


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

В чём суть, капитан?

В архитектуре x86 есть понятие «колец защиты» («Ring») – режимов работы процессора. Чем ниже номер текущего режима, тем больше возможностей доступно исполняемому коду. Самым ограниченным «кольцом» является «Ring 3», самым привилегированным – «Ring -2» (режим SMM). Исторически сложилось, что все пользовательские программы работают в режиме «Ring 3», а ядро ОС – в «Ring 0»:

Режимы работы x86 процессора

Режимы работы x86 процессора

В «Ring 3» программам запрещены потенциально опасные действия, такие как доступ к I/O портам и физической памяти. По логике разработчиков, настолько низкоуровневый доступ обычным программам не нужен. Доступ к этим возможностям имеют только операционная система и её компоненты (службы и драйверы). И всё бы ничего, но однажды я наткнулся на программу RW Everything:

RW Everything действительно читает и пишет практически всё

RW Everything действительно читает и пишет практически всё

Эта программа была буквально напичкана именно теми функциями, которые обычно запрещаются программам «Ring 3» - полный доступ к физической памяти, I/O портам, конфигурационному пространству PCI (и многое другое). Естественно, мне стало интересно, как это работает. И выяснилось, что RW Everything устанавливает в систему прокси-драйвер:

Смотрим последний установленный драйвер через OSR Driver Loader

Смотрим последний установленный драйвер через OSR Driver Loader

Выводы?

Как видите, имея права администратора, можно делать с компьютером практически что угодно. Будьте внимательны - установка утилит от производителя вашего железа может обернуться дырой в системе. Ну а желающие поэкспериментировать со своим ПК - добро пожаловать на низкий уровень! Наработки выложил на GitHub. Осторожно, бездумное использование чревато BSODами.

В Windows есть фича "Изоляция ядра", которая включает I/O MMU, защищает от DMA атак и так далее (кстати об этом - в следующих сериях)


Так вот, при включении этой опции, некоторые драйвера (в том числе RW Everything и китайско-подписанный chipsec_hlpr) перестают запускаться:

Работаем с модулями ядра в Linux



Ядро — это та часть операционной системы, работа которой полностью скрыта от пользователя, т. к. пользователь с ним не работает напрямую: пользователь работает с программами. Но, тем не менее, без ядра невозможна работа ни одной программы, т.е. они без ядра бесполезны. Этот механизм чем-то напоминает отношения официанта и клиента: работа хорошего официанта должна быть практически незаметна для клиента, но без официанта клиент не сможет передать заказ повару, и этот заказ не будет доставлен.
В Linux ядро монолитное, т.е. все его драйвера и подсистемы работают в своем адресном пространстве, отделенном от пользовательского. Сам термин «монолит» говорит о том, что в ядре сконцентрировано всё, и, по логике, ничего не может в него добавляться или удаляться. В случае с ядром Linux — это правда лишь отчасти: ядро Linux может работать в таком режиме, однако, в подавляющем большинстве сборок возможна модификация части кода ядра без его перекомпиляции, и даже без его выгрузки. Это достигается путем загрузки и выгрузки некоторых частей ядра, которые называются модулями. Чаще всего в процессе работы необходимо подключать модули драйверов устройств, поддержки криптографических алгоритмов, сетевых средств, и, чтобы уметь это правильно делать, нужно разбираться в строении ядра и уметь правильно работать с его модулями. Об этом и пойдет речь в этой статье.

В современных ядрах при подключении оборудования модули подключаются автоматически, а это событие обрабатывается демоном udev, который создает соответствующий файл устройства в каталоге "/dev". Все это выполняется в том случае, если соответствующий модуль корректно установлен в дерево модулей. В случае с файловыми системами ситуация та же: при попытке монтирования файловой системы ядро подгружает необходимый модуль автоматически, и выполняет монтирование.
Если необходимость в модуле не на столько очевидна, ядро его не загружает самостоятельно. Например, для поддержки функции шифрования на loop устройстве нужно вручную подгрузить модуль «cryptoloop», а для непосредственного шифрования — модуль алгоритма шифрования, например «blowfish».

Поиск необходимого модуля

Модули хранятся в каталоге "/lib/modules/<версия ядра>" в виде файлов с расширением «ko». Для получения списка всех модулей из дерева можно выполнить команду поиска всех файлов с расширением «ko» в каталоге с модулями текущего ядра:

find /lib/modules/`uname -r` -name ‘*.ko’

Полученный список даст некоторое представление о доступных модулях, их назначении и именах. Например, путь «kernel/drivers/net/wireless/rt2x00/rt73usb.ko» явно указывает на то, что этот модуль — драйвер устройства беспроводной связи на базе чипа rt73. Более детальную информацию о модуле можно получить при помощи команды modinfo:

Загрузка и выгрузка модулей

Загрузить модуль в ядро можно при помощи двух команд: «insmod» и «modprobe», отличающихся друг от друга возможностью просчета и удовлетворения зависимостей. Команда «insmod» загружает конкретный файл с расширением «ko», при этом, если модуль зависит от других модулей, еще не загруженных в ядро, команда выдаст ошибку, и не загрузит модуль. Команда «modprobe» работает только с деревом модулей, и возможна загрузка только оттуда по имени модуля, а не по имени файла. Отсюда следует область применения этих команд: при помощи «insmod» подгружается файл модуля из произвольного места файловой системы (например, пользователь скомпилировал модули и перед переносом в дерево ядра решил проверить его работоспособность), а «modprobe» — для подгрузки уже готовых модулей, включенных в дерево модулей текущей версии ядра. Например, для загрузки модуля ядра «rt73usb» из дерева ядра, включая все зависимости, и отключив аппаратное шифрование, нужно выполнить команду:

После загрузки модуля можно проверить его наличие в списке загруженных в ядро модулей при помощи команды «lsmod»:

Module Size Used by
rt73usb 17305 0
crc_itu_t 999 1 rt73usb
rt2x00usb 5749 1 rt73usb
rt2x00lib 19484 2 rt73usb,rt2x00usb

Из вывода команды ясно, что модуль подгружен, а так же в своей работе использует другие модули.
Чтобы его выгрузить, можно воспользоваться командой «rmmod» или той же командой «modprobe» с ключем "-r". В качестве параметра обоим командам нужно передать только имя модуля. Если модуль не используется, то он будет выгружен, а если используется — будет выдана ошибка, и придется выгружать все модули, которые от него зависят:

Для автоматической загрузки модулей в разных дистрибутивах предусмотрены разные механизмы. Я не буду вдаваться здесь в подробности, они для каждого дистрибутива свои, но один метод загрузки всегда действенен и удобен: при помощи стартовых скриптов. В тех же RedHat системах можно записать команды загрузки модуля прямо в "/etc/rc.d/rc.local" со всеми опциями.
Файлы конфигурация модулей находится в каталоге "/etc/modprobe.d/" и имеют расширение «conf». В этих файлах преимущественно перечисляются альтернативные имена модулей, их параметры, применяемые при их загрузке, а так же черные списки, запрещенные для загрузки. Например, чтобы вышеупомянутый модуль сразу загружался с опцией «nohwcrypt=1» нужно создать файл, в котором записать строку:

options rt73usb nohwcrypt=1

Черный список модулей хранится преимущественно в файле "/etc/modules.d/blacklist.conf" в формате «blacklist <имя модуля>». Используется эта функция для запрета загрузки глючных или конфликтных модулей.

Сборка модуля и добавление его в дерево

Иногда нужного драйвера в ядре нет, поэтому приходится его компилировать вручную. Это так же тот случай, если дополнительное ПО требует добавление своего модуля в ядро, типа vmware, virtualbox или пакет поддержки карт Nvidia. Сам процесс компиляции не отличается от процесса сборки программы, но определенные требования все же есть.
Во первых, нужен компилятор. Обычно установка «gcc» устанавливает все, что нужно для сборки модуля. Если чего-то не хватает — программа сборки об этом скажет, и нужно будет доустановить недостающие пакеты.
Во вторых, нужны заголовочные файлы ядра. Дело в том, что модули ядра всегда собираются вместе с ядром, используя его заголовочные файлы, т.к. любое отклонение и несоответствие версий модуля и загруженного ядра ведет к невозможности загрузить этот модуль в ядро.
Если система работает на базе ядра дистрибутива, то нужно установить пакеты с заголовочными файлами ядра. В большинстве дистрибутивов это пакеты «kernel-headers» и/или «kernel-devel». Для сборки модулей этого будет достаточно. Если ядро собиралось вручную, то эти пакеты не нужны: достаточно сделать символическую ссылку "/usr/src/linux", ссылающуюся на дерево сконфигурированных исходных кодов текущего ядра.
После компиляции модуля на выходе будет получен один или несколько файлов с расширением «ko». Можно попробовать их загрузить при помощи команды «insmod» и протестировать их работу.
Если модули загрузились и работают (или лень вручную подгружать зависимости), нужно их скопировать в дерево модулей текущего ядра, после чего обязательно обновить зависимости модулей командой «depmod». Она пройдется рекурсивно по дереву модулей и запишет все зависимости в файл «modules.dep», который, в последствие, будет анализироваться командой «modprobe». Теперь модули готовы к загрузке командой modprobe и могут загружаться по имени со всеми зависимостями.
Стоит отметить, что при обновлении ядра этот модуль работать не будет. Нужны будут новые заголовочные файлы и потребуется заново пересобрать модуль.

Ошибка «Invalid argument» может говорить о чем угодно, саму ошибку ядро на консоль написать не может, только при помощи функции «printk» записать в системный лог. Посмотрев логи можно уже узнать в чем ошибка:

В этом примере выведена только последняя строка с ошибкой, чтобы не загромаждать статью. Модуль может написать и несколько строк, поэтому лучше выводить полный лог, или хотя бы последние строк десять.
Ошибку уже легко найти: значение «2» неприемлемо для параметра «nohwcrypt». После исправления, модуль корректно загрузится в ядро.

Из всего сказанного можно сделать один вывод: ядро Linux играет по своим правилам и занимается серьезными вещами. Тем не менее — это всего лишь программа, оно, по сути, не сильно отличается от других обычных программ. Понимание того, что ядро не так уж страшно, как кажется, может стать первым шагом к пониманию внутреннего устройства системы и, как результат, поможет быстро и эффективно решать задачи, с которыми сталкивается любой администратор Linux в повседневной работе.

видеодрайвер-nvidia-windows-kernel-mode-driver-перестал-отвечать-что-делать

Обновляем видеокарту

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

  • В первую очередь обновите драйвера своей видеокарты. Это делается стандартно, но лучше применить скачивание из официального веб-сайта NVIDIA.
  • При подозрении на некачественный софт, который ранее устанавливался на компьютер, сделайте возврат системы на пару дней назад.
  • Крайним способом остается полная установка драйверов с диска к видеокарте (он идет в комплекте с компьютером). Но прежде удалите те драйвера, что уже стоят.

Пытаемся решить при помощи DirectX

Установка последнего DirectX очень важный шаг для любого геймера. Без его нормальной работы рассчитывать на успешный запуск игры не приходится. Тут главное уловить момент. Если ошибка появляется в начале загрузки, значит проблема с большой долей вероятности в DirectX.

DirectX лучше скачивать только с официального источника – Microsoft. Также он идет к любой компьютерной игре в комплекте. Папка, где он обычно храниться именуется «Redist».

Работа по настройкам видеокарты

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

  • Находим на рабочем столе «Мой компьютер» и кликаем правой кнопкой мышки.
  • Первым пунктом обычно стоит «Панель управления».
  • Находим среди множества вариантов «Панель управления Nvidia».

Вот подробная видео-инструкция по настройке видеодрайвера.

Повышаем производительность

Очень актуально при ошибке NVIDIA Windows Kernel Mode Driver для ноутбуков c Windows (7/8/10). Попробуйте выставить производительность системы на максимум.

  1. В нижней панели справа отыщите индикатор заряда ноутбука или компьютера.
  2. Зайдите «Дополнительные параметры электропитания».
  3. Выставьте точку напротив «Высокая производительности».

Повысив производительность, уберите все возможные фоновые программы. Если на рабочем столе стоят анимированные обои, то их следует заменить. Установите стандартный фон.

Проверяем Adobe Flash Player. Если баг «Видеодрайвер перестал отвечать» выскакивает в браузере, то возможно стоит обновить Adobe Flash Player. Думаю с его обновлением, проблем возникнуть не может.

Плата видеокарты

Ошибка видеодрайвера Nvidia windows kernel mode driver – это не только программные сбои, но и возможные физические поломки. Следует перейти к непосредственному изучению самой платы видеокарты.

  1. Осторожно извлеките плату видеокарты. Хорошенько продуйте контакты и протрите сухой тканью. Верните на место.
  2. Попробуйте скачать программу для измерения температуры видеокарты. Рекомендуется воспользоваться Speccy. Ее установка очень проста. Сразу при первом запуске в меню «Графические устройства» отобразится температура. До 80 °C считается норма. Если больше, тогда проверите термопасту.

PCI Express Config Space

Немного отвлечёмся на один нюанс про PCIE Config Space. С этим адресным пространством не всё так просто - со времён шины PCI для доступа к её конфигурационному пространству используется метод с использованием I/O портов 0xCF8 / 0xCFC. Он применён и в нашем драйвере AsrDrv101:

Чтение и запись PCI Config Space

Чтение и запись PCI Config Space

Но через этот метод доступны только 0x100 байт конфигурационного пространства, в то время как в стандарте PCI Express размер Config Space у устройств может быть достигать 0x1000 байт! И полноценно вычитать их можно только обращением к PCI Extended Config Space, которая замаплена где-то в адресном пространстве, обычно чуть пониже BIOS:

Адресное пространство современного x86 компа, 0-4 ГБ

Адресное пространство современного x86 компа, 0-4 ГБ

На чипсетах Intel (ну, в их большинстве) указатель на эту область адресного пространства можно взять из конфига PCI устройства 0:0:0 по смещению 0x60, подробнее описано в даташитах:


У AMD я такого не нашёл (наверняка есть, плохо искал), но сам факт неуниверсальности пнул меня в сторону поиска другого решения. Погуглив стандарты, я обнаружил, что указатель на эту область передаётся системе через ACPI таблицу MCFG

А сами ACPI таблицы можно найти через запись RSDP, поискав её сигнатуру по адресам 0xE0000-0xFFFFF, а затем распарсив табличку RSDT. Отлично, здесь нам и пригодится функционал поиска по памяти. Получаем нечто такое:

На всякий случай оставляем вариант для чипсетов Intel

Всё, теперь осталось при необходимости заменить чтение PCI Express Config Space через драйвер на чтение через память. Теперь-то разгуляемся!

Читаем BIOS

В качестве примера применения нашего "тулкита", попробуем набросать скрипт чтения BIOS. Он должен быть "замаплен" где-то в конце 32-битного адресного пространства, потому что компьютер начинает его исполнение с адреса 0xFFFFFFF0. Обычно в ПК стоит флеш-память объёмом 4-16 МБ, поэтому будем "сканировать" адресное пространство с адреса 0xFF000000, как только найдём что-нибудь непустое, будем считать, что тут начался BIOS:

В результате получаем:

Вот так в 10 строчек мы считали 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 на команду идентификации

Немного помучившись, получаем ответ от SSD на команду идентификации

А если написать свой драйвер?

Некоторые из вас наверняка уже подумали - зачем так изворачиваться, реверсить чужие драйвера, если можно написать свой? И я о таком думал. Более того, есть Open-Source проект chipsec, в котором подобный драйвер уже разработан.

Зайдя на страницу с кодом драйвера, вы сразу наткнетесь на предупреждение:

В этом предупреждении как раз и описываются все опасности, о которых я рассказывал в начале статьи - инструмент мощный и опасный, следует использовать только в Windows режиме Test Mode, и ни в коем случае не подписывать. Да, без специальной подписи на обычной системе просто так запустить драйвер не получится. Поэтому в примере выше мы и использовали заранее подписанный драйвер от ASRock.

Если кто сильно захочет подписать собственный драйвер - понадобится регистрировать собственную компанию и платить Microsoft. Насколько я нагуглил, физическим лицам такое развлечение недоступно.

Точнее я так думал, до вот этой статьи, глаз зацепился за крайне интересный абзац:

У меня под рукой нет Windows DDK, так что я взял 64-битный vfd.sys , скомпилированный неким critical0, и попросил dartraiden подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin запущена с правами администратора

Драйвер из статьи действительно подписан, и действительно неким китайским ключом:

Как оказалось, сведения о подписи можно просто посмотреть в свойствах.. А я в HEX изучал

Как оказалось, сведения о подписи можно просто посмотреть в свойствах.. А я в HEX изучал

Немного поиска этого имени в гугле, и я натыкаюсь на вот эту ссылку, откуда узнаю, что:

есть давно утёкшие и отозванные ключи для подписи драйверов

если ими подписать драйвер - он прекрасно принимается системой

малварщики по всему миру используют это для создания вирусни

Основная загвоздка - заставить майкрософтский SignTool подписать драйвер истёкшим ключом, но для этого даже нашёлся проект на GitHub. Более того, я нашёл даже проект на GitHub для другой утилиты подписи драйверов от TrustAsia, с помощью которого можно подставить для подписи вообще любую дату.

Несколько минут мучений с гугл-переводчиком на телефоне, и мне удалось разобраться в этой утилите и подписать драйвер одним из утекших ключей (который довольно легко отыскался в китайском поисковике):

И в самом деле, китайская азбука

И в самом деле, китайская азбука

И точно так же, как и AsrDrv101, драйвер удалось без проблем запустить!

А вот и наш драйвер запустился

А вот и наш драйвер запустился

Из чего делаю вывод, что старая идея с написанием своего драйвера вполне себе годная. Как раз не хватает функции маппинга памяти. Но да ладно, оставлю как TODO.

Читайте также: