Драйвер microsoft system management bios что это

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

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

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

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

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

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

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

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

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

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

Чтение / запись MSR (Model-Specific Register)

Чтение / запись CR (Control Register)

Чтение TSC (Time Stamp Counter)

Чтение PMC (Performance Monitoring Counter)

Alloc / Free физической памяти

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

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

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

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

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

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

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

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

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

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

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

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

PCI Express Config Space

Чтение и запись 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 через драйвер на чтение через память. Теперь-то разгуляемся!

Читаем 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

Пилим новый скрипт для чтения через чипсет:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы?

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

Тем не менее, рассмотренный пример утилиты на базе AsrDrv работает:

Источник

DMTF выпустил версию 3.4.0 спецификации 20 августа 2020 года.

SMBIOS изначально был известен как BIOS управления рабочим столом ( DMIBIOS ), поскольку он взаимодействовал с интерфейсом управления рабочим столом (DMI).

СОДЕРЖАНИЕ

История

Версия 1 спецификации Desktop Management BIOS (DMIBIOS) была разработана Phoenix Technologies в 1996 году или ранее.

Версия 3.0.0, представленная в феврале 2015 года, добавила 64-битную точку входа, которая может сосуществовать с ранее определенной 32-битной точкой входа.

Версия 3.4.0 была выпущена в августе 2020 года.

СОДЕРЖАНИЕ

Таблица SMBIOS состоит из точки входа (определены два типа: 32-разрядная и 64-разрядная) и переменного числа структур, описывающих компоненты и функции платформы. Эти структуры иногда называют «таблицами» или «записями» в сторонней документации.

Типы конструкций

Начиная с версии 3.3.0, спецификация SMBIOS определяет следующие типы структур:

Доступ к данным SMBIOS

Таблица конфигурации EFI (EFI_CONFIGURATION_TABLE) содержит записи, указывающие на таблицы SMBIOS 2 и / или SMBIOS 3. Есть несколько способов доступа к данным в зависимости от платформы и операционной системы.

Из UEFI

В оболочке UEFI команда SmbiosView может извлекать и отображать данные SMBIOS. Часто можно войти в оболочку UEFI, войдя в BIOS, а затем выбрав оболочку в качестве варианта загрузки (в отличие от DVD-привода или жесткого диска).

Из Linux

Из Windows

В системах Windows, которые его поддерживают (XP и новее), некоторая информация SMBIOS может быть просмотрена либо с помощью утилиты WMIC с ‘BIOS’ / ‘MEMORYCHIP’ / ‘BASEBOARD’ и аналогичными параметрами, либо путем поиска в реестре Windows в разделе HKLM \ HARDWARE \ ОПИСАНИЕ \ Система.

Генерация данных SMBIOS

Создание таблицы и структуры обычно осуществляется микропрограммой / BIOS системы. Спецификация инициализации платформы UEFI (PI) включает протокол SMBIOS (EFI_SMBIOS_PROTOCOL), который позволяет компонентам отправлять структуры SMBIOS для включения и позволяет производителю создавать таблицу SMBIOS для платформы.

Источник

Немного про UEFI и Secure Boot

UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.

Основные отличия UEFI от BIOS:

Как происходит загрузка в UEFI?

С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.

Secure Boot

«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»

Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!

Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.

Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.
В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.
Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.
Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.

Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.
Спасибо за внимание!

Источник

Созданная более 30 лет назад, именуемая BIOS базовая система ввода-вывода порядком устарела, и всё большее количество компьютеров сегодня выпускается на базе UEFI — расширяемом интерфейсе прошивки, который можно условно назвать новым поколением BIOS. И хотя UEFI появился не вчера и даже не позавчера, для многих пользователей он остаётся ещё чем-то новым и малопонятным, что приводит к разного рода недоразумениям. Например, почему-то считается, что на ПК с UEFI принципиально нельзя установить Windows 7 x64, если он не поддерживает режим CSM, в котором «семёрка» показывает лучшую производительность.

Как установить Windows 7 на компьютер с UEFI без поддержки CSM с помощью FlashBoot

Если не вдаваться глубоко в технические подробности, CSM — это модуль совместимости, режим, позволяющий устанавливать и загружать старые операционные системы на компьютерах с UEFI так же, как если бы вместо UEFI в них использовался классический BIOS, примером чему может служить загрузка с MBR-дисков на UEFI. Эта опция в интерфейсе UEFI (в зависимости от версии) может называться CMS Boot, UEFI and Legacy OS или CMS OS. При её использовании обычно приходится отключать Secure Boot, работающий только с «чистой» UEFI. Проблема в том, что в самых новых материнских платах CSM может и не поддерживаться, ведь и эта технология постепенно уходит в прошлое.

Из примера с установкой 64-разрядной Windows 7 на VirtualBox в режиме UEFI можно видеть, что VGA-совместимый GPU с правильно сопоставленными портами ввода-вывода и обработчиком INT 10H действительно необходим, причём INT 10H обычно предоставляется прошивкой при включённом режиме CSM. Начиная с Windows 8, обработчик INT 10H перестал использоваться для загрузки системы, а вместе с ним были удалены эмулятор BIOS и драйвер минипорта VGA, а вместо последнего стал использоваться интегрированный видеодрайвер на базе протокола вывода графики UEFI, также известный как GOP.

Так может быть для загрузки Windows 7 на UEFI будет достаточно интегрировать модифицированный обработчик INT 10H, умеющий использовать тот же протокол GOP? Увы, эксперименты показали, что этого оказалось недостаточно, так как помимо вызова VGA через INT 10H, через порт ввода-вывода VGA происходит обращение к ядру операционной системы (файл NTOSKRNL.EXE). Чтобы решить проблему загрузки, разработчикам пришлось создать патч для NTOSKRNL.EXE, создающий специальный подпроцесс при каждой загрузке Windows.

FlashBoot как итог решения проблемы

«Видимым» результатом усилий разработчиков стала утилита FlashBoot Pro — простой и интуитивно понятный инструмент для создания загрузочных флешек с пропатчиванием Windows 7 x64, благодаря чему эту систему можно устанавливать на новые компьютеры с UEFI без поддержки режима совместимости CSM. Кроме того, FlashBoot и ее профессиональная версия FlashBoot Pro может быть использована для «создания» переносных, загружающихся с флешки систем Windows, создания образов флешек (в том числе загрузочных) и восстановления из них на других переносных накопителях, а также их форматирования и полной очистке. FlashBoot Pro дополнительно поддерживается создание клонов Windows 7, 8, 8.1 и 10 с возможностью интеграции драйверов USB 3.0, NVMe и AHCI/RAID, создание загрузочных флешек с Windows XP и «живых» дисков BartPE (мини-версия XP), а также самораспаковывающихся архивов.

Создание загрузочной флешки в FlashBoot

Приведём пример создания загрузочной флешки с Windows 7 x64 с пропатченными файлами загрузки для последующей установки системы на новые ПК с UEFI без поддержки CSM. Первым делом находим Free-версию программы на официальном сайте www.prime-expert.com/flashboot (Pro-версию можно только купить), устанавливаем и запускаем. Подключаем к компьютеру флешку и жмём в открывшемся окне приложения «Next».
В следующем окне выбираем опцию записи дистрибутива на флешку «OS installer → USB». Далее программа предложит выбрать метод создания загрузочного носителя.
Поскольку нам нужна загрузочная UEFI-флешка без поддержки CSM выбираем опцию «Windows Vista/7/8/8.1/10 installer with added drivers (for UEFI-based Computers)», доступную только в Pro-версии. Она же позволяет интегрировать в процессе создания загрузочного накопителя драйвера. Если нужна UEFI-флешка с поддержкой CSM, подойдёт и «Windows Vista/7/8/8.1/10 installer (for BIOS-based Computers)».
Следующий шаг — выбор источника, которым может служить как установочный ISO-файл, так и записанный на DVD-диск дистрибутив системы.
Жмём «Next» и видим, что FlashBoot уже включила интеграцию драйверов USB 3.x и NVMe, а также пропатчивание загрузочных файлов. Активировав пункт «Custom drivers from the specified folder…», можно добавить свои драйвера, указав файлы INF, SYS и CAT.
После очередного нажатия «Next» выбираем в выпадающем списке подключённую флешку и снова нажимаем «Next».
На следующем этапе можно дать метку тома и указать в дополнительных настройках «Set advanced options» нужно ли добавлять в конец флешки нераспределённое пространство, чего мы делать не станем.
В итоге перед вами предстанет список запланированных операций, запускаем их нажатием «Format Now». Процедура записи довольно длительная, копирование файлов образа размером 5,5 Гб на флешку объёмом 7,5 Гб, подключённую по интерфейсу USB 2.0 у нас заняла почти два часа!
За прогрессом записи вы можете наблюдать в окошке мастера. По успешном завершении процедуры вы получите сообщение «Completed successfully. Click OK to exit». Готово, можете использовать флешку для установки Windows.
FlashBoot Pro со скидкой 40% или как мы пытались получить бесплатную версию программы для создания загрузочных флешек.
Читайте наш специальный раздел об установке Windows 7 на новые ноутбуки и ПК с интерфейсом UEFI

Источник