Появилось несколько вопросов, да и я кое-что вспомнил, так что давайте поговорим:
Денис спрашивал, почему у него в видеобиосе отличаются адреса строки с ошибкой и ссылки на неё по сравнению с моим примером?
Ответ простой - потому что это другая видеокарта и у неё немного другой видеобиос, а значит отличия в адресах абсолютно естественны.
Не переживайте, просто делайте всё по аналогии с моим примером, но с учётом своих адресов.
Если не заработает, то придется ковыряться с IDA. Как это сделать я расскажу чуть ниже.
Сергей М писал(а):
Vadimi4
Статья супер! Все доступно.
Использую эту методику можно и WhiteList HP и IBM обходить, как я понимаю.
Сергей, спасибо! Да - примерно таким образом исправляют и whitelist в биосах, но в тех нескольких статьях, которые я читал на хабре по этому поводу (один товарищ корректировал whitelist в HP а другой в Lenovo - неплохие, кстати, статейки) я увидел пару важных отличий от описанной мной корректировки видеобиоса: во-первых в статьях говорилось, что проверка whitelist устроена несколько хитрее и на самом деле там не одна проверка а две или три, а во-вторых авторы ни разу не упоминали о корректировке контрольной суммы, отредактированного ими модуля.
Почему у них работало без корректировки контролной суммы - не знаю. Может в модуле с whitelist её вообще нет...
Теперь опишу пару моментов, которые я не осветил в предыдущих сообщениях.
1) Во время своих продолжительных экспериментов с видеобиосом и его интеграцией в биос, сталкивался со следующей ошибкой в phoenixtool:
Changes detected in OPROM00.ROM
New OPROM00.ROM Module is 4 bytes too big
New OPROM00.ROM Module is 4 bytes too big
OPROM00.ROM not reintegrated
Unable to reintegrate OPROM00.ROM
Что сие означает? Это означает, что phoenixtool не умеет интегрировать в биос модуль, который больше чем оригинальный модуль. Вроде бы глупость - мы же размер файла не трогали, а просто поменяли значения двух байт. Но дело тут вот в чем - модули в биосе хранятся в запакованном (сжатом) виде. И наши манипуляции повлияли на то, что модуль не получается сжать до его оригинального размера!
Что делаем? Для начала думаем: как работает простейший алгоритм сжатия? Он заменяет цепочку последовательных одинаковых блоков на один такой блок и указатель количества его повторов. То-есть, если мы имеем строку
KKKLLLL то, после сжатия простейшим алгоритмом, получим
3K4L .
Значит пробуем поменять что-нибудь в видеобиосе так, что-бы получилась несколько последовательных одинаковых символов, причем не важно каких именно. Но что можно безболезненно поменять, ведь там же всякие команды, которые явно не стоит трогать? Тогда давайте поменяем что-нибудь в текстовых строках! А именно в той, которая, как мы надеемся, скоро станет совершенно бесполезной
:
Готово! Не забываем снова откорректировать контрольную сумму и пробуем интегрировать полученный модуль в Phoenixtool.
У меня, после этих манипуляций, ошибка больше не вылетала.
2) Я показал в предыдущем сообщении скрин IDA, но ничего не рассказал, как Вам получить такое-же. Исправляюсь! Но прежде, должен уточнить, что до данного случая с видеобиосом, я IDA в глаза не видел и никогда в ней не работал. Так что я могу лишь показать как делал я, но наверняка спецы по этой программе смогут рассказать о более простых и правильных путях получения того-же результата.
Итак, запускаем IDA, открываем наш модуль видеобиоса и получаем окно, с параметрами загрузки нашего модуля. В данном окне, нам нужно выбрать тип процессора, для которого написан наш модуль. Очевидно, что у нас это x86, причем какой именно - не особо важно. Но давайте выберем самый современный из доступных:
Затем мы получаем вопрос от программы, в каком режиме битности мы хотим дизассемблировать наш модуль, в 16-бит или 32-бит?
Тут мы должны вспомнить, что обычный PC-BIOS имеет ряд ограничений (16-битный исполняемый код, адресуемая память 1 Мбайт, аппаратные ограничения IBM PC/AT и т. д.), а значит ваш самый современный 64-разрядный процессор на этапе загрузки биоса работает в 16-разрядном режиме
. Кстати обход этих ограничений, пожалуй, и есть самое большое новшество в UEFI.
Итак, нам нужно дизассемблировать в 16-битном режиме, а значит нажимаем в окошке кнопку
No.
Ну вот, мы загрузили модуль. Что теперь? А теперь нам нужно перейти к тому месту, где происходит наша проверка (в моём примере - это
D5C5) и скомандовать ИДе, что-бы она попробовала преобразовать машинные коды в понятный ассемблерный код. Делается это так - становимся курсором на нужной нам строке и нажимаем клавишу
C на клавиатуре (или через меню -
Edit -> Code):
Какие могут быть грабли? Ну, например, вы могли выбрать не ту строку, с которой скомандовали начать преобразовывать код и на выходе у вас будет какая-то фигня. В нашем случае, если стать прямо на строку по адресу
D5C5 и нажать
С, то мы получим ерунду, так как по этому адресу у нас записан аргумент (адрес) для операции mov, а мы заставили ИДу попытаться преобразовать его в инструкцию.
Код:
mov di, 0B9E7h
Что делать? Нажать кнопочку
U, для того, что-бы все вернуть назад и сместившись на одну или несколько строк вверх/вниз попробовать снова преобразовать в код. Таким образом "прощупываем" интересующий нас кусок и находим наш алгоритм проверки. В нашем примере, начало этой проверки находилось на 17 байт раньше (
D5B4) чем ссылка на строку с ошибкой (
D5C5).
Вроде-бы всё рассказал из того, что знал.
Будут вопросы - welcome в личку или сюда - постараюсь помочь.
Успехов!