Изменение инженерного пароля

1. метод подсчета CRC вовсе не является загадкой
2. помнится в эпоху DOS я писал такого резидента - CMOSGuard назывался - работал в паре с KillKbd

Тогда, пожалуйста, расскажи алгоритм или дай линк на место, где это можно посмотреть.

1. Заархивировать его. Есть 2 способа:

б) CBROM'ом :

CBrom /PCI

(вместо /PCI может быть что угодно: /ACPI, /OEM0 ...)
любой файл, который не жалко (хоть нулевой длины)
в результате CBROM ругается и подвиснет
(это нормальная реакция на файл )
жмем Ctrl+Break
получаем нужный нам файл файл BIOS.ROM в текущей директории

cbrom завис вхлам ctrl+break не помогло - снял задачу ))

а) #0Fh=00h #10h=00h
(если архив создавался с помощью LHA, то по этим байтам обычно расположено
ВРЕМЯ последней модификации файла)

б) #11h=00h #12h=50h - идентификаторы основного образа;

(если архив создавался с помощью LHA, то по этим байтам обычно расположена
ДАТА последней модификации файла)

в) и желательно ExtendedArea1,2,3 (=20h{OSID},00h,00h)
(если архив создавался с помощью LHA, то там обычно (=4Dh{MS-DOS},00h,00h))

а где оно располагается?

3. Пересчитать и подправить ChkSum (байт #01h)

сделал

lha t BIOS.ROM <-- если выдаст ошибку, то проблемы с CRC или ChkSum
lha -t BIOS.ROM <-- если выдаст ошибку, то проблемы с ChkSum

> lha t BIOS.ROM

Testing archive : BIOS.ROM

No file found

> lha -t BIOS.ROM

Name ... .. . . . . . . . . .... .... ...
---------------------------------------------
no file

дальше продолжать не стал...

смотрим утекшие исходники биос - там есть все
есть некоторые проблемы со старыми биосами, но их можно решить дизассемблировав cbrom

Bizquit

а если вторым способом (через LHA) ?
у меня оба способа прекрасно работали

Программка как раз отображает карту расположения (структуру) полей заголовка: адреса полей в первой колонке, длина -- во второй, название полей в третей.
Заголовок распологается с самого начала файла. Нумерация байтов, как в HEX-редакторе (с нулевого).

Любые вносимые изменения лучше контролировать с помощью упомянутой программки.

Упс, мой косяк... пропустил РPS... думал, что прога сама правит ChkSum, после его правки ЛХА стал разпознавать bios.rom

Записать bios.rom в прошивку, я думаю, проблем не составит.
Остается узнать способ подсчета "злополучного байта".

Да, и еще смущает разница в 1 байт оригинального и перепакованого 6omm7e.bin (см. выше по треду). может этот байт и есть тот самый ЦРЦ, который идет следом за главным модулем прошивки?

PS:
а Биос_Патчер не правит контрольную сумму?

Bizquit

Полночи потратил на разработку этого вопроса.
Картина понемногу проясняется.
Сорцы биоса вчера тоже глядел, но ни черта не понял (туго у меня с ассемблером), кроме того, что используется CRC16 с довольно оригинальным образующим полиномом.

Не понятно пока, как они 16-битный CRC запихивают в 8 бит
Берут на выбор один из двух байтов ?

Надо еще выяснить, имеет ли вообще этот загадочный байт хоть какое-то отношение к CRC.

В общем вопросов тьма, сегодня продолжу разборки

ИМХО, в этом нет ничего удивительного

Вряд ли.
Этот CRC нужен биосу, а не архиватору.
Поэтому архиватор даже не подозревает о существовании этого CRC ?

Кстати, если бы не этот проклятый CRC, то состав модулей в образе биоса можно было бы просматривать с помощью архиватора

ЗЫ: Что-то с форумом на клокерсах стряслось.Уже целый час в дауне...

Стормозил. Сорри :oops:
Сырцы то ведь есть!

Так, народ - об чём гутарим, собственно??? Об любимых авардовских цээрцэшках? Тогда спросите у меня - я знаю больше всех про это и, вообще, их у меня больше чем в самом аварде...
А если серьёзно, то подавляющее большинство пытающихся "разгадать" (или утверждющих, что уже сделали это) алгоритм их (различных CRC в Award BIOS) подсчета не учитывают следующие _принципиальные_ вещи:
- способ подсчета изменется у разных производителей (самый яркий пример - Asus)
- способ подсчета разный у разных версий
- и _самое_главное_ он изменялся (в т.ч. изменяется/будет_изменяться) СО_ВРЕМЕНЕМ. Т.е. в одной и той же версии способо подсчета мог изменяться.
Поэтому, например, лично я очень давно похоронил попытки написать патчер, считающий чексуммы (первые версии патчеры так и делали) - я пересчитывал кучу чексум, в т.ч. давно уже не используемых самим авардом - это грубо давало 90-95% точность работы. После плюнул и стал пользоваться cbrom - получил 99-99.9% точность. Итого, как говорится - "А смысл???"
Если же кого-то интересует "отдельные" моменты подсчета чексум - спрашивайте, но только сначала подумайте и скажите "зачем" вам это надо и нельзя ли это сделать имеющимся таким банальным и сверхнадежным "cbrom 2.07/2.08"...

Дык... Заглядывал бы почаще - может, и спрашивали бы... А то сидим тут, как сиротинушки...