UEFIReplace

[LSSoniX]

Всем доброго здравия.

Если не трудно то внесите следующие изменения:
1 - убрать создание нового файла с расширением .patched,. То есть изменение сохранять в файл с тем же именем, что задан в комманднной строке.
2 - добавить новый ключ <ALL}ONE>.
2.1 - ALL - менять по всему файлу биос пока найден заданный GUID
2.2 - ONE - менять только один раз, как реализовано на данный момент
UEFIReplace <ALL|ONE>

Благодарю.

[vit9696]

Привет,

1. Перезаписывать файл без ведома юзера — это дикость :), не надо так делать, особенно с учётом сравнения результатов. Если надо сохранять в отдельное место, то для этого можно сделать аргумент. Добавил как -o / --output и соответственно путь к файлу в UEFIPatch и UEFIReplace.

2. Добавил в качестве аргумента -all. По умолчанию пусть останется замена один раз. Меньше — лучше.

Изменения пока в отдельной ветке:
https://github.com/LongSoft/UEFITool/tree/uefirepl

Есть на чём проверить?

P. S. Это же ты UBU занимаешься? Не хотите её портировать на macOS? Полезная штука, но вендор-lock вызывает острую неприязнь, ahem…

[LSSoniX]

Я не против создания бэкапов, но в данном случае создает некоторые неудобства при пакетной обработке. Те после завершения замены придется задавать обработку переименования bios.bin.patched в bios.bin.
Спасибо, опробую все новые аргументы.

PS если честно я с МасОСькой не работал никогда, даже не представляю если у нее своя пакетная обработка. Сейчас бы под венду до ума довести и уменьшить зависимость от мумутула.

[LSSoniX]

Упс! Прошу прощения, а где пересобраный экзешник можно забрать на потестить? :))

[vit9696]

Ну, теперь в принципе можно сохранить в тот же файл, указав его в output. Однако это должно происходить осознанно.

В случае macOS там обычный bash, у которого очень даже гибкий скриптовой язык. Он используется в том числе в Linux, поэтому в Windows 10 можно попробовать прямо из надстройки Linux поверх Windows. Мануалов в том числе на русском в интернете масса.

Системы сборки под Windows у меня нет, сделал отдельно тег, куда собрались файлы с данными изменениями.
https://github.com/LongSoft/UEFITool/releases/tag/t19052018

[LSSoniX]

Уже забрал и протестил.
Я пока проверяю замену ОРОМок в контейнере GUID А032?, они там лежат фриаомами
В общем -о работает без проблем.
Для тестирования взят биос от Асрока X99M Killet 3.1 v3.90, в нем 2 оромки
Скрипт просетнький
[code]
@echo off
set subguid=
for /f "tokens=1,2" %%a in ('uefifind body list 5043495286802228 bios.bin') do (
set subguid=%%b
if defined subguid (
echo %%a %%b
uefireplace bios.bin %%a 18 SataOrom.bin -o _bios.bin
)
)
[/code]
По скрипту находим все оромки ирст и делаем замену, но что происходит.
Без опции -all находит все оромки, их 2, но заменяет только первую, вторая не меняется хотя сообщение о замене выдает.
С опцией - all идет падение.

[LSSoniX]

Сейчас выявил еще одну большую неприятность.
В биосах АМИ на платформе Аптио 5 в контейнере с GUID А032 могут находится не только оромки, но и ефи, например GOPDriver. Еслм смотреть последовательность расположения файлов GOP обычно всенда первый, но вместо него может быть и дургой ефи драйвер или оромка сети.
Так вот, менявначале удивило, почему в УР для замены указывается основной GYUD, а не SubGUID фриформы.
В результате проверки по замене ором ирст, гоп был заменен на оромку.
Те по сути получается, что УР в таких контейнерах меняет первый файл и сваливает

Думаю, что надо для SecType 18 указывать не основной GUID, а SubGuid мли сразу парой.
К сожалению в данном варианте УР не принимает SubGUID или GUID+SuvGUUD

[LSSoniX]

Те строка должна быть более полной
УР <биос файл> <GUID [SubGUID]> и тд
В противном случае будет замена первого встречного или всех подряд найденных.

[vit9696]

Рекурсию я поправил, опять наткнулся на грабли, что замена тела происходит через удаление старого и добавление нового после.

Насчёт GUID/SubGUID. GUID — достаточно случайная величина, вбивать два — это как-то совсем ненормально. Прикрутил небольшой костыль, чтобы можно было для freeform subtype guid (0x18) указывать guid конкретно freeform. Не очень, но в принципе должно работать. Думаю, с ребятами ещё это надо будет обсудить, но пока попробуй.

https://github.com/LongSoft/UEFITool/releases/tag/t19052018r3

[LSSoniX]

Без костылей никак. У меня DtvVer сплошные костыли. :)) Ладно, лишь бы работало корректно.

В общем прогнал сборку r3 по фрифоромам, меняет всё как нужно по SubGUID.
Замена тела по SecType 0x10 тоже без проблем проходит и вполне корректно.

Осталось еще 2 основных замены, это весь FFS и RAW.
Для замены уже собранного FFS я пробовал SecType 0x00, возможно надо было другой?
Для замены RAW секции SecType 0x19,
В обоих случаях я получал токо один ответ от УР
[quite]
No replacements can be applied to input file
[/quite]
Соответсвенно замены никакой.
Самое простое это пробовать менять микоды в GUID 1708.... Или весь уже собранный FFS или токо микод как RAW.

PS возвращаясь к теме о портировании UBU на другие ОСЬки. У меня уже были запросы, вся проблема в мумутуле. Если удастся от него избавиться от него хотя бы на 90% можно будет подумать. Пока мы сильно завязаны на нем..

[vit9696]

В случае Raw секции у меня всё работает, пробовал на твоём файле вот так:

./UEFIReplace/UEFIReplace X99MK3_4.00 B733C141-E88F-4786-94AF-8B87BC4867FE 0x19 Raw.raw 
parseVolume: non-UEFI data found in volume's free space
File replaced

Если у тебя что-то не работает, то лучше приводи полный пример, что делаешь и как.

В случае замены ffs целиком можно подумать, как это сделать. Сейчас заменяется содержимое в формате "replace body", в принципе можно добавить флажок, чтобы менялся ffs целиком ("replace as is"), но для этого опять же нужен конкретный пример.

Сейчас мне не до UEFITool, но если подробно опишешь что не так, в свободное время постараюсь сделать. Восстановить test-case по сообщению выше трудновато.

[LSSoniX]

Хмм.. Значит, что то в самой RAW или я чего то не понимаю.
Хорошо, я попробую изложить все замечания на данный момент.
1 - Сообщение "No replacements can be applied to input file" оно абстрактно и вводит в непонятки в чем проблема. Не найден GUID, не верна SecType или еще что?
К примеру мы хотим заменить файл EFI IRST, нам точно известны GUID и SecType РЕ32
даем последовательно 4 комманды на замену

Указываем` неправильный GUID
uefireplace bios.bin 01B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver.efi -o bios.bin 
No replacements can be applied to input file

Указываем не правильно SecType
uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 19 raiddriver.efi -o bios.bin 
No replacements can be applied to input file

GUID and SecType указаны правильно
uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver.efi -o bios.bin 
File replaced

Просто повторяем ради интереса  GUID and SecType верные
uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver.efi -o bios.bin 
No replacements can be applied to input file

Только третья понятна, остальные сиди и думай, что там не так.

2 - По RAW, контейнер с микрокодами

uefireplace bios.bin 17088572-377F-44EF-8F4E-B09FFF46A070 19 mcode.bin -o  rplmCode.bim
No replacements can be applied to input file

Ну вот, что не так? Я уже перепробовал на всех популярных брендах с чипсетами от 6-ого до 370-ого Одна и та же картина.
Файл биоса любой с Интел микодами. сами миккоды https://github.com/platomav/CPUMicrocodes/tree/master/Intel

3 - По FFS.
В общем суть в чем. В амишных бивисах обычно по 2-3 контейнера с микрокодами, GUID выше. Одиг тх контейнеров "пустышка", те забит 0xFF. Зачем он нужен мы так и не поняли до сих пор, но чтобы обновить контейнер с микрокодами надо эту "пустышку" как то обходить.
Для обхода я сделал так:

• ищем GUID 1708... и если есть извлекаем
• проверяем его содержимое
  -- если это не "пустышка", то заменяем FFS с другим GUID в конце которого к примеру 02
  -- если "пустышка", сохраняем в отдельный файл и заменяем FFS с другим GUID на конце 01
  и так до тех пор кока найден реальный GUID
• после того как подмена закончена делаеи обратку
  -- заменяем все FFS GUID с концом 02 на реальный GUID с микрокодами
  -- возвращаем обратно "пустышку" с реальным GUID вместо, того еа конце которого 01
  Вот такая процедурка..

Вообще, если удастся менять RAW с микодами, то замена всего FFS не нужна будет, достаточно только менять header/GUID, те к примеру коммандой
uefireplaxce GUID2> -o outfile

НУ вот так как то.

[vit9696]

Во, теперь понятнее. У тебя секция, которая состоит в виде файла без body. Понятное дело, что она не заменяется. Поправил. Делать так:
uefireplace bios.bin 17088572-377F-44EF-8F4E-B09FFF46A070 1 mcode.bin -o rplmCode.
Также на всякий случай добавил опцию -asis, чтобы можно было заменить файл целиком.

[LSSoniX]

Если не трудно, то объясни пожалуйста, если файл уже поменяли и тут же снова его хотим заменить, то замена не происходит, почему? (это про действия последовательно 3 и 4)

За текушие изменения спасибо. Буду теститься дальше. :))

[vit9696]

Проверь в UEFITool, там guid файла мог смениться.

[LSSoniX]

Проверил, GUID 91B4D9C1-141C-4824-8D02-3C298E36EB3F не сменился.
Вроде как на проверку похоже.
Если сначала заиенть файл например 14 версия, потом опять же его попытаться заменить, то не меняется, а если тут же предложить заиенить другую версию, то замена проходит.

uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver.efi -o bios.bin
File replaced
uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver.efi -o bios.bin
No replacements can be applied to input file
uefireplace bios.bin 91B4D9C1-141C-4824-8D02-3C298E36EB3F 10 raiddriver2.efi -o bios.bin
File replaced

С одной стороны это хоршо, но вот из за комента не понятки.
Ладно, с этим может со временем разберемся.
Я забыл уточнить как юхать -asis?

[vit9696]

А, тогда понятно.

В случае -asis просто добавляй в конец командной строки при необходимости, просто заменит не в режиме body, а как есть целиком.

[LSSoniX]

А в SecType чего ставить, что в голову вбредет или как?

[vit9696]

В соответствии с Type/Subtype UEFITool или по содержимому, как и раньше.

[LSSoniX]

То есть, если я меняю FFS non-body RAW, то 1. Если FFS с body РЕ32 то 10 и тд?

[vit9696]

Да, так должно работать. Но в случае с 1 можно и без -asis, когда надо заменить просто микрокод.

[LSSoniX]

Понял. Благодарствую. Поток пока не закрываю, мало ли чего вытестится. :))

[vit9696]

Хорошо, давай тогда оно повисит хотя бы до конца недельки, а там можно релиз уже, чтобы никого не путать.
P.S. Очень рассчитываю на версию для macOS :)

[LSSoniX]

Хорошо. Постараюсь за неделю.
На данный момент оттестил -asis. Всй работает только надо быть очень аккуратным.
У меня подмена была в Freeform, муму по барабану что там подпихивают, но это муму..
В общем замена RAW на Free через указание SecType = 1 без проблем, а вот в обратку через 1 понятно, что не пойдет, а вот если 18 подставить, так вообще свистопляска. :))
Но это не трогаем, я перегенерил подменки под RAW и теперь всё через 1 заменяет как надо.
Думаю проблему с обновлением микодов на Аптио 5 платформе решили.
Осталисб PE32 и Freeform ОКОМок, но с ними вроде как проблем нет. Но недельку погоняю.

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

По ортированию надо будет в UEFIEtract добавить -о, при этчтобы FFS извлекался в расжатом виде, иначе версии файлов не увидеть На данный момент за извлечение муму отвечает, а втом виде который УЕ выдает задолбаещься пути папок считывать и прописывать..
Но это попозже, сначала с заменой надо докопать.

[LSSoniX]

Забыл про скрин почему сообщения от Парсера kexit отключить.
Кому надо тот в УТ всё увидит, в строке как то перебор, лмбо во все утили добавить аргумент для вывода парсера -parser

[LSSoniX]

Или может сделать вывод сообщений от Парсера в отдельный файл?
При тестировании замены FFS RAW (sectype 1, -asis) с микодами получил вот такие сообщения, на скрие.

[LSSoniX]

Разобрался с последним скрином, были заданы сразу 2 аргумента - all -asis
Если -all убрать, то всё пучком.

[vit9696]

Привет,

Насчёт микрокодов. Я правильно понимаю, что теперь есть какие-то сложности использования микрокодов отсюда? https://github.com/platomav/CPUMicrocodes В UBU далеко не всегда есть актуальные версии микрокодов, поэтому часто нужно брать из репозитория platomav, их как-то надо будет теперь конвертировать или UBU это сделает сама?

UEFIExtract — это new_engine ветка, так что к ней можно будет вернуться после. Аргумент для пути сохранения вполне логичен, а вот по расжатию там надо будет подумать ещё.

По поводу логов. Я редко использую Windows, а под cmd не писал ничего ещё больше, но разве там не работает самый обычный редирект сообщений? Типа:

command.exe > file.txt

Это функция ОС, зачем её дублировать в программе?

[LSSoniX]

Привет.

По микодам. В UBU обычно для дектопных с 6 по 370 серии. чипсетов. Обновки берутся с репы Плато по той самой ссылке. Если нужны инженерики или более ранние версии, то пишем Плато и просим прислать. У него по моему уже полная коллекция. :))
В версии 1.70 я сделал так, чтобы был легче добавлять/удалять/менять микоды.
Размещаются предуставновленные в папке Files\Intel\mCode дальше по сокетам.
Список на обновление в файлике MCUpdate.txt, вот редактируя его можно мзменять и "хулиганить"
IBU читает CPUID из этой текстульки и ищет его в бивисе Если найдено то путь с микодом добавляются в переменную, потом собирается FFS и меняется в бивисе.
Единственная проблема, что мне бывает трудно добавлять обновленные верси микодов и МСЕ.
А так всё просто кто докопался до истины. :))

Хорошо. Закончим с УР потом в новый движок кину пару предложений по УЕ и УФ (extract & finder)

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

[vit9696]

Так, ещё раз.

Если тебе нужно скрыть сообщения парсера — это дело не UEFIReplace, а твоё собственное. Как я уже сказал, сообщения легко перенаправить в файл (в Unix это специальный файл /dev/null, который поглощает любой ввод). Погуглил, в Windows это NUL.

Результат работы утилиты должен проверяться не по её логу, а по коду выхода из программы ($? в Unix). Судя по гуглу, на Windows это %errorLevel%. Успешно — это всегда 0. Не найдено патчей — 41, всё остальное можно посмотреть в basetypes.h в репозитории.

[LSSoniX]

Бррр.. Мы говорим вроде об одном, но по разному. :))
Сообщения которые выдает УР "File replace", "Errro", "No replacement,,,," и тд эти остаются как есть.
Я говорю о сообщениях двиэка, выделил, на предкартинках их тоже заметно много

. В Уефифайндкре они отключены, хотя вначале были.

[vit9696]

Мы говорим об одном, но имеем в виду разные вещи. Я тебя понял, и считаю, что сокрытие подобных сообщений — неприемлемый костыль, который не нужен в UEFIReplace. Подробный лог должен сохраняться в файл для изучения юзером при необходимости. Результат работы программы должен определяться по коду её выхода. То, что ты выводишь всё внутри UBU — это твоё право, но как говорится сам виноват.

[LSSoniX]

Уговорил, будут доставить вопросами по этим сообщениям буду отсылать сюда. :)
Лады, тогда -all отключи, я проверю еще раз.
Причина в том, что асусовы бивисы для 9-серии содержат в себе 2 GOPDriver, которые почему то размещаются не в томе DXE, а втомах PEI. Имеют одинаковый GUID и SecType PE32/
Так вот, если я не задаю -all оба меняются, а задаю - файлы меняются, но при этом еще и парсер ругается. Вот и думаю, что уже изначально было заложено пройтись по всему бивису и сделать замену везде где совпадет GUID и SecType.
Я эе поторопился с этим кл.чом из за FFS RAW который не поддерживался вначале и видимо зря.
Поэтому надо еще раз пересобрать и перепроверить.

[vit9696]

Что-то странное, перепроверь всё ещё раз. Если реально так, кидай файл с примером и точную последовательность действий.

Я пересмотрел сейчас весь код, и могу сказать, что на первый взгляд там всё корректно.

Если -all не указывать, то логика осталась как раньше: происходит замена первого найденного вхождения (одной секции), и происходит завершение работы программы. Если -all указан, то в цикле будет совершён обход всех файлов.

Никаких третьих вариантов быть не должно.

[LSSoniX]

Упс! Мой косяк в скрипте, забываю, что для мумутула надо подмену делать, чтобы до следфайлов докопаться. Прошу прощения, был не прав.. Без -all первый файл и выход, с -all все и выход
Перепроверил раз 5 с распаковкой через УЕ.

В общем, основные замены работают. Можно топик закрывать.

PS По -о в экстракторе и в файндере кое что поменять на следнеделе тогда новый поток открою