Сейчас исполняется код из флешки и есть мысль что тут что-то не так, как надо. Очередная идея - автор BIOS рассчитывал на те инструкции, которые попали в кэш (в самом QEMU кэш как сущность не очень заметен).
Что-то подобное может-быть возможно было бы сделать используя SMM, на это уже атака
(грязный прием, противоречащий Intel рекомендациям по написанию BIOS), не думаю что в
нормальном коде BIOS будет что-то подобное. co-c.net/repository-securite-informatique/Papers/smm_cache_fun.pdf
Вы писали что по 0xe8000 ncpucode.bin(запакованный) и соответственно переход заведомо
неверный, анализировать получившиеся "команды" нет смысла.
Вы проанализировали значения PAM регистров, точно соответствует режиму чтения flash?
Если да, то может быть ошибка возникла где-то ранее, что привело к ошибочномуи вызову
процедуры программирования PAM или на упомянутую последовательнось команд,
делающую переход на 0xe8000.
Есть вариант добавить в BIOS отладочный код и исследовать на реальной системе.
Заменяем команду в интересующем месте на near jmp на неиспользуемое место,
(в том же сегменте), где размещаем отладочный код:
ту команду(ы) которые(ми) пришлось заменить вышеупомянутым jmp(то есть
восстанавливаем команды BIOS запорченные jmp) + код выводящий в port 0x80.
Не забываем сохранить и восстановить все регистры использованные кодом вывода
значений в диагностический port!
По окончании отладочного кода jmp обратно. Относительные смещения внутрисегментных
переходов придется рассчитывать. Очень удобно использовать IDA для этого, и легко
убедится, что все адреса переходов рассчитаны верно.
Какую часть кода обходить и продублировать в отладочном коде и что выводить -
зависит от фантазии и конкретной ситуации. Хорошо если POST card имеет дополнительный
индикатор, например для port 0x81, туда можно выводить например дополнительные
значения(Вы отмечали что участок кода с переходм на 0xe8000 исполняется неоднократно).
Можно добавить код чтения PCI PAM reg, по аналогии с основной процедурой, имеющейся
в BIOS и выводить значения в port 0x81).
Можно сделать задержку в отладочном коде, чтобы успеть заметить показания.
Очень полезно иметь POST card, запоминающую историю POST, с целью дальнейшего
анализа. Или можно попробовать снять video и потом в замедленном режиме просматривать.
Можно вообще сделать останов в нужном месте, но после этого придется восстанавливать
BIOS(на Gigabyte Dual-BIOS особо надеяться не стоит).
Я делал подобное при исследовании BIOS платы P3B-F. С современными Award возможны
трудности с внесением изменнений. Здесь немогу подсказать, тк не интересуюсь
современными платформами вообще. Конечно этот способ трудоемок и легко можно
запортить BIOS, но я все же решил написать об этом.
Что-то подобное может-быть возможно было бы сделать используя SMM, на это уже атака
(грязный прием, противоречащий Intel рекомендациям по написанию BIOS), не думаю что в
нормальном коде BIOS будет что-то подобное.
co-c.net/repository-securite-informatique/Papers/smm_cache_fun.pdf
Вы писали что по 0xe8000 ncpucode.bin(запакованный) и соответственно переход заведомо
неверный, анализировать получившиеся "команды" нет смысла.
Вы проанализировали значения PAM регистров, точно соответствует режиму чтения flash?
Если да, то может быть ошибка возникла где-то ранее, что привело к ошибочномуи вызову
процедуры программирования PAM или на упомянутую последовательнось команд,
делающую переход на 0xe8000.
Есть вариант добавить в BIOS отладочный код и исследовать на реальной системе.
Заменяем команду в интересующем месте на near jmp на неиспользуемое место,
(в том же сегменте), где размещаем отладочный код:
ту команду(ы) которые(ми) пришлось заменить вышеупомянутым jmp(то есть
восстанавливаем команды BIOS запорченные jmp) + код выводящий в port 0x80.
Не забываем сохранить и восстановить все регистры использованные кодом вывода
значений в диагностический port!
По окончании отладочного кода jmp обратно. Относительные смещения внутрисегментных
переходов придется рассчитывать. Очень удобно использовать IDA для этого, и легко
убедится, что все адреса переходов рассчитаны верно.
Какую часть кода обходить и продублировать в отладочном коде и что выводить -
зависит от фантазии и конкретной ситуации. Хорошо если POST card имеет дополнительный
индикатор, например для port 0x81, туда можно выводить например дополнительные
значения(Вы отмечали что участок кода с переходм на 0xe8000 исполняется неоднократно).
Можно добавить код чтения PCI PAM reg, по аналогии с основной процедурой, имеющейся
в BIOS и выводить значения в port 0x81).
Можно сделать задержку в отладочном коде, чтобы успеть заметить показания.
Очень полезно иметь POST card, запоминающую историю POST, с целью дальнейшего
анализа. Или можно попробовать снять video и потом в замедленном режиме просматривать.
Можно вообще сделать останов в нужном месте, но после этого придется восстанавливать
BIOS(на Gigabyte Dual-BIOS особо надеяться не стоит).
Я делал подобное при исследовании BIOS платы P3B-F. С современными Award возможны
трудности с внесением изменнений. Здесь немогу подсказать, тк не интересуюсь
современными платформами вообще. Конечно этот способ трудоемок и легко можно
запортить BIOS, но я все же решил написать об этом.