Uefi tool: Releases · LongSoft/UEFITool · GitHub
Содержание
знакомство с UEFITool / Хабр
Прикрываясь полумифическими «безопасностью» и «защитой простого пользователя от буткитов» производители UEFI все сильнее закручивают гайки с каждым новым поколением своих продуктов. При этом поддержка предыдущих поколений быстро сходит на нет, и их пользователям ничего не остается, кроме как брать эту самую поддержку в свои руки. Конечно, при отсутствии исходного кода вносить какие-то изменения довольно сложно, но и без него можно сделать многое.
В своихпредыдущихстатьях об UEFI я планировал описать различные полезные модификации, которые помогают преодолеть некоторые заложенные производителями ограничения, но тогда до них руки не дошли, зато теперь — самое время.
В первой части этой статьи я опишу работу с написанным мной инструментом для модификации образов UEFI, а вторая будет посвящена самим модификациям.
Вступление, отказ от ответственности
Прошивка UEFI BIOS на современных платах, несмотря на наличие различных технологий вроде USB BIOS Flashback, Dual BIOS, Flash Recovery и т.
п. — все равно лотерея. Прошивка же модифицированных образов — лотерея вдвойне.
Именно поэтому я прошу до начала любых экспериментов с прошивкой сделать при помощи аппаратного SPI-программатора полный дамп содержимого микросхемы, иначе восстановление после неудачной прошивки (а она рано или поздно случится) будет долгим, дорогим и болезненным.
SPI-программатор в данный момент может быть собран в домашних условиях из чего угодно, от пары резисторов и конденсаторов (SPIPGM) до Arduino или Raspberry Pi. Мой вариант дешевого и быстрого SPI-программатора описан здесь. Любителям вытравить пару-тройку плат советую обратить внимание на этот проект, а почитателям устройств «все-в-одном» — на этот.
Далее по тексту я полагаю, что у вас есть программатор, возможность восстановления после сбоя прошивки и готовность к экспериментам. Безумству храбрых, конечно, тоже можно петь песни, но не говорите потом, что я не предупреждал.
Традиционно, все, что вы тут сейчас прочитаете, написано в образовательных целях, автор не несет ответственности за возможную порчу вашего оборудования, недополученную прибыль, потерю времени и веры в человечество, вы пользуетесь предоставленным софтом на свой страх и риск и так далее.
UEFITool
Устав от ограничений существующих утилит для работы с образами UEFI (ну и пораженный синдромом NIH в самое сердце), я написал кроссплатформенную утилиту с открытым исходным кодом — UEFITool.
Это редактор образов UEFI, написан на C++\Qt, распространяется под лицензией BSD, готовые сборки выкладываются сюда.
Проект находится в активной разработке, поэтому код не блещет красотой и баги нет-нет, да попадаются. Если вдруг наткнетесь — буду рад репортам.
Для нормальной работы с утилитой стоит прочитать предыдущие статьи о структуре образа UEFI, иначе непонятно будет, что вообще происходит, но я постараюсь все же пояснить некоторые моменты. Будем считать, что это заготовка для будущей документации.
В качестве примеров в обеих частях статьи я буду использовать полные дампы с Zotac Z77-ITX WiFi (AMI Aptio4) и Dell Vostro 3360 (Phoenix SCT 2.3). К сожалению, у меня нет тестового стенда на платформе Insyde h3O, поэтому рассказать о ней мне нечего.
Возможно, Falseclock знает о них немного больше.
С точки зрения UEFITool’а разницы между образами UEFI разных производителей практически нет, поэтому я остановлюсь на ней при описании патчей.
Итак, запускаем UEFITool, открываем образ (Ctrl+O) и видим примерно такое:
В левой части окна отображается структура открытого образа в виде дерева, справа — информация о выбранном элементе дерева, снизу — сообщения, указывающие на ошибки в формате файла, в данном случае — использование разработчиками Phoenix секций с типом 0xF0, назначение которых не описано в спецификации UEFI PI. Двойной щелчок по сообщению раскроет дерево так, чтобы был виден либо на сам элемент, который это сообщение вызвал, либо его родительский элемент. В это же окно выводятся результаты поиска, который можно вызвать нажатием Ctrl+F (оба варианта одной картинкой):
Здесь следует немного пояснить терминологию. Практически все структурные элементы в образе UEFI имеют заголовок, в котором хранятся служебные данные вроде GUID, атрибутов, контрольных сумм и т.
п., и тело — в нем хранятся собственно данные. Текст же в заголовках не хранится, поэтому для него такой выбор не нужен.
На первом уровне дерева находятся Flash-регионы, в данном случае это Descriptor, ME и BIOS:
При выборе региона Descriptor можно узнать настройки доступа к регионам, в данном случае доступ полный, но такие настройки встречаются очень редко. Intel рекомендует производителям оборудования закрывать доступ к региону МЕ на чтение/запись и региону Descriptor на запись, именно поэтому на большинстве плат встроенными средствами полный дамп снять без «танцев с бубном» практически невозможно. При выборе региона ME можно узнать версию ME firmware, если же она не отображается — это не к добру и такой образ лучше не шить.
Перейдем еще на уровень ниже, к содержимому региона BIOS:
На этом уровне могут встречаться два типа элементов: тома и свободное место. Свободное в данном случае — не обязательно пустое, к примеру, в этом образе в самом начале Padding’а хранится прошивка EC.
Тома делятся на обыкновенные (формат файловой системы известен), загрузочные (формат ФС известен, содержат Security Core, изменять стоит с особой осторожностью) и неизвестные (либо неизвестен формат ФС, либо разбор еще не реализован). В нашем случае первый том после свободного пространства в начале — обычный, затем два неизвестных (на самом деле, в первом хранится NVRAM, а во втором — ключи и БД для SecureBoot, но программе я это пока еще не объяснил), последний том является загрузочным.
Откроем теперь обычный том, в данном случае в нем хранятся файлы, загружаемые в фазе DXE.
Такая структура (основной том внутри сжатой секции) используется довольно часто, она позволяет сэкономить приличное количество места в микросхеме. Есть еще вариант сжимать не весь том целиком, а каждый файл по отдельности — это несколько менее экономно в плане места, зато стартует такой UEFI BIOS быстрее, т.к. нет смысла распаковывать файлы, к которым не было обращений.
Теперь заглянем внутрь файла:
Все данные в нем хранятся внутри GUID-defined-секции (в заголовке таких секций обычно хранится ЭЦП или контрольная сумма, в данном случае — 4 байта, похожие на КС, которую, однако, никто не проверяет), и делятся на 4 секции: образ PE32 — собственно исполняемый файл в формате PE/COFF, секция зависимостей DXE — определяет порядок загрузки DXE-драйверов, секция UI — в ней хранится текст «SystemCapsuleRt.
efi» в формате Unicode и неизвестная секция типа 0xF0 (скорее всего, её содержимое каким-то образом связано с вышеупомянутой КС).
Все это хорошо, конечно, но редактирования пока не видно. Не беда, вызываем для любого элемента контекстное меню, в котором видно, что с этим элементом можно сделать.
А сделать можно следующее:
- сохранить элемент в файл либо целиком (Extract as is), либо только данные, без заголовков (Extract body)
- пересобрать элемент (Rebuild), в этом случае при сохранении измененного образа для него (и всех его родительских элементов) будут пересчитаны размеры, контрольные суммы, исправлено выравнивание, т.е. структура образа будет приведена в соответствие со спецификацией UEFI PI
- вставить элемент из файла, либо перед выбранным (Insert before), либо после (Insert after), либо внутрь него (Insert into, в данном случае внутрь PE32-секции ничего вставить не получится)
- заменить элемент на другой элемент из файла, либо целиком (Replace as is), либо только его тело (Replace body)
Последнее действие является наиболее полезным, т.
к. позволяет произвести модификацию какой-либо части UEFI, не затрагивая при этом структуры всего образа.
Пример использования
Рассмотрим в качестве примера полезную для пользователей MacOS X на ПК модификацию: обход установки бита LOCK (0x0F) в регистре MSR_PMG_CST_CONFIG_CONTROL (0xE2). Бит этот устанавливается DXE-драйвером PowerManagement, чтобы ОС не могла управлять множителем CPU путем записи в этот регистр. Для Windows и Linux это не большая проблема, а вот MacOS X не может стерпеть от UEFI такой наглости. Можно, конечно, пропатчить драйвер AICPM.kext (в 10.8) или ядро (в 10.9), но лучше пропатчить DXE-драйвер и не бояться, что очередное автоматическое обновление сломает загрузку. Патч этот нужен только системам на базе процессоров Intel SandyBridge, IvyBridge и Haswell и их *-E вариантов и делается так:
- Открываем свой дамп в UEFITool, очищаем Messages нажатием Ctrl+Backspace, чтобы не мешали
- Открываем поиск, выбираем Hex-pattern, Body only, ищем строку «75080FBAE80F»
- Делаем двойной щелчок на сообщении о том, что строка найдена, сохраняем тело указанного элемента в файл
- Исправляем в Hex-редакторе «75080FBAE80F» на «EB080FBAE80F» (JE становится JMP), сохраняем изменения
- Заменяем содержимое выбранного элемента на измененное, старый элемент будет помечен на удаление (Remove), новый — на замену (Replace), все родительские элементы до корня — на перестроение (Rebuild)
- Сохраняем измененный образ (Ctrl+S), если сохранение прошло успешно, будет выдан запрос на открытие только что сохраненного образа, если нет — сообщение об ошибке
Прошиваем полученный образ тем же SPI-программатором, которым он был сделан, и получаем отсутствие паники ядра при загрузке MacOS X.
Подробности, другие модификации, заключение
Если вам интересно, откуда взялся магический паттерн «75080FBAE80F» и на какие еще патчи стоит обратить внимание — читайте вторую часть этой статьи, которая будет опубликована немного позже. В ней я постараюсь подготовить побольше примеров в формате «что за модификация, зачем нужна, как сделать, кем и как была найдена», не углубляясь каждый раз в то, как именно вынуть подлежащий модификации элемент и как вставить его обратно.
Надеюсь, что статья не показалась слишком скучной и нудной. Если у вас есть вопросы и предложения — буду рад выслушать и ответить по мере сил. Баг-репортам буду рад еще больше. Спасибо заранее и удачных прошивок.
P.S. Уважаемая администрация и лично НЛО, сделайте для таких вот постов хаб UEFI, пожалуйста.
Фазы загрузки UEFI и способы контроля исполняемых образов — ОКБ САПР
Фазы загрузки UEFI и способы контроля исполняемых образов
Черчесов А.
Э., МФТИ
В статье рассматриваются основные фазы загрузки базовой системы ввода-вывода, способы встраивания исполняемых образов в различные фазы загрузки UEFI и способы защиты от вредоносного кода в UEFI BIOS.
Ключевые слова: UEFI BIOS, DXE Phase, PEI Phase, Boot Firmware Volume (BFV), DXE Core.
UEFI boot stages and ways to control executable images
The article describes the UEFI boot phases, the ways of embedding executable images in various phases, and ways how to protect against malicious code in the UEFI BIOS.
Keywords: UEFI BIOS, DXE Phase, PEI Phase, Boot Firmware Volume (BFV), DXE Core.
Базовая система ввода-вывода (BIOS) давно перестала быть простейшей микропрограммой, главной целью которой является инициализация и тестирование на низком уровне аппаратных компонентов компьютера для дальнейшей передачи управления загрузчику операционной системы (ОС). С момента введения единого расширяемого микропрограммного интерфейса (Unified Extensible Firmware Interface, UEFI) BIOS приобретает черты упрощенной современной операционной системы со своими фазами загрузки и механизмами обеспечения безопасности, включая реализацию различных криптографических функций [1].
UEFI также позволяет расширять прошивку платформы, загружая исполняемые образы – драйверы или приложения. Исполняемые образы представляют собой класс файлов, определенных спецификацией UEFI, которые содержат исполняемый код. Загруженные образы получают доступ к сервисам, которые также определены спецификацией UEFI (boot services, runtime services) [2. С. 31]. Исполняемые образы могут быть загружены в память как встроенным менеджером загрузки, так и другими исполняемыми образами [3. С. 17]. Данная возможность позволяет расширять функционал базовой системы ввода-вывода, однако, она создает новые векторы атак в случае неконтролируемого встраивания драйверов.
Существуют штатные механизмы защиты от этих атак. Однако практическая реализация этих механизмов может защитить не от всех атак, а нарушение организационных требований может привести к неэффективности использования штатных средств защиты.
Внедрение в BIOS дает возможность распространить влияние вредоносного кода на все последующие этапы загрузки.
Под угрозой оказываются код управления системой (System Management Mode, SMM), существующие средства защиты, загрузчики, гипервизор и операционная система (ОС). Учитывая, что BIOS запускается с высоким уровнем привилегий на одном из первых этапов загрузки ЭВМ, вредоносный код, исполняемый на уровне BIOS, очень сложно детектировать и устранить на последующих этапах. Для понимания способов инъекций вредоносного кода в UEFI и защиты от них, необходимо ознакомиться со всеми фазами загрузки и возможностями инъекции кода в каждую из них.
Согласно спецификации UEFI система проходит следующие этапы загрузки: Security (Sec), Pre EFI Initialization (PEI), Driver Execution Environment (DXE), Boot Dev Select (BDS) [2. С. 11].
Внедрение в фазу Security невозможно из-за проприетарности данной стадии. В данной фазе подготавливается временная память, адрес и размер которой передаются в фазу PEI. Помимо этого в фазу PEI передается адрес и размер стека, состояние платформы, адрес и размер BFV (Boot Firmware Volume) [4].
В фазе PEI инициализируется RAM для запуска фазы DXE. В фазу DXE передается информация об обнаруженных устройствах для корректной инициализации каждого из устройств. Фаза PEI состоит из ядра и модулей PEIM, осуществляющих первичную инициализацию устройств. Список PEIM может быть расширен путем добавления собственных модулей. Ядро PEI обходит все тома прошивки в поиске всех PEI модулей и запускает их. Порядок запуска модулей не случаен и определяется диспетчером PEI. Модули могут иметь зависимости от других модулей, поэтому сперва запускаются модули, не имеющие зависимостей, затем модули, зависящие от них по цепочке [4].
Код DXE состоит из ядра (DXE Core), диспетчера и драйверов. Ядро инициализирует и запускает службы UEFI. Диспетчер осуществляет поиск всех DXE-драйверов и передачу управления каждому из них. Данные драйверы могут содержать зависимости от других компонентов. Каждый DXE-модуль может осуществлять загрузку и запуск исполняемых образов, одним из которых может выступать загрузчик ОС.
После исполнения драйверов осуществляется поиск загрузчика ОС [4].
Таким образом, инъекция драйвера как в фазу PEI, так и в DXE может нарушить процесс загрузки ОС, запустив исполняемый образ в UEFI. Рассмотрим практический способ влияния на процесс загрузки на примере инъекции вредоносного DXE-драйвера с использованием утилиты UEFI Tool и программатора. UEFI Tool позволяет считывать и редактировать бинарный файл прошивки (BFV), расширяя его исполняемым кодом и различными данными. В качестве примера приведем сценарий встраивания и функционирования вредоносного драйвера в одной из фаз.
Стоит отметить, что такой драйвер может иметь как примитивный вид, так и представлять собой многофункциональный программный компонент. Для простоты понимания можно ввести допущение, что загружаемый исполняемый образ расположен в корне одной из файловых систем. Данное допущение не уменьшает значимости данного вектора атаки на BIOS, так как исполняемый образ может быть загружен в систему в режиме выполнения самим драйвером, содержащего вредоносный код.
Получив список всех файловых систем, драйвер осуществит проверку наличия необходимого образа и, в случае успеха, загрузит код в память и передаст ему управление. Стоит заметить, что для поиска исполняемого образа в коде драйвера могут использоваться протоколы. Как было сказано выше, порядок получения управления различными драйверами строго не определен, а это значит, что на момент выполнения используемые протоколы могут быть еще не доступны для использования. Для обеспечения доступности используемых протоколов необходимо использовать секцию [Depex]. В данной секции указывается список протоколов, использование которых необходимо разрабатываемому драйверу. Эта секция обеспечит получение драйвером управления только тогда, когда системные службы или другие драйверы предоставят доступ к использованию необходимых протоколов, указанных в этой секции.
Считав программатором с чипа бинарный файл прошивки, злоумышленник может приступить к ее модификации. Полученные после сборки исходного кода драйвера файлы необходимо обернуть в определенный формат и добавить в один из томов прошивки системы.
Злоумышленник успешно завершит атаку, записав программатором модифицированный бинарный файл на чип обратно.
Рассмотренный способ влияния на процесс загрузки подтверждает необходимость проверки каждого из DXE-драйверов, получающих управление, так как каждый из них может содержать потенциально вредоносный код. Доверенную загрузку можно нарушить не только инъекцией DXE-драйверов, но и PEI-драйверов. Разработка драйверов PEI (как для вирусов, так и для средств защиты) сложнее, так как недоступна проинициализированная память, протоколы и системные службы. Однако, процедура инъекции PEI-драйвера в один из томов прошивки системы ничем не отличается.
Для обеспечения защиты от неконтролируемого встраивания драйверов программными средствами необходимо обеспечить гарантированное получение управления средствами защиты при каждом старте ЭВМ до запуска модулей PEI и DXE и невозможность осуществить загрузку ОС в обход средств защиты.
Гарантированное получение управления до запуска модулей можно обеспечить только в случае функционирования средства защиты на уровне PEI Core или SEC.
Учитывая проприетарность кода фазы SEC, внедрение компонента защиты в PEI Core представляется правильным. Невозможность осуществить загрузку ОС в обход средств защиты можно обеспечить исключительно путем сертификации BIOS и опломбирования корпуса ЭВМ. Однако, имея сертифицированный BIOS и опломбированный корпус, можно смело утверждать, что компонент безопасности, реализованный в виде DXE-драйвера, получит управление и не позволит нарушить доверенную загрузку, проведя процедуру аутентификации и контроля целостности.
Средство защиты, которое обеспечит проверку драйверов, может быть не только программным, но и программно-аппаратным. Программная составляющая такого средства может также представлять собой DXE-драйвер, который в сочетании с аппаратно-реализованным сторожевым таймером не позволит вредоносному коду продолжить процесс загрузки в обход средства защиты. В случае, если драйвер средства защиты не получит управление через определенное время после старта системы, сторожевой таймер выполнит перезапуск системы аппаратными способами.
Итак, удалось убедиться, что вполне доступными средствами можно осуществить инъекцию вредоносного кода путем расширения BFV DXE-драйвером, более того, это было проделано на практике в стендовых условиях. В то же время эта угроза может быть сведена к нулю, если системную прошивку BIOS UEFI расширить средством защиты, которое будет перехватывать управление при старте, проводить аутентификацию и проверку целостности и в случае успеха продолжать процедуру загрузки.
Список литературы
- Лыдин C. О средствах доверенной загрузки для аппаратных платформ, реализующих спецификацию UEFI // Научно-практический журнал/ФГУП «ВИМИ», М., 2016. Вып. 3. № 114. С. 45–50. URL: http://www.okbsapr.ru/lydin_2016_1.html (дата обращения: 15.05.2017).
- Zimmer V., Rothman M., Marisetty S. Beyond BIOS Second Edition, Intel Press, ноябрь 2010 г. URL: https://www.microbe.cz/docs/Beyond_BIOS_Second_Edition_Digital_Edition_(15-12-10)%20.pdf (дата обращения: 15.
05.2017). - Unified Extensible Firmware Interface Specification Version 2.6 Январь, 2016 г. URL: http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf (дата обращения: 15.05.2017).
- Agneessens J.-F. Analysis of the building blocks and attack vectors associated with the Unified Extensible Firmware Interface (UEFI) (SANS Institute InfoSec Reading Room). URL: https://www.sans.org/reading-room/whitepapers/services/analysis-building-blocks-attack-vectors-unified-extensible-firmware-34215 (дата обращения: 20.03.2018).
05.2017).
Автор: Черчесов А. Э.
Дата публикации: 01.01.2018
Библиографическая ссылка: Черчесов А. Э. Фазы загрузки UEFI и способы контроля исполняемых образов // Вопросы защиты информации. М., 2018. № 2 (121). С. 51–53.
Метки документа:
bios/uefi
доверенная загрузка
уязвимости/угрозы/атаки
выпусков · LongSoft/UEFITool · GitHub
UEFITool / UEFIExtract / UEFIFind A65
25 фев 16:56
Николай Шлей
62d96a1 Сравнить
UEFITool / UEFIExtract / UEFIFind A65Latest
Latest
Выпуск с исправлением ошибок, с огромной благодарностью всем, кто сообщил об этих новых ошибках.
Новые функции:
- Заменен парсер AMI NVAR на парсер на основе KaitaiStruct. Это еще один шаг к цели «свести к минимуму ручной анализ», заявленной путем переписывания парсеров FIT/ACM/BootGuard в KS, другие парсеры, связанные с NVRAM, последуют в следующих обновлениях.
- Добавлены цели фаззинга для фаззеров, совместимых с libFuzzer и AFL, которые уже выявили множество проблем. Исправления сейчас в разработке, будут постепенно включаться в следующие обновления.
- Добавлены
--help (-h)и--version (-v)в UEFIExtract и UEFIFind, это упрощает их использование в скриптах.
Исправления:
- Универсальный пакет macOS для UEFITool снова представляет собой пакет приложений, спасибо @makigumo и @mikebeaton за отчет.
- Текстовый поиск Unicode снова работает, спасибо @nightgolfer и @mikebeaton за сообщение.
- UEFIExtract и UEFIFind снова могут быть собраны с более старыми версиями CMake, спасибо @platomav за сообщение.
- Проблемы с разбором дескриптора и капсулы теперь не фатальные, спасибо @platomav за сообщение.
- Действие «Извлечь тело» не работало для некоторых типов разделов.
UEFITool/UEFIExtract/UEFIFind A64
13 фев 02:40
Николай Шлей
24d61c4 Сравнить
UEFITool / UEFIExtract / UEFIFind A64
Новые функции:
- поддержка темного режима пользовательского интерфейса при переходе на Qt6 для всех выпусков. Подтверждена работа на
Windows 11,macOS 13,Ubuntu 22.04 LTSиFreeBSD 13.1с Qt 6.4.2. Спасибо @yeggor, @vit9696 и @NikolajSchlej. - Сборки Windows разделены на современные версии win64 (использующие статическую сборку x64 Qt 6.4.2) и устаревшие версии win32 (использующие статическую сборку x86 Qt 5.6.3, поддерживаются устаревшие версии Windows вплоть до Windows XP). Если вы используете современные окна, попробуйте сборку win64, так как в ней могут быть неотловленные 64-битные ошибки, характерные для MSVC. Благодаря @NikolajSchlej.
- Поддержка хэш-файла защищенных диапазонов AMI v3. Спасибо @cybojanek за первоначальный запрос на включение и @NikolajSchlej за окончательную реализацию.
Если вы используете современные окна, попробуйте сборку win64, так как в ней могут быть неотловленные 64-битные ошибки, характерные для MSVC. Благодаря @NikolajSchlej.Исправления:
- Qt6 начал использовать sse2 по-настоящему, и это выявило сбой, о котором сообщили @4e4o и @stuarthayhurst, который затем был исправлен @NikolajSchlej.
- В файлах конфигурации CMake отсутствовали цели установки для всех инструментов, поэтому
cmake --installне работал. Теперь благодаря @NikolajSchlej.
UEFITool NE/UEFIExtract/UEFIFind A63
29 янв 22:38
НиколайШлей
3e55a65
Сравнить
UEFITool NE/UEFIExtract/UEFIFind A63
Новые функции:
- благодаря @mikebeaton
- для дисплеев HiDPI, спасибо @NikolajSchlej
- Zlib-сжатые разделы, используемые на платах на основе AMI для процессоров AMD, теперь поддерживаются благодаря @NikolajSchlej
теперь можно вставлять идентификаторы GUID в необработанном формате EDK2 в окно поиска без повторного форматирования вручную.
Поддержка
Исправления:
- несколько небольших исправлений для сбоев, спасибо @yeggor, @hughsie и @NikolajSchlej
- для сборок OpenBSD, спасибо @klemensn
Исправление
Примечания:
- пришлось переключиться на использование моноширинного шрифта для всего пользовательского интерфейса из-за требований HiDPI. Если вам не нравится новый внешний вид пользовательского интерфейса, пожалуйста, откройте вопрос.
UEFITool NE/UEFIExtract/UEFIFind A62
03 окт 20:29
НиколайШлей
662e0bf Сравнить
UEFITool NE/UEFIExtract/UEFIFind A62
Этот выпуск содержит множество мелких улучшений и исправлений мелких проблем, которые оставались нерешенными в течение нескольких лет из-за их незначительности.
Он также добавляет FreeBSD в список поддерживаемых операционных систем благодаря усилиям @pkubaj по созданию инструментов, которые можно создавать там.
Новые функции:
- поддержка x86-64 128Kb Recovery Startup AP Data, специальная 16-байтовая запись по фиксированному адресу внутри файла заполнения в некоторых томах PEI на ПК x86-64, спасибо @NikolajSchlej
- для файлов AMI ROM Hole, которые должны оставаться с фиксированными базовыми адресами внутри образа, благодаря @NikolajSchlej
Поддержка
.
Исправление ошибок и небольшие улучшения:
- исправление сбоя при анализе ME FPT, спасибо @retpoline за отчет и @NikolajSchlej за исправление
- для сборок на Windows с MinGW, спасибо @llxiaoyuan за сообщение и @NikolajSchlej за исправление
- для сборок на нескольких вариантах BSD для разных архитектур, спасибо @pkubaj, @vit9696 и @NikolajSchlej
- для совместимости с C++17, спасибо @yeggor
- для файлов CMake, чтобы сделать UEFITool совместимым с Qt 6. 0/6.1/6.2, спасибо @NikolajSchlej
- для ОС, которые вызывают Qt5 qmake не просто
qmake, аqmake-qt5(Fedora, FreeBSD), спасибо @ValdikSS - исправлений, чтобы сделать статические анализаторы более счастливыми, спасибо @NikolajSchlej
- хак, чтобы парсеры на основе Kaitai делали на одну копию памяти меньше, спасибо @vit9696 и @NikolajSchlej
- новое приложение FlatHub для UEFITool и необходимые для него файлы, спасибо @vulpes2
Исправление
Исправление
Исправление
Исправление
0/6.1/6.2, спасибо @NikolajSchlejИсправление
UEFITool NE/UEFIExtract/UEFIFind A61
10 сен 14:46
Николай Шлей
c4ca232 Сравнить
UEFITool NE/UEFIExtract/UEFIFind A61
Этот огромный выпуск ( более 9000 строк нового кода) наконец-то добавляет поддержку структур Intel BootGuard v2 (о которых @prop263 сделал пиар почти 2 года назад), перереализован с нуля с использованием Kaitai Struct.
Другие изменения, включенные в этот выпуск:
- улучшенный значок UEFITool для сборки macOS, спасибо @vit9696
- Парсеры Intel BootGuard v1 и Intel ACM заменены парсерами на основе Kaitai благодаря @NikolajSchlej
- добавлена поддержка сборок Meson для UEFIExtract и UEFIFind, спасибо @hughsie
- добавлена поддержка сборок CMake для UEFITool (требуется Qt6), спасибо @NikolajSchlej
- добавил больше специфичных для Lenovo идентификаторов GUID во встроенную базу данных GUID благодаря @crass 9.0021
- добавил несколько новых статических анализаторов (PVS-Studio, CodeQL, SonarCloud) в пайплайн CI/CD, исправил большинство обнаруженных ими проблем, спасибо @NikolajSchlej
Отдельное спасибо ребятам из Fiano и CSS, без них я не смог перепроверить новые определения KSY.
UEFITool/UEFIExtract/UEFIFind NE A60
27 авг 18:46
НиколайШлей
2246026 Сравнить
UEFITool/UEFIExtract/UEFIFind NE A60
Первый выпуск 2022 года в основном предназначен для тестирования новых универсальных двоичных файлов для macOS (т.
е. когда единый двоичный файл создается как для x86-64, так и для arm64), но в нем также есть некоторые улучшения и исправления:
- добавлена поддержка анализ некоторых образов HP, которые используют GUID EFI_GUIDED_SECTION_LZMA_HP для своих сжатых LZMA разделов, спасибо @yeggor
- добавлена поддержка действий «Извлечь несжатое…» и «Несжатое шестнадцатеричное представление…» в UEFITool, оба они полезны при ожидании необработанных несжатых данных сжатых элементов и помогут обнаружить и исправить некоторые другие невидимые проблемы, такие как #178. , спасибо @NikolajSchlej
- добавлена поддержка правильного синтаксического анализа заголовка ME File Partition Table версии 2.1, улучшен синтаксический анализ предыдущих версий 1.0 и 2.0, спасибо @NikolajSchlej и @platomav
- исправил CI\CD, обновил его конфигурацию для использования более новых бегунов, исправили некоторые предупреждения Coverity, обнаруженные, потому что он снова работает, благодаря @vit9696 и @NikolajSchlej
- собрал Qt 5. 6.3 как универсальную библиотеку для macOS и обновил unixbuild.sh и CI\CD для создания универсальных двоичных файлов вместо x86-64 для macOS, спасибо @vit9696 и @NikolajSchlej
6.3 как универсальную библиотеку для macOS и обновил unixbuild.sh и CI\CD для создания универсальных двоичных файлов вместо x86-64 для macOS, спасибо @vit9696 и @NikolajSchlejА59
14 окт 01:26
vit9696
d9af12b Сравнить
- Исправлено зависание синтаксического анализатора области расширения CPLD
- Улучшен парсинг МЭ с помощью MEParser
- Добавлена совместимость с Qt6 для пользовательских сборок, спасибо @vampirecat35
- Готовые бинарные файлы Linux изменены, чтобы требовать Ubuntu 20.04
- Исправлено несколько проблем с парсером изображений Z590, спасибо @joevt
- Добавлен идентификатор GigaDevice GD25LQ16V, спасибо @realnickel
- Добавлено больше распознаваемых имен файлов GUID, спасибо @assafcarlsbad
А58
07 ноя 18:02
vit9696
7bce6fa Сравнить
- Исправлено несколько сбоев со специальными параметрами Boot Guard
- Исправлен парсинг нескольких прошивок Lenovo
0.
28.0
24 мар 05:01
вит9696
0.28.0
д9642с5
Сравнить
0.28.0
- Добавлена поддержка «Не перестраивать» для томов
- Добавлена поддержка разбора/восстановления разделов LZMAF86
- Добавлены новые исправления блокировки EIST для UEFIPatch
- Исправлено неправильное обращение с новой строкой в конце в UEFIPatch
.
А57
24 мар 05:06
vit9696
fc2d8f0
Сравнить
- Фиксированная контрольная сумма ввода FIT (#189)
- Исправлен бесконечный цикл из-за файлов тома нулевого размера (#191)
- Исправлены сбои при разборе некоторых образов прошивок
- Исправлена проверка подписи CPD
- Фиксированное обнаружение микрокода (#194)
- Добавлена поддержка разбора разделов LZMAF68 (#197)
- Разрешено использовать клавишу ввода/возврата в виджетах списка для навигации (#200)
- Исправлен сброс полноэкранного режима окна после закрытия приложения (#202)
- Добавлена печать родительской информации для найденного элемента (#203)
UEFITool — Скачать
Обзор Softonic
Бесплатный редактор изображений UEFI
UEFITool , как и Ventoy и Boot-Repair-Disk, представляет собой бесплатную модификацию UEFI , которая дает вам доступ к UEFI-совместимым утилитам.
В Windows он имеет простой интерфейс, который позволяет анализировать, редактировать и просматривать образы BIOS и настройки прошивки UEFI. Ключевым моментом является импорт данных в файлы изображений, которые затем могут служить основой для их настройки.
Профессионалы обычно меняют прошивку UEFI , однако UEFITool позволяет новичкам понять, как это работает. Он также совместим с различными типами BIOS и предлагает множество других функций. У вас есть возможность использовать обычные или расширенные настройки.
Как изменить UEFI?
Работа с настройками BIOS может быть сложной, особенно если вы не знакомы с этой процедурой. Цель UEFITool — упростить процесс, предоставив лучшие методы для интерпретация и изменение настроек без причинения вреда. Вы просто импортируете файлы как изображения и вносите изменения перед их повторным экспортом. Удобный интерфейс UEFITool — это первый компонент, упрощающий изменение UEFI.
Все удобно расположено в окнах, где вы можете получить всю информацию, необходимую для начала работы. Конечно, прежде чем вы сможете внести какие-либо изменения, вам нужно понять, на что вы смотрите. UEFITool отображает данные в формате легко читаемый образом. Изображения, такие как BIN, BIO, ROM, CAP, WPH, FD и EFI, — это некоторые из типов изображений, с которыми вы можете поэкспериментировать с помощью этого инструмента.
Если вы знаете, что делаете, вы можете добавлять и удалять компоненты по своему усмотрению. После внесения необходимых изменений у вас есть возможность сохранить образы BIOS и настройки прошивки UEFI на устройстве Windows или на внешнем USB-накопителе в качестве последнего шага. Если вы хотите получить отзывы других разработчиков об изменениях, вы также можете опубликовать их в открытом доступе.
Легко изменить прошивку UEFI
Для тех, кому внесение изменений в UEFI утомительно и несколько сложно, UEFITool послужит отличным решением.
У вас будет базовый пользовательский интерфейс , простой для понимания и навигации, что значительно облегчит вашу работу. Более того, вы сможете быстро экспортировать любую свою работу после того, как закончите. Это также полезно для тех, кто хочет изучить и попрактиковаться в обращении с этим типом инструмента.
Pros
- Импорт File Bios Files
- View, Edit и Analyze Images
- Поделитесь изображениями другим пользователям
Cons
- Подходящие больше для опытных пользователей UEFI
Программа, доступные в других LabrageS 9003
- Скачать UEFITool [ES]
- Загрузить UEFITool [FR]
- 下载UEFITool [ZH]
- Скачать UEFITool [NL]
- Tải xuống 9 0VI UEFITool0020 СКАГАТА Скачать do uefitool [PT]
- Scarica uefitool [It]
- Pobierz Uefitool [PL]
353592
Top Developments для Windows
- 535353535353
.
- 535353535353
0192019
019201920192019. [DE]
Реклама
Возможно, Falseclock знает о них немного больше. 
п., и тело — в нем хранятся собственно данные. Текст же в заголовках не хранится, поэтому для него такой выбор не нужен.
к. позволяет произвести модификацию какой-либо части UEFI, не затрагивая при этом структуры всего образа.
Этот вариант настраивается средством специальной оболочки UEFI BIOS Utility. О том, как ею воспользоваться, мы и желаем поведать в статье дальше.
Для этого на главном окне оболочки кликните по кнопке «Exit/Advanced Mode» и воспользуйтесь вариантом «Advanced Mode». На неких версиях UEFI подходящий пункт представлен отдельной кнопкой понизу экрана.
Учтите, что последняя функция также может находиться на вкладке «Advanced».
, спасибо @NikolajSchlej
27.0
В Windows он имеет простой интерфейс, который позволяет анализировать, редактировать и просматривать образы BIOS и настройки прошивки UEFI. Ключевым моментом является импорт данных в файлы изображений, которые затем могут служить основой для их настройки.
