Решил вынести в отдельную тему, хотя может можно было кинуть в теоретические вопросы. Ну если что , перекинте...
Облазил форум, многие темы посвящены конкретной плате, а у меня вопрос следующий.
Очень хочется просто прочитать BIOS. Не перезаписать, а просто прочитать. Да, уточнение, чтение на этапе загрузки, то есть осуществляется из кода BIOS платы расширения. Прочитав умные книги
, выяснил, что как минимум у AWARD и AMI BIOS отображается на область памяти (FFFFFFFFh - объем чипа BIOS). То есть возникает резонное предположение о возможности просканировать эту область памяти и соответственно быть отправленным южным мостом в чип BIOS (хотя может он уже в этот момент туда и не отправляет). Однако где-то в этой области возникают непонятки, в смысле, то ли что-то там отображается из внутренних регистров чипа, то ли код распакованного BIOS меняется после каждой загрузки, но в этой области памяти некоторые участки изменяются при перезагрузке, хотя остальные совпадают с образом, скачанным с сайта производителя. Кстати, как отображается память BIOS у других производителей, в том числе IBM? Кто дизассемблировал, подскажите!
В общем, вопрос следующий. Как можно просто прочитать BIOS на этапе работы самого BIOS ( то есть при выполнении BIOS платы расширения), можно ли разрешить чтение напрямую из флеш-биос путем программирования его регистров, можно ли как-то универсализировать эту процедуру, хотя бы в рамках одного производителя (используются может одни и те же регистры для разрешения чтения)??? Или это вообще гиблое дело???
Пожалуйста, высказывайте мнения, Все интересно!!!
<font size="1">> Именно это - прошивка посредством упомянутых "хуков" и было сделано в runiflash - в противопоставление используемому по умолчанию "классическому" способу.
</font><font size="2">Мне чертовски хочется в своем плагине-читалке обойтись без использования этих хуков. Да и хуки эти под виндами просто так вызвать не получится
У меня вопрос - на Ваш взгляд, потребуется ли для выбора (и возможного редактирования) нужного скрипта учитывать еще и название матплаты?
Могут ли существовать в природе две матплаты с одинаковыми чипсетами+SIO, но с принципиально разными наборами операций для доступа к ПЗУ? </font>
В таких случаях я не мешаю течению предсказуемого путешествия по граблям... :)
С поправкой на то, что в последних BIOS уже предусмотрен 32-битный вход для хуков (хотя обычно они прошиваются через SMM).
Видоизменённая в сторону amiflash идеология uniflash. Оба закончили плохо. Бесконечная борьба с ветряными мельницами.
При "классическом" подходе - в обязательном порядке. Именно для подобной операции Rainbow добавил в одной из версий считывание DMI.
Могут и существуют. Именно эта особенность современного BIOS-прошивания и является причиной вышеизложенных комментариев о неперспективности "классического" способа с поправкой на то, что это отличный повод для самообразования.
Но зато какое увлекательное!
<font size="1">> В таких случаях я не мешаю течению предсказуемого путешествия по граблям...
<font size="2"><font size="1">>Именно эта особенность современного BIOS-прошивания и является причиной вышеизложенных комментариев о неперспективности "классического" способа</font> </font>
</font>
Для тестирования плагина такие грабли как раз и разыскиваются. Но пока безуспешно.
Да, для защиты от записи биоса разработчик матплаты может, например, повесить требование изменения хитрого битика в произвольном плато-специфичном GPIO-порту.
Но в этой ветке форума обсуждается не перепрошивка биоса, а всего лишь чтение прошивки.
Для чтения прошивки разрешение на запись требуется только для того, чтобы "записать" в ПЗУ команды для определения Vendor_ID+Device_ID этого ПЗУ. А затем узнать размер этого ПЗУ - 128/256/384/512/1024 кбайт. И всё. Больше нам это разрешение на запись не потребуется. Но эта информация не критична - по "внешнему виду" прочитанного (с запасом) файла прошивки можно догадаться о размере ПЗУ. Или отодрать наклейку на флешке
Теперь осталось настроить чипсет для доступа на чтение конца 4-го гигабайта. Здесь злобные разработчики матплаты/биоса бессильны, ибо алгоритм настройки определяется только чипсетом.
Итак, как мне кажется, для чтения прошивки классический (нехуковый) подход вполне жизнеспособен.
PS
О граблях. Было бы интересно ознакомиться с матплатой, биос которой успешно считывается программой runiflash, но классический подход для чтения прошивки не будет работать.
Не "может", а "как правило - делает". ;)
Стандартное подмена тёплого на мягкое. Если задуматься на два хода вперёд - получим: получив возможность прочитать всю флэшку - мы имеем (корректный) доступ ко всем её ячейкам. А раз имеем - сможем (с поправкой на наличие алгоритма прошивки плюс снятия защиты от записи бутблока сотоварищи - уже программной, относительно самой флэшки и т.д.) и переписать. Итого: можем читать = можем писать. Итого из итого: в отношении "защиты от записи" - обычно неверно разделять эти понятия, т.к. не сняв оную (защиту как бы от записи) - мы не размапим чипсет, а значит корректно и не прочитаем (и не прошьём).
Всё сказанное имеет много оговорок, т.к. реализации разнятся и по производителям плат, и по производителям BIOS, и по "исторической" переменной... Но суть сказанного одна: ставить целью реализовать (лишь) "классическую" схему (в плане прошивки) - обречено на провал. Хотя не отрицаю, что в области "чтения" - можно достичь определённых успехов (особенно на старых платах ;) ).
Можно начать и закончить практически любым Абитом. :)
Или даже проще глянуть внутренности того же unfilash, где стоят условия на совпадения с "исключительными случаями". Вот, в частности, кусок кода:
Как говорится - без комментариев...
<font size="2">apple_rom
</font><font size="1">> Можно начать и закончить практически любым Абитом.
</font>У меня как раз есть одна плата Abit (VP6, 01/17/2001-694X-686B-6A6LJA1EC-WK)
Проведем эксперимент.
Отключаем разрешение на запись...
// "VT82C686A" ISA Bridge
//Offset 43 - ROM Decode Control
//Setting these bits enables the indicated address range to be
//included in the ROMCS# decode:
// 7 FFFE0000h-FFFEFFFFh
// 6 FFF80000h-FFFDFFFFh
// 5 FFF00000h-FFF7FFFFh (Rev H)
virtual void enableFlashAddrRange()
{
DWORD address = m_bdf | 0x43;
BYTE b43 = read_pci_regb(address);
write_pci_regb(address, b43 | 0xe0);
// ROM Write Enable
// address = m_bdf | 0x40;
// BYTE b40 = read_pci_regb(address);
// write_pci_regb(address, b40 | 0x01);
// PM GPIO
// BYTE b = port_inpb (0x404C);
// b &= 0xEF;
// port_outpb (0x404C, b);
}
И классическим методом успешно читаем прошивку.
Естественно, что при этом не удалось определить флешку.
Всем доброго!
зависит от производителя?
Хотелось бы внести уточнение... При работе кода BIOS платы расширения, обращаясь к адресам в районе 4ГБ мы НЕ отправляемся южным мостом во флеш? Я правильно понял? Или только за исключением некоторых участков? Или как всегда
И еще маленький вопрос... У всех BIOS инструкция начальная инструкция находится на 16 байт меньше от конца BIOS? И все BIOS отображают себя на конец адресного пространства памяти?
Если посмотреть на исходники AWARD, то можно увидеть два разных хука - Ct_ROM_Write_Enable и Ct_Enable_ROM_Decode.
Первый хук содержит снятие защиты от записи, а второй этого не делает.
Для чтения прошивки, как мне кажется, достаточно вызвать только второй - Ct_Enable_ROM_Decode.
Насколько я помню, обычно на момент инициализации BIOS плат расширения в конце 4-го гигабайта виден только boot block (64кб).
Остальной системный BIOS уже не виден, там FF. От производителя BIOS зависит, отключит ли он остальной BIOS, но boot block отключить нельзя, он всегда виден.
Первая инструкция на архитектуре IA-32 всегда выполняется по адресу 0xFFFFFFF0, это определенно. На AMD64/EM64T я не уверн, надо доку читать...
Поэтому все BIOS на IA-32 должны отображаться на конец адресного пространства, чтобы было что выполнить :)