Решил вынести в отдельную тему, хотя может можно было кинуть в теоретические вопросы. Ну если что , перекинте...
Облазил форум, многие темы посвящены конкретной плате, а у меня вопрос следующий.
Очень хочется просто прочитать BIOS. Не перезаписать, а просто прочитать. Да, уточнение, чтение на этапе загрузки, то есть осуществляется из кода BIOS платы расширения. Прочитав умные книги
, выяснил, что как минимум у AWARD и AMI BIOS отображается на область памяти (FFFFFFFFh - объем чипа BIOS). То есть возникает резонное предположение о возможности просканировать эту область памяти и соответственно быть отправленным южным мостом в чип BIOS (хотя может он уже в этот момент туда и не отправляет). Однако где-то в этой области возникают непонятки, в смысле, то ли что-то там отображается из внутренних регистров чипа, то ли код распакованного BIOS меняется после каждой загрузки, но в этой области памяти некоторые участки изменяются при перезагрузке, хотя остальные совпадают с образом, скачанным с сайта производителя. Кстати, как отображается память BIOS у других производителей, в том числе IBM? Кто дизассемблировал, подскажите!
В общем, вопрос следующий. Как можно просто прочитать BIOS на этапе работы самого BIOS ( то есть при выполнении BIOS платы расширения), можно ли разрешить чтение напрямую из флеш-биос путем программирования его регистров, можно ли как-то универсализировать эту процедуру, хотя бы в рамках одного производителя (используются может одни и те же регистры для разрешения чтения)??? Или это вообще гиблое дело???
Пожалуйста, высказывайте мнения, Все интересно!!!
apple_rom
> Именно это - прошивка посредством упомянутых "хуков" и было сделано в runiflash - в противопоставление используемому по умолчанию "классическому" способу.
Мне чертовски хочется в своем плагине-читалке обойтись без использования этих хуков. Да и хуки эти под виндами просто так вызвать не получится Есть желание содержательную часть этих хуков представить в виде спец. скрипта, в котором по-честному будут перечислены атомарные действия по записи требуемых байт в нужные регистры. Это будет расширяемый набор скриптов, причем нужный скрипт будет автоматически (по желанию - вручную) выбираться на основе идентификационных данных о железе (чипсет, SIO).
У меня вопрос - на Ваш взгляд, потребуется ли для выбора (и возможного редактирования) нужного скрипта учитывать еще и название матплаты?
Могут ли существовать в природе две матплаты с одинаковыми чипсетами+SIO, но с принципиально разными наборами операций для доступа к ПЗУ?
apple_rom
> В таких случаях я не мешаю течению предсказуемого путешествия по граблям...
>Именно эта особенность современного BIOS-прошивания и является причиной вышеизложенных комментариев о неперспективности "классического" способа
Для тестирования плагина такие грабли как раз и разыскиваются. Но пока безуспешно.
Да, для защиты от записи биоса разработчик матплаты может, например, повесить требование изменения хитрого битика в произвольном плато-специфичном GPIO-порту.
Но в этой ветке форума обсуждается не перепрошивка биоса, а всего лишь чтение прошивки.
Для чтения прошивки разрешение на запись требуется только для того, чтобы "записать" в ПЗУ команды для определения Vendor_ID+Device_ID этого ПЗУ. А затем узнать размер этого ПЗУ - 128/256/384/512/1024 кбайт. И всё. Больше нам это разрешение на запись не потребуется. Но эта информация не критична - по "внешнему виду" прочитанного (с запасом) файла прошивки можно догадаться о размере ПЗУ. Или отодрать наклейку на флешке
Теперь осталось настроить чипсет для доступа на чтение конца 4-го гигабайта. Здесь злобные разработчики матплаты/биоса бессильны, ибо алгоритм настройки определяется только чипсетом.
Итак, как мне кажется, для чтения прошивки классический (нехуковый) подход вполне жизнеспособен.
PS
О граблях. Было бы интересно ознакомиться с матплатой, биос которой успешно считывается программой runiflash, но классический подход для чтения прошивки не будет работать.
Или даже проще глянуть внутренности того же unfilash, где стоят условия на совпадения с "исключительными случаями". Вот, в частности, кусок кода:
Как говорится - без комментариев...
apple_rom
> Можно начать и закончить практически любым Абитом.
У меня как раз есть одна плата 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.
lsvmo:
Насколько я помню, обычно на момент инициализации BIOS плат расширения в конце 4-го гигабайта виден только boot block (64кб).
Остальной системный BIOS уже не виден, там FF. От производителя BIOS зависит, отключит ли он остальной BIOS, но boot block отключить нельзя, он всегда виден.
Первая инструкция на архитектуре IA-32 всегда выполняется по адресу 0xFFFFFFF0, это определенно. На AMD64/EM64T я не уверн, надо доку читать...
Поэтому все BIOS на IA-32 должны отображаться на конец адресного пространства, чтобы было что выполнить
Отправить комментарий