Проводим анализ закрытой штатной системы Carin 520 на базе BMW MK1-MK3 VDO, также используемой на рульных телегах от Peugeot, Renault, Land Rover. Заинтересованным добро пожаловать! Раскуриваем сабжи с картами Москвы и СПБ http://www.bmwnav.narod.ru а также картой Сингапура http://www.freefile.ru/files/4649 .

| Сообщение посчитали полезным:

Неа, это ж тебе интересно реверсить GPS, а не мне Я по техническим вопросам отвечаю

-----
Реверсивная инженерия - написание кода идентичного натуральному

| Сообщение посчитали полезным:

Ды не могу понять, с какого модуля начинается загрузка и отслеживание типа оборудования с последующим направлением по папкам...

| Сообщение посчитали полезным:

Всем привет! Вернулся из Немчии, нарыл кабель для программирования БК, копаюсь до сих пор в коде Hеxxx, есть новые статейки?

| Сообщение посчитали полезным:

Неа. Ща не занимался почти.

-----
Реверсивная инженерия - написание кода идентичного натуральному

| Сообщение посчитали полезным:

Всем привет! Тема продолжается. Приношу извинения за детство и излишнюю эмоциональность, допущенную мною в предыдущих сообщениях На данный момент наши продвижения:

1. Расследование проца и системы притормаживаем.
2. Берем приоритетное направление - анализ самого файла VDO CarinDB.
3. CarinDB - перекомпилированный вариант SHP - формата.

CarinDB состоит из блоков по 2048 байт (2К).
Базовое смещение в файле - 800.
Блок состоит из Header и дополнительных записей с полезными данными. Header состоит из 12 байт.

3 байта - ID блока
1 байт - количество зон 2К в этом блоке
4 байта - тип блока (нечто вроде описания структуры, архитектуры и принципа записей)
2 байта - смещение начала полезных данных относительно начала блока
2 байта - количество записей этих данных

За базу берем всем известную карту Москвы с BMWNav.

Читаем:
ROM:00000000 00 00 00 01 00 12 00 00 00 24 00 01 00 00 03 01
- блок с ID 00 00 00
- количество зон 2К - одна (следующий блок по смещению ROM:00000800)
- тип блока 00 12 00 00 (далее мы будем их рассматривать)
- данные начинаются с ROM:00000024
- количество полезных записей для данных - одна

Идем далее...
ROM:00000800 00 00 01 01 00 13 00 00 00 10 00 01 00 1C 00 01
- блок с ID 00 00 01
- количество зон 2К - одна (следующий блок по смещению ROM:00001000)
- тип блока 00 13 00 00
- данные начинаются с ROM:00000810
- количество полезных записей для данных - одна

Далее...
ROM:00001000 00 00 02 01 00 07 00 00 00 CC 00 00 00 00 8E 01
- блок с ID 00 00 02
- количество зон 2К - одна (следующий блок по смещению ROM:00001800)
- тип блока 00 07 00 00
- данные начинаются с ROM:000010СС
- количество полезных записей для данных - ноль

Далее...
ROM:00001800 00 00 03 01 00 0B 00 00 00 0C 00 01 00 00 04 01
- блок с ID 00 00 03
- количество зон 2К - одна (следующий блок по смещению ROM:00002000)
- тип блока 00 0В 00 00
- данные начинаются с ROM:0000180С
- количество полезных записей для данных - одна

| Сообщение посчитали полезным:

На данный момент я готовлюсь выложить свое мнение по поводу полезных записей, как бы это доступнее объяснить.
Маленькая подзадача - создать приложение С/С++, читающее эти самые заголовки блоков и выдающее в список тип блоков. У кого какие идеи?

| Сообщение посчитали полезным:

Kot_358 пишет:
1. Расследование проца и системы притормаживаем.
2. Берем приоритетное направление - анализ самого файла VDO CarinDB.
3. CarinDB - перекомпилированный вариант SHP - формата.
И сразу становитса неинтересно, да и не по теме

| Сообщение посчитали полезным:

Kot_358 пишет:
Маленькая подзадача - создать приложение С/С++, читающее эти самые заголовки блоков и выдающее в список тип блоков.
в аттаче



ecef_17.07.2008_CRACKLAB.rU.tgz - unpack_carin.rar

| Сообщение посчитали полезным:

dJabber, очень буду признателен, а нельзя ли залить в другое место, ссылка битая RAR-ом не открывается

| Сообщение посчитали полезным:

На данный момент я выявил закономерность, что все карты Carin по-любому начинаются с трех блоков типа 00 12 00 00, 00 13 00 00, 00 07 00 00. Все они по 1 Кб. Далее идут страны. Что это за типы блоков - ХЗ, общей логике моих мыслей они не поддаются... можбыть, это какое-то описание структуры блоков данных в файле?

| Сообщение посчитали полезным:

Kot_358 пишет:
Jabber, очень буду признателен, а нельзя ли залить в другое место, ссылка битая RAR-ом не открывается

unpack http://rapidshare.com/files/130544870/unpack_carin.exe.html

| Сообщение посчитали полезным:

мои соображения по поводу блока {00 13 00 00} - imho ето описательный блок. находится в карте в единственном екземпляре. состоит из двух структур - структуры заголовка описания и структуры пояснительного текста

в заголовке находится что-то типа версии формата карты, метки (label) и описания карты (description)
в другой структуре находится 16-байтный код (GUID?) который одинаков во всех доступных мне картах, некоего двухбайтного кода (везде 0x0001), опять версии формата и пояснительного текста

word 0x0008: 00 10 - ссылка на структуру заголовка
word 0x000A: 00 01 - количество структур заголовков
word 0x000C: 00 1C - ссылка на структуру с текстом пояснения
word 0x001E: 00 01 - количество структур с текстом пояснения

структура заголовка

word 0x0010: 00 01 - версия hi
word 0x0012: 00 21 - версия lo (в картах с bmwnav - значение 00 10, в другой базе, 2004 года - 1D)
word 0x0014: 00 38 - ссылка на текст метки
word 0x0016: 00 09 - длина текста метки
word 0x0018: 00 41 - ссылка на текст описания
word 0x001A: 00 0F - длина текста описания

структура с пояснительным текстом

16byte 0x001C: 06 9F 6B C7-0D 3E D7 8E-13 DE 43 55-1A 7D AF 1C - 16-байтовый код (GUID?)
word 0x002C: 00 01 - код
word 0x002E: 00 01 версия hi
word 0x0030: 00 21 - версия lo (в картах с bmwnav - значение 00 10, в другой базе, 2004 года - 1D)
word 0x0032: 00 50 - смещение текстового пояснения
word 0x0034: 02 29 - длина текстового пояснения

все смещения - в байтах относительно начала блока



dea7_17.07.2008_CRACKLAB.rU.tgz - carindb_0000001.bin

| Сообщение посчитали полезным:

Спасибо большое, DJabber! carindb_0000001.bin я затрудняюсь открыть, не знаю, в чем дело Залей, пожалуйста, поудобнее, плиз, на рапиду, что ли. Да и unpack вываливает ошибку на смещении Offset: 00001292, глянь, пожалуйста, что там за строки гонят, если его писал ты сам... По умолчанию я копаю халявную карту Москвы с BMWNav. По структуре записей я раскопал следующее:

ROM:00004000 00 00 08 08 00 0E 00 00 00 24 00 62 03 34 00 62 ......$.b4.b
ROM:00004010 04 BC 01 EC 00 00 00 00 00 00 00 00 00 00 10 08 -
ü..........
ROM:00004020 00 00 00 00 32 DC 00 02 00 00 03 34 32 E9 00 02 ....2-...42ù.
ROM:00004030 00 00 03 38 32 FD 00 02 00 00 03 3C 33 10 00 02 ..82¤...<3.
ROM:00004040 00 00 03 40 33 21 00 02 00 00 03 44 33 2F 00 02 ..@3!...D3/.
ROM:00004050 00 00 03 48 33 48 00 02 00 00 03 4C 33 5F 00 02 ..H3H...L3_.

ROM:000072D0 7F FF 7F FF 00 01 AF 02 03 C0 00 01 22 70 72 61   .
ïL.
"pra
ROM:000072E0 76 64 79 22 20 75 6C 2E 00 61 62 65 6C 27 6D 61 vdy" ul..abel'ma
ROM:000072F0 6E 6F 76 73 6B 61 79 61 20 75 6C 2E 00 61 62 72 novskaya ul..abr
ROM:00007300 69 6B 6F 73 6F 76 73 6B 69 79 20 70 65 72 2E 00 ikosovskiy per..
ROM:00007310 61 65 72 6F 64 72 6F 6D 6E 61 79 61 20 75 6C 2E aerodromnaya ul.
ROM:00007320 00 61 65 72 6F 70 6F 72 74 61 20 70 72 2E 00 61 .aeroporta pr..a
ROM:00007330 65 72 6F 70 6F 72 74 6F 76 73 6B 61 79 61 20 31 eroportovskaya 1
ROM:00007340 2D 79 61 20 75 6C 2E 00 61 66 61 6E 61 73 27 79 -ya ul..afanas'y

Важное замечание: Записи про которые пойдет ниже речь, начинаемые в примере со смещения 24 ВСЕ по 8 байт. Это зарубаем на носу себе.

Тут взяли к примеру блок ROM:00004000, тип 00 0Е 00 00, не знаю еще что это за тип, записи начинаются с ROM:00004024, количество - 62.

Идем к первой записи: 32 DC 00 02 00 00 03 34.
Идем к ROM:00004024 - читаем два байта: 32 DC - это смещение на наименовнание. ROM:00004000 + 32DC равняется ROM:000072DС. На этом смещении я могу прочитать "pravdy" ul.

Дальше идем к след. записи: 32 E9 00 02 00 00 03 38
Идем к ROM:0000402С - читаем два байта: 32 Е9 - это смещение на наименовнание. ROM:00004000 + 32Е9 равняется ROM:000072Е9. На этом смещении я могу прочитать abel'manovskaya ul.

Дальше идем к след. записи: 32 FD 00 02 00 00 03 3C
Идем к ROM:00004034 - читаем два байта: 32 FD - это смещение на наименовнание. ROM:00004000 + 32FD равняется ROM:000072FD. На этом смещении я могу прочитать abrikosovskiy per.

Дальше идем к след. записи: 33 10 00 02 00 00 03 40
Идем к ROM:0000403C - читаем два байта: 33 10 - это смещение на наименовнание. ROM:00004000 + 3310 равняется ROM:00007310. На этом смещении я могу прочитать aerodromnaya ul.
И так катаемся до тех пор, пока не прошмонаем все 62 записи. Далее, я подозреваю, блок закончится. Синтаксис я не меняю, чтобы было видно, что скобки как на "pravdy" ul сохраняются. У меня возник резонный вопрос: смещение первых двух байт в записи указывает только на наименование, но не я не нашел указателя на размер. Как навигатор понимает, что наименование закончилось? И тут же попробую ответить себе: все записи разделяются стабильно двумя точками, но не простыми, ака HEX 00. В сокращении тоже стоят точки, но они имеют символ "2Е". Не на точки ли "00" он ориентируется? ПОзже распишу структуру 8 байт записи. Какие мнения у народа рождаются? К сожалению, я не могу более наглядно выделять записи цветом, но, думаю, выражаюсь понятно... Hexxx, ты следишь за топиком или тебе уже неинтересно? DJabber, рад твоему появлению, ты очень вовремя А что это еще за новые для меня версии карт "HI" и "LO"?

| Сообщение посчитали полезным:

начну с конца
Kot_358 пишет:
А что это еще за новые для меня версии карт "HI" и "LO"? Пардон, предыдущий твой топик нихрена не понял...

hi и lo - ето старший и младший номер версии, например 1.21 или 1.10, или 1.19.
просто у тех карт, которые у меня есть форматы некоторых типов блоков отличаются например в блоках с типом 0x10. поэтому я начал сравнивать блоки с типом 0x13, которые считаю некоторым образом заголовочными, и увидел различия вот в этих цифрах и для себя решил, что ето версия формата карты.


Kot_358 пишет:
carindb_0000001.bin я затрудняюсь открыть, не знаю, в чем дело

теперь про carindb_0000001.bin - ето сам блок с типом 0x13, выдранный из carindb, ты его можешь получить и сам, выдрав 2K байт по смещению 0x800 из любой карты, например с помощью hiew


Kot_358 пишет:
Да и unpack вываливает ошибку на смещении Offset: 00001292, глянь, пожалуйста, что там за строки гонят, если его писал ты сам...
перезалил тут http://rapidshare.com/files/131309626/unpack_carin.rar.html вместе с carindb_0000001.bin

Kot_358 пишет:
У меня возник резонный вопрос: смещение первых двух байт в записи указывает только на наименование, но не я не нашел указателя на размер. и т.д.

все названия - ето ASCIIZ строки. начала строк- в найденном тобой массиве из 62 структур, а конец строки определяется по символу 0х00

| Сообщение посчитали полезным:

dJabber пишет:
hi и lo - ето старший и младший номер версии, например 1.21 или 1.10, или 1.19. - смышлен, смышлен, ничего не скажешь Не подумай, что прошу научить, скажи только на каком этапе исследования CarinDB ты находишься? Анализ? Штурм структуры? Ребилд? Рабочий релиз?
Спасибо за разъяснение про точку 00.
dJabber пишет:
carindb_0000001.bin - ето сам блок с типом 0x13 - если так-тогда ладно, я справлюсь, это не трудно. Примечание: мы тут все пользуем ИДУ Про. Хотелось бы услышать мнение про байты, которые находятся между заголовком блока и полезными записями... Попробую докопаться до них... В любом случае, ты можешь быть ценным помощником

| Сообщение посчитали полезным:

Kot_358 пишет:
на каком этапе исследования CarinDB ты находишься?
на этапе неспешного ковыряния структуры... хотелось бы, конечно, сделать возможным ребилд

Kot_358 пишет:
Хотелось бы услышать мнение про байты, которые находятся между заголовком блока и полезными записями...
про ето есть только догадки у меня на руках только файлы carindb... еслиб еще была какаянибудь софтина, которая работает с етим файлом - открывает его, читает, отображает информацию было бы проще - а так - только догадки...

| Сообщение посчитали полезным:

Дык, наш профессионализм и заключается в том, чтобы создать вспомогательное ПО на С, имея только CarinDB. Я усиленно штурмую Visual C/C++, хотя бы слепить анализер записей NFR - уже будет большой прогресс... К вечеру я хочу опубликовать выводы по типам блоков. Все больше прихожу к выводу, что в блоках "00 12 00 00" и "00 07 00 00" содержится некое описание типов блоков, имеющихся в файле. Достать бы еще список доступных типов блоков...

| Сообщение посчитали полезным:

Информация в carindb хранится блоками. каждый блок занимает 1 или более секторов. Размер сектора зависит от версии carindb (2048 или 512 байт). Каждый блок имеет следующий формат:
descriptor
data_section_0
data_section_1
....
data_section_N
text_strings
Дескриптор блока состоит из:
заголовка, таблицы секций, данных заголовка.
Заголовок:
4 байта - ID блока
В ID хранится - номер сектора, с которого начинается блок, размер блока в секторах, номер файла базы (для DVD) формат хранения зависит от версии базы и типа системы.
2 байта - тип блока
1 байт - способ упаковки данных (0, 1, 2, 3, FF, FE)
1 байт - размер блока (в секторах) после распаковки.

| Сообщение посчитали полезным:

Krueger пишет:
2 байта - тип блока
1 байт - способ упаковки данных (0, 1, 2, 3, FF, FE)
1 байт - размер блока (в секторах) после распаковки.

блин, так и думал, что блоки типа
{00 0E 01 08}
{00 0E 01 07}
чем-то запакованы

| Сообщение посчитали полезным:

2 Krueger: Хе-хе, а можно подробнее ?

Krueger пишет:
descriptor
data_section_0
data_section_1
....
data_section_N
text_strings - есть ли какая-то логически определенная структура или она определяется блоками 13 и 7?

Krueger пишет:
В ID хранится - номер сектора, с которого начинается блок, размер блока в секторах, номер файла базы (для DVD) формат хранения зависит от версии базы и типа системы. - а как же мое наблюдение, что ID - это номер блока и количество зон 2К? Или это еще дальше? Чето я не понл...

2dJabber: dJabber пишет:
блин, так и думал, что блоки типа
{00 0E 01 08}
{00 0E 01 07}
чем-то запакованы - откуда такие выводы?

| Сообщение посчитали полезным:

Krueger и dJabber, я надеюсь на ваше общество

| Сообщение посчитали полезным:

Kot_358 пишет:
чем-то запакованы - откуда такие выводы?

в блоках типа

{00 XX 00 00} - четко просматривается структура, а в блоках типа {00 XX TT SS} - полная каша

Kot_358 пишет:
а как же мое наблюдение, что ID - это номер блока и количество зон 2К?
ето то же самое, но другими словами


обнаружил еще одну интересную особенность по поводу блоков 0x0E - они образуют связный список, т.е.
по смещению 0x28 (для карт "версии"1.10 с bmwnav - по смещению 0x1C) лежит ID следующего за данным блоком блока типа 0х0Е, а по смещению 0x2C (0x20 для v 1.10) лежит ID предыдущего блока 0х0Е

| Сообщение посчитали полезным:

dJabber пишет:
лежит ID следующего за данным блоком блока типа 0х0Е, а по смещению 0x2C (0x20 для v 1.10) лежит ID предыдущего блока 0х0Е - ых, обогнал меня, я тоже заметил, но придавать значения не стал, все собираюсь опубликовать выводы...

dJabber пишет:
в блоках типа {00 XX TT SS} - полная каша - какие соображения по дешифровке, каким желудком это могло быть переварено? Можбыть это не каша, а неисследованная структура (непознанное, блин )? А зональность 2К в них соблюдаешь? Не хочу огорчить тебя - в unpack, который ты дал есть баг, она все равно не доходит до конца - вываливает ошибку, но когда я ее успеваю остановить до ошибки - на смещении 2000 или 3800 она неправильно выдает размер блока, показывает 1 зону, а там их 8 Мож чё не так делал? Я в ярлычке к ней написал: "C:\Moskow Map\Recorded map\unpack_carin.exe" /carindb

| Сообщение посчитали полезным:

Пока что выводы относительно

descriptor
data_section_0
data_section_1
....
data_section_N
text_strings

я не публикую, слишком много различного в размере data_section относительно типа блока. В одном блоке эти записи весят 12 байт, в другом 8, с третьем 16, не могу логически связать...
Одно я знаю точно - 0х11 и 0х10 - это наши дорогие POI, за которые все впрягаются, нам они пока не светят, в демке их нет. А жаль... Никто не поделится русской картой с ПОЯми?

| Сообщение посчитали полезным:

Количество секций в блоке, их назначение, формат и размер записи в секции зависят от типа блока и версии базы. Версия базы (release) хранится в блоке с типом 0x0012 (первый блок в базе) по смещению 0x1A, а также в файле bibliography в строке DB-REL. Минимально поддерживаемая версия - 0x0E (1995 год). У современных карт версия 0x22. Кол-во секций, их формат и размер записей в секции меняются в зависимости от версии базы. Начиная с версии 0x12 информация о размере записей хранится в массиве блоке 0x0012. Ссылка на таблицу и кол-во записей в ней хранятся в блоке 0x0012 по смещениям 0x0028 0x002A.

| Сообщение посчитали полезным:

Krueger пишет:
Ссылка на таблицу и кол-во записей в ней хранятся в блоке 0x0012 по смещениям 0x0028 0x002A. - премного благодарны То есть, как я понимаю, прошивка навигатора сам дает инициативу карте задать свою структуру? И нам, в принципе, не в лом будет создавать карту образца 0х0Е? МК1-МК3 ее поймут без вопросов? Я поразмыслю, зачем девелоперами такая возможность предусмотрена была, наверное, чтобы какие-то другие форматы читались? Если я все правильно понял - завтра займусь таблицей описания записей. Krueger, не пропадай, пожалуйста...

| Сообщение посчитали полезным:

Не откладываю в долгий ящик:

Библиография сингапура:

CD-ID 6335
DB-REL 26
BSW-REL 91.0 91.1 92.5 92.7 92.8 93.0 93.1 93.3 93.6 94.0 94.3 95.3 95.6 95.7 95.8
BSW-REL 96.0 96.1 96.2 97.0 98 10

РОМ в ИДЕ:

ROM:00000000 00 00 00 01 00 12 00 00 00 34 00 01 00 00 03 01
ROM:00000010 00 0C 00 01 00 00 01 01 00 01 00 1A 00 00 00 0C
ROM:00000020 00 01 00 08 00 3C 00 1F 00 7A 00 5A 08 00 00 02


Выписка из смещения 0х5А
ROM:00000050 00 0B 00 0C 00 0D 00 0E 00 0F 00 10 00 11 00 12
ROM:00000060 00 13 00 14 00 15 00 16 00 17 00 18 00 19 00 1A
ROM:00000070 00 1B 00 1C 00 1D 00 00 00 00 00 01 00 0C 00 02

Видим: 00 10, 00 11, 00 12, 00 13 ..... 00 1D
Закрывают строку 00 00 00 00 (нулевые байты ? ? ? чексум ? ? ?)

Выписка из смещения 0х7А
ROM:00000070 00 1B 00 1C 00 1D 00 00 00 00 00 01 00 0C 00 02
ROM:00000080 00 10 00 03 00 08 00 04 00 1C 00 05 00 08 00 06
ROM:00000090 00 10 00 07 00 08 00 08 00 1E 00 09 00 18 00 0A
ROM:000000A0 00 06 00 0B 00 74 00 0C 00 06 00 0D 00 04 00 0E
ROM:000000B0 00 30 00 0F 00 08 00 10 00 08 00 11 00 3C 00 12
ROM:000000C0 00 04 00 13 00 06 00 14 00 08 00 15 00 06 00 16
ROM:000000D0 00 06 00 17 01 38 00 18 00 18 00 19 01 28 00 1A
ROM:000000E0 00 08 00 1B 00 34 00 1C 00 28 00 1D 00 04 00 1E
ROM:000000F0 00 08 00 1F 00 14 00 20 00 2C 00 21 00 10 00 22
ROM:00000100 00 04 00 23 00 04 00 24 00 04 00 25 00 14 00 26
ROM:00000110 00 04 00 27 00 08 00 28 00 0C 00 29 00 0C 00 2A
ROM:00000120 00 04 00 2B 00 28 00 2C 00 08 00 2D 00 08 00 2E
ROM:00000130 00 18 00 2F 00 28 00 30 00 0C 00 31 00 08 00 32
ROM:00000140 00 14 00 33 00 20 00 34 00 10 00 35 00 08 00 36
ROM:00000150 00 10 00 37 00 0A 00 38 00 04 00 39 00 04 00 3A
ROM:00000160 00 14 00 3B 00 04 00 3C 00 10 00 3D 00 34 00 3E
ROM:00000170 00 14 00 3F 00 18 00 40 00 0A 00 41 00 04 00 42
ROM:00000180 00 18 00 43 00 1C 00 44 00 04 00 45 00 10 00 46
ROM:00000190 00 38 00 47 00 10 00 48 00 04 00 49 00 04 00 4A
ROM:000001A0 00 08 00 4B 00 14 00 4C 00 08 00 4D 00 0C 00 4E
ROM:000001B0 00 1C 00 4F 00 04 00 50 00 10 00 51 00 28 00 52
ROM:000001C0 00 10 00 53 00 04 00 54 00 04 00 55 00 08 00 56
ROM:000001D0 00 18 00 57 00 0C 00 58 00 04 00 59 00 04 00 5A
ROM:000001E0 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ROM:000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Видим: 00 01 00 0С, 00 02 00 10, 00 03 00 08, 00 04 00 1C ....... 00 5A 00 02
Строка закрыта.

Резонный вопрос: какого хрена мы не видим этих строк в московской демке?
ЭНИ АЙДИЕС?????

| Сообщение посчитали полезным:

Выписка с BmwNav, демка, Москва:

CD-ID 1545
DB-REL 16
BSW-REL 85.8 85.9 86.1 87.2 88.3 89.1 89.2 89.3 90.0 90.1 91.0


ROM:00000000 00 00 00 01 00 12 00 00 00 24 00 01 00 00 03 01
ROM:00000010 00 0C 00 01 00 00 01 01 00 01 00 10 00 00 00 0C
ROM:00000020 00 01 00 08 00 00 02 01 00 01 00 00 00 00 00 00

Байты 0х28 и 0х2А ? ? ? ? ? ?

| Сообщение посчитали полезным:

Таблица хранится в картах начиная с версии 0x12. Для более старых карт таблица встроена в софт.

| Сообщение посчитали полезным:

Krueger пишет:
Таблица хранится в картах начиная с версии 0x12 - это все прекрасно, конечно, за прояснение благодарен, но дальше я в тупике, ни структуры, ни иерархии записей я не понимаю
Все вышесказанное тобой - личные наблюдения? Довольно точно выражаешься, как в мануале...

2 Krueger: Можешь утвердить мое мнение, что в 0х7А - 4 байт данных в группе, а в 0х5А - 2 байта как на вышеуказанной мной выписке?

| Сообщение посчитали полезным: