Позже буду описывать используемые поля и давать пояснения. В случае неясностей в тексте прошу задавать вопросы - буду корректировать периодически ЭТО ПЕРВОЕ СООБЩЕНИЕ, что бы было все доступно и понятно...
В данной теме рассматриваются BIN-файлы системы AISIN, являющиеся "кирпичиками" в операционной системе, используемой на японских магнитолах, загружающих ОС с HDD и SD-карточек.
В магнитолах, загружающихся с HDD данный тип файлов, необходимы для работы, находится как правило в папке PRG на одном из логических дисков HDD.
Пример листинга файлов одного из таких каталогов:
Грубо говоря - каждый из BIN-файлов содержит программы и ресурсы, необходимые для функционирования отдельных функций магнитолы...
На магнитолах, загружаемых с HDD в каталоге PRG отсутствует один, очень важный для начальной загрузки файл - ldm.bin !
На самом деле он находится в начале жесткого диска, в скрытом разделе (Windows определяет его как RAW-раздел, т.е. не размеченный, а по большому счету - раздел с неизвестной для Windows файловой системой...)
На самом деле в RAW-области, кроме BOOT-записи и вышеупомянутого файла ldm.bin, находится своя файловая система с файлами картографии...
В конце поста я приведу пример начала жесткого диска...
В магнитолах, загружающихся с SD-карточек BIN-файлы упакованы особым образом в знакомый многим контейнер - файл LOADING.KWI, формат которого я планирую раскрыть в отдельной теме....
Ну а теперь - сам внутренний формат BIN-файлов:
Как видно из картинки, рассматриваемые файлы состоят из:
- Заголовка, размером 128 (дес.) байт, выделенного синим цветом
и- Тела модуля(блока), выделенного зеленым цветом.
Рассмотрим поля Заголовка (цифровые значения адресов (offset) указаны в шестнадцатеричной системе, длина поля - в десятичной!):=== Offset ===== Length ==========================================================================================
[0000 -- 0003] -- 4 bytes -- внутреннее имя Модуля(Блока);
[0004 -- 0005] -- 2 bytes -- 0D 0A (символы CR - Carriage Return (Перевод каретки) и LF - Line Feed (Перевод строки) );
[0006 -- 000D] -- 8 bytes -- версия Модуля (Блока);
[000E -- 000F] -- 2 bytes -- 0D 0A (CR, LF);
[0010 -- 001A] -- 11 bytes -- месяц, дата и год разработки (разделители - код 20h (пробел));
[001E -- 001F] -- 2 bytes -- 0D 0A (CR, LF);
[0020 -- 0027] -- 8 bytes -- время разработки в формате ЧЧ:ММ:СС;
[002E -- 002F] -- 2 bytes -- 0D 0A (CR, LF);
[0030 -- 003E] -- 15 bytes -- Фирма-разработчик;
[005D -- 005E] -- 2 bytes -- 0D 0A (CR, LF);
[005F -- 0063] -- 5 bytes -- НАЗНАЧЕНИЕ ПОЛЯ ПОКА НЕ ВЫЯСНЕНО;
[0070 -- 0072] -- 3 bytes -- адрес расположения тела блока в оперативной памяти (тут адрес начала поля возможно начинается с адреса 006Fh);
[0074 -- 0077] -- 4 bytes -- длина Блока (Заголовок + Тело модуля(Блока)), начиная с Нулевого оффсета (Обзовем переменной BlockLen);
[0078 -- 007B] -- 4 bytes -- Контрольная Сумма (КС) Тела модуля (Блока);
[0080 -- до адреса, указанного в поле [0074 - 0077]] -- расположено тело Модуля (Блока).
===============================================================================================================
Контрольная Сумма (КС) тела Модуля (Блока) считается от оффсета 0080h до конца тела Модуля(Блока):
Длина для подсчета КС = BlockLen - 80h
В принципе можно КС считать и до конечного адреса физического файла - ошибки не будет, ввиду того, что его концовка заполнена нулевыми значениями!
Сама Контрольная Сумма (КС) считается простым последовательным суммированием полей по два двойных слова (4 байта) между собой от начала Тела Модуля(Блока)...
(что то тут у меня не удалось правильно сформулировать принцип суммирования..((( ... Надо пересмотреть эту формулировку для понятия..)
Может лучше вот так?:
Контрольная Сумма формируется последовательным суммированием 4-х разрядных слов, с отбрасыванием разрядов, выходимых из разрядной сетки, от начала Тела Модуля(Блока)(оффсет $0080) и длиной BlockLen - 80h.(Читать как BlockLen минус 80h )(Вроде я не ошибся?)
Пока скажу коротко - определенного формата на это содержимое не существует - производитель ПО магнитол распоряжается этим пространством на свое усмотрение.
Там могут находиться различные блоки, модули и поля, такие как:
- процессорные команды;
- таблицы графических данных, используемых в интерфейсе магнитол, и сама графика(как в открытом формате, так и в упакованном виде);
- таблицы текстовых сообщений и сам текст на Японском и Английском языках;
- различные шрифты и таблицы перекодировок;
- и т.д. и т.п.
Вот для начала весь расклад...
И еще - для правильного подсчета используйте следующую простую формулу:
Адрес последнего байта ПОЛЯ = Адрес первого байта ПОЛЯ + Длина ПОЛЯ - 1
Как и обещал, привожу HEX-ASCII-дамп начала жесткого диска:Как видим - с Нулевого оффсета жесткого диска идет BOOT-загрузчик ОС, а с оффсета 0200h - спрятался Модуль (Блок) ldm.bin (внутреннее имя - .LDR).
Прямоугольниками выделены поля:
- Синим - длина Модуля (Блока), отсчитываемая в данном случает от оффсета 0200h;
- Зеленым - Контрольная сумма Тела Модуля(Блока), которая считается в данном случае от оффсета 0280h.
Таким образом, зная адрес начала и длину Модуля(Блока) ldm.bin, можно легко его от туда сохранить в отдельный файл.
Не забыв при этом дополнить в конце нулями до длины физического файла, кратного 2048dec.
Ну а дальше, имея в своем распоряжении ПОЛНЫЙ набор BIN-файлов данной версии, при желании и/или необходимости, можно собрать свой файл-контейнер LOADING.KWI для анализа содержимого программами, оперирующими с данным типом файла...
Примечание:
Ввиду того, что в разных источниках, сам BIN-файл иногда называется по разному - МОДУЛЕМ или БЛОКОМ, я был вынужден применять через скобку оба этих названия, что возможно несколько усложнило восприятие!
Если посчитаете, то достаточного ОДНОГО названия из двух - я откорректирую описание выше...