Как вшить ключ в биос ноутбука
Обновлено: 07.07.2024
Вас приветствует канал WindowsUsers ! Данная статья получилась довольно длинной – наберитесь терпения! Столкнулся с ситуацией одной девушки подписчицы – она никак не может установить Windows 10 Pro на свой ноутбук и все по тому-что скачивает образы Windows.iso либо с официального сайта Microsoft , либо программой Rufus . Продвинутые пользователи знают, что данные образы содержат несколько редакций Windows 10 – Домашняя, Профессиональная и Для образовательных учреждений, а у девушки в bios ноутбука зашит ключ от Домашней редакции и система автоматом устанавливается Домашняя исключая возможность выбора. Опытные пользователи наверняка скажут: «Плевое дело… Пересобрать iso c добавлением ei . cfg или сделать экстракт в Dism с выделением нужной редакции и опять же пересобрать iso» - но как это сделать девушке которая можно сказать осваивает тонкости по написанным нами статьям?! И еще у начинающих пользователей сложилось устойчивое мнение что образы Windows надо непременно скачивать с официального сайта Microsoft – а все остальное зло😉
Исходя из выше изложенного🤣 хочу рассказать вам о сайте UUP dump , который позволяет скачивать не только нужную вам редакцию, но и с последними обновлениями , если быть точным сайт автоматически предоставляет вам скрипты aria2 в соответствии с вашим выбором, а вы уже на своем ПК запускаете нужный скрипт и начинается скачивание файлов с официальных серверов Microsoft и их компиляция в нужный вам образ Windows.iso ( тоже самое и делает официальная утилита Microsoft Media Creation Tool ), с запуском одного файла на ПК согласитесь даже ребенок справится - это вам не работа с Dism в командной строке. Скрипты в одном скачанном пакете созданы как для Windows, так и для Linux и Mac.
Ну что-ж перейдем к обзору сайта UUP dump . При открытии ссылки нас встречает вот такое окно:
Сайт к сожалению на английском и русского увы нет в перечне языков сайта – пользуйтесь онлайн-переводчиком, хотя и так все интуитивно понятно, во всяком случае для меня (к слову меня чуть из-за английского из школы не выгнали, шучу). На первой странице сайта есть возможность выбрать нужную версию Windows 10 по ее кодовому имени - Dev Channel, 21H1, 20H2, 20H1, 19H2, 19H1, 1809 , а также можно сразу перейти к последней сборке публичного релиза - Latest Public Release build или к последним файлам инсайдерских сборок – соответственно Предварительный просмотр, Бета-канал и канал Dev и выбрать нужную архитектуру . Так-же можно в строке поиска ввести сразу нужную версию, например новейшая майская Windows 10, со всеми последними обновлениями - 19043.1023 из канала предварительного просмотра.
Давайте я сразу покажу как скачать новейшую версию образа Windows 10 Pro 21H1 Публичного релиза, что-б не усложнять статью и не загромождать ее картинками, кто желает может сам прочитать на сайте раздел справки на английском FAQ (кто не силен – воспользуйтесь онлайн переводчиком). Предположу, что у вас ПК 64-битной архитектуры и не на arm процессоре - как самый распространенный вид ПК, нас интересует последнее майское обновление 21H1 2021 года Публичного релиза – кликаем по x64:
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.
Введение
С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM'ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.
Тестовая конфигурация
Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:
1. AMI, они же "треугольные": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, они же "квадратные": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, они же "полукруглые": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
Об интерфейсах для настройки SecureBoot
На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool'а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.
Готовим плацдарм
Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.
Генерируем собственные ключи для SecureBoot
Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.
Генерируем ключевые пары
Конвертируем открытые ключи в формат ESL
Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.
Подписываем ESL-файлы
Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца. Ну тогда вам прямая дорога вот сюда, там в самом конце раздела 1.3.4.3 есть ссылка на сертификат Microsoft Corporation KEK CA 2011 в формате DER, из которого нужно сначала получить PEM командойзатем сконвертировать полученный PEM в ESL командой
после чего добавить получившийся файл к нашему файлу KEK.esl командой
Теперь Microsoft такой же авторизованный пользователь вашей платформы, как и вы сами, с чем я вас и поздравляю.
С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:
Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:
Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.
Подписываем загрузчик
Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.
В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.
Укрощение строптивого
AMI AptioV
Insyde H2O
Phoenix SCT
Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:
Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool'а, иначе на этой платформе его запустить не получится:
Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool'а заканчивается вот так:
При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.
Заключение
В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.
Я думаю что у многих появлялась идея вшить ключ от восьмёрки. Имеется в распоряжении ноутбук, вшит ключ от ХРюшки, возможно ли его изменить на ключ от восьмёрки? Довольно популярный сайт, надеюсь здесь есть люди, которые смогут помочь. ( внимание! поместил в эту тему, т.к. если вшить ключ, то будет активироваться система, следовательно это лекарство)
чувак, то что ты хочешь называется SLIC таблица вшитая в BIOS. никто твой ноутбук переделывать не будет, это большая работа по программированию. кроме того в твой ноутбук с хрюшей скорее всего новый BIOS просто не поместится. так что забудь об этой идее фикс и купи себе новый ноутбук (уже пора)
А смысл ставить 10 на BIOS с MBR прироста ведь не будет, структура не позволит разогнаться на прирост, для десятки требуется UEFI с GPT и диск SSD вот здесь и прирост и скорость и производительность, но и самое главное оператива чем выше ее число МГц тем лучше. А на старом железе это будет примерно Vista, просто что красивее и новее, а производительности не добавит, а может еще и наоборот получится несовместимость с железом а именно с видео картой.
А ключ может работать года два после обновления а потом потребуют плату за него примером в 190 долларов по подписке, это они могут сделать, такая завлекаловка будет очень удобной, многим придется и заплатить, чтоб закончить работу, проекты и заказы.
Для обывателя не страшно и если имеется бэкап с более ранней версией к которой можно вернуться в любой момент, для себя держу два бэкапа 7-х-64 Максимальная и 8.1-х-64 Корпоративная, для 7-ки висит в трее обнова, для 8.1 корп ее нет. Так что для одной системы может стать проблемой, но это все исправимо при получении обновления указать все в настройках и оповещении обновлений и выбрать те обновления которые именно важны для системы.
Саблезуб (26.07.2015, 21:47) писал: для десятки требуется UEFI с GPT
Это то здесь причём? grt нужен если систему ставишь на жд болееили+ 2 тера ну или если есть присуиствие такого жд (а также если проц итаниум), а какой прирост производительности это даст? это даст плотность записи на жд более 2 терабайт и всё, а крутится или читать записывать он быстрей не будет и система грузится и выгружатся то же быстрей не будет. Как то так.
Первый ключ, который показывает программа по умолчанию, это - BT79Q-G7N6G-PGBYW-4YWX6-6F4BT. Данный общий ключ установлен на всех ноутбуках с предустановленной Windows 10 Домашняя для одного языка. Также этот ключ будет установлен на вашем ноутбуке, если вы обновили Windows 8.1 для одного языка до Windows 10 Домашняя для одного языка.
Если отметить в программе пункт MSDM KEY, то откроется ключ, вшитый в BIOS, в таблицу данных ACPI, в подтаблицу MSDM. На серверах Майкрософт информация об этом ключе соответствует операционной системе, которая была установлена на вашем ноутбуке при покупке в магазине. Если при покупке ноутбука на нём была установлена Windows 10 Домашняя для одного языка, то ключ MSDM KEY принадлежит только этой ОС. И д анный ключ можно записать куда-нибудь на всякий случай.
Зачем на ноутбуке с Windows 10 два ключа?
Напомню вам, как собственно говоря происходит активация Windows 10.
Практически на все ноутбуки, продающиеся в магазинах, установлены OEM-версии Windows 10. Вы можете спросить, что такое OEM-версия Windows ? Ответ простой, это операционная система, которая поставляется вместе с ноутбуком в виде предустановленной версии.
OEM-версии операционных систем от Microsoft, начиная с Windows 8.1, используют проверку подлинности, основанную на сличении двух ключей:
1. Ключа, вшитого в BIOS, в таблицу данных ACPI, в подтаблицу MSDM2. И лицензионного 25-значного ключа, вшитого в дистрибутив Windows 10.
3. Также в активации участвует OEM-сертификат, вшитый в дистрибутив ОС.
Допустим на вашем ноутбуке установлена Windows 10 Домашняя для одного языка и вы решили её переустановить заново. После переустановки, Windows 10 Домашняя для одного языка попросит активировать себя и на серверах Майкрософт произойдёт сличение двух ключей: первого общего, вшитого в дистрибутив операционной системы - BT79Q-G7N6G-PGBYW-4YWX6-6F4BT и второго ключа, вшитого в БИОС ноутбука. Активация произойдёт, если оба ключа будут относится к релизу Windows 10 Домашняя для одного языка .
Читайте также: