Никак не могу победить сабж.
Мать: GigaByte GA6OMM7E
Версия БИОС: Award Modular BIOS v6.00PG
Что делаю:
1. Сливаю прошивальщиком биос в файл.
2. В модбине изменяю Security Default Password на свой.
3. Прогоняю БиосПатчер-ом
4. Зашиваю FLASH840.EXE - шником
Результат:
AWARD_SW идет на ура....
Думал, что модбин не сохраняет результат. Изменил BIOS Message - сохранилось... А пароль не сохраняется...
Пробовал модбины:
modbin6.1.00.37, modbin6.1.00.37 - оба при попытке сохранить вываливаются с ошибкой.
modbin6.2.00.00beta - сохраняет, но рез-ат см. выше...
2. помнится в эпоху DOS я писал такого резидента - CMOSGuard назывался - работал в паре с KillKbd :lol:
Тогда, пожалуйста, расскажи алгоритм или дай линк на место, где это можно посмотреть.
cbrom завис вхлам ctrl+break не помогло - снял задачу ))
а где оно располагается?
сделал
> lha t BIOS.ROM
Testing archive : BIOS.ROM
No file found
> lha -t BIOS.ROM
Name ... .. . . . . . . . . .... .... ...
---------------------------------------------
no file
:!:
дальше продолжать не стал...
смотрим утекшие исходники биос - там есть все :wink:
есть некоторые проблемы со старыми биосами, но их можно решить дизассемблировав cbrom
а если вторым способом (через LHA) ?
у меня оба способа прекрасно работали
Программка как раз отображает карту расположения (структуру) полей заголовка: адреса полей в первой колонке, длина -- во второй, название полей в третей.
Заголовок распологается с самого начала файла. Нумерация байтов, как в HEX-редакторе (с нулевого).
Любые вносимые изменения лучше контролировать с помощью упомянутой программки.
Записать bios.rom в прошивку, я думаю, проблем не составит.
Остается узнать способ подсчета "злополучного байта".
Да, и еще смущает разница в 1 байт оригинального и перепакованого 6omm7e.bin (см. выше по треду). может этот байт и есть тот самый ЦРЦ, который идет следом за главным модулем прошивки?
PS:
а Биос_Патчер не правит контрольную сумму?
Полночи потратил на разработку этого вопроса.
Картина понемногу проясняется.
Сорцы биоса вчера тоже глядел, но ни черта не понял (туго у меня с ассемблером), кроме того, что используется CRC16 с довольно оригинальным образующим полиномом.
Не понятно пока, как они 16-битный CRC запихивают в 8 бит
Берут на выбор один из двух байтов ?
Надо еще выяснить, имеет ли вообще этот загадочный байт хоть какое-то отношение к CRC.
В общем вопросов тьма, сегодня продолжу разборки :)
ИМХО, в этом нет ничего удивительного
Вряд ли.
Этот CRC нужен биосу, а не архиватору.
Поэтому архиватор даже не подозревает о существовании этого CRC ? :-)
Кстати, если бы не этот проклятый CRC, то состав модулей в образе биоса можно было бы просматривать с помощью архиватора :-)
ЗЫ: Что-то с форумом на клокерсах стряслось.Уже целый час в дауне...
Стормозил. Сорри :oops:
Сырцы то ведь есть! :)
А если серьёзно, то подавляющее большинство пытающихся "разгадать" (или утверждющих, что уже сделали это) алгоритм их (различных CRC в Award BIOS) подсчета не учитывают следующие _принципиальные_ вещи:
- способ подсчета изменется у разных производителей (самый яркий пример - Asus)
- способ подсчета разный у разных версий
- и _самое_главное_ он изменялся (в т.ч. изменяется/будет_изменяться) СО_ВРЕМЕНЕМ. Т.е. в одной и той же версии способо подсчета мог изменяться.
Поэтому, например, лично я очень давно похоронил попытки написать патчер, считающий чексуммы (первые версии патчеры так и делали) - я пересчитывал кучу чексум, в т.ч. давно уже не используемых самим авардом - это грубо давало 90-95% точность работы. После плюнул и стал пользоваться cbrom - получил 99-99.9% точность. Итого, как говорится - "А смысл???" :)
Если же кого-то интересует "отдельные" моменты подсчета чексум - спрашивайте, но только сначала подумайте и скажите "зачем" вам это надо и нельзя ли это сделать имеющимся таким банальным и сверхнадежным "cbrom 2.07/2.08"... :)
Дык... Заглядывал бы почаще - может, и спрашивали бы... А то сидим тут, как сиротинушки... :wink: