База данных IDA от void17

У МЕНЯ ПОЛУЧИЛОСЬ ДАМПАНУТЬ ВСЮ ИНФОРМАЦИЮ В ФАЙЛ!!!
https://drive.google.com/file/d/1f33j57 ... sp=sharing

Круто Но тут символы и методы, а названий полей не видно что-то. Есть ли утилита, которая бы вместе с названиями полей доставала типы?

Зато размеры сразу видны:

Код: Выделить всё

Size = 16, class name = type_AI_enemy_data

Отдельно типы: https://drive.google.com/file/d/1NFyoVO ... sp=sharing

AlexSpl писал(а):

Круто Но тут символы и методы, а названий полей не видно что-то. Есть ли утилита, которая бы вместе с названиями полей доставала типы?

Плохо смотрите. Все там есть.
Например:

Код: Выделить всё

0x59d8 : Length = 130, Leaf = 0x1203 LF_FIELDLIST
   list[0] = LF_BCLASS, public, type = 0x599A, offset = 0
   list[1] = LF_MEMBER, public, type = T_LONG(0012), offset = 20
      member name = 'target_hex'
   list[2] = LF_MEMBER, public, type = T_LONG(0012), offset = 24
      member name = 'second_target_hex'
   list[3] = LF_MEMBER, public, type = T_LONG(0012), offset = 28
      member name = 'value'
   list[4] = LF_MEMBER, public, type = T_UCHAR(0020), offset = 32
      member name = 'cast_now'
   list[5] = LF_METHOD, count = 2, list = 0x59D7, name = 'type_spell_choice'

0x59d9 : Length = 42, Leaf = 0x1005 LF_INTERFACE
   # members = 4,  field list type 0x686e,
   Derivation list type 0x0000, VT shape type 0x0000
   Size = 16, class name = type_AI_enemy_data


А я извлёк спецификацию формата вплоть до NB11:

Цитата:

Debug Information Format
The debug information format encompasses a block of data which goes into the .exe file at a location dependent upon the executable file format. The version of the debug information is specified by a signature that is contained within the debug information. The signature has the format NBxx, where xx is the version number and have the following meanings.

NB00 Not supported

NB01 Not supported

NB02 Linked by a Microsoft LINK, version 5.10, or equivalent OEM linker

NB03 Not supported

NB04 Not supported

NB05 The signature emitted by LINK 5.20 and later linkers for a file before it has been packed.

NB06 Not supported.

NB07 This signature is used for Quick C for Windows 1.0 only.

NB08 The signature CodeView 4.00 through CodeView 4.05 uses for a file after it has been packed. CodeView 4.00 - 4.05 will not process a file that does not have this signature.

NB09 The signature for CodeView 4.10 for a file after it has been packed. CodeView 4.10 will not process a file that does not have this signature.

NB10 The signature for an executable with the debug information stored in a separate PDB file. Corresponds with the formats set forth in NB09 or NB11.

NB11 The signature for Visual C++ 5.0 debug information that has been packed and bonded to the executable. This includes all 32-bit type indices.

NB11.zip

(1.98 МБ) Скачиваний: 165

Это чтобы лучше понимать инфу в дампе.

Разобрался, как находить типы полей. type_enemy_data я правильно разобрал

Например,

Код: Выделить всё

list[92] = LF_MEMBER, protected, type = 0x686A, offset = 80
   member name = 'melee_enemies'
list[93] = LF_MEMBER, protected, type = 0x686A, offset = 400
   member name = 'ranged_enemies'
list[94] = LF_MEMBER, protected, type = 0x686A, offset = 720
   member name = 'worst_enemies'

Ищем тип 0x686A:

Код: Выделить всё

0x686a : Length = 14, Leaf = 0x1003 LF_ARRAY
Element type = 0x59D9
Index type = T_SHORT(0011)
length = 320
Name = (none)

Это массив размером 320 байт, 320 / 16 = 20 элементов типа Element type 0x59D9. Ага:

Код: Выделить всё

0x59d9 : Length = 42, Leaf = 0x1005 LF_INTERFACE
# members = 4,  field list type 0x686e,
Derivation list type 0x0000, VT shape type 0x0000
Size = 16, class name = type_AI_enemy_data

Значит, type_AI_enemy_data.

И, наконец, получаем поля type_AI_enemy_data:

Код: Выделить всё

0x686e : Length = 78, Leaf = 0x1203 LF_FIELDLIST
list[0] = LF_MEMBER, public, type = 0x64AB, offset = 0
   member name = 'enemy'
list[1] = LF_MEMBER, public, type = T_LONG(0012), offset = 4
   member name = 'damage'
list[2] = LF_MEMBER, public, type = T_LONG(0012), offset = 8
   member name = 'count'
list[3] = LF_MEMBER, public, type = T_LONG(0012), offset = 12
   member name = 'total_damage'

Как же хочется поблагодарить того, кто выложил дримкаст версию героев. Не то все золото, что блестит. (С)

Теперь хотелось бы выяснить, какие типы использовать. long (12) или всё же привычный int? uchar(20) или привычный bool? Нужно сразу решить, чтобы потом не было путаницы. Интересно, программеры NWC реально заморачивались с long и int, которые в 32-х разрядах одно и то же, или это причуды компилятора?

Всё-таки считаю, что нужно оставлять такие, как в дампе. Т.е. если int, пишем int, а если long, то long.

AlexSpl писал(а):

Теперь хотелось бы выяснить, какие типы использовать. long (12) или всё же привычный int? uchar(20) или привычный bool? Нужно сразу решить, чтобы потом не было путаницы. Интересно, программеры NWC реально заморачивались с long и int, которые в 32-х разрядах одно и то же, или это причуды компилятора?

Я тоже задавался этим вопросом при изучении дримкаст базы. Я вот что понял.
sizeof(long) = sizeof(int) в 32-битной Windows. НО! Разделение NWC делали для себя, чтобы было понятнее. Хоть они имеют один размер, но по задумке те или иные поля или параметры хранят по задумке б0льшие числа в long и меньшие в int.

Цитата:

Разделение NWC делали для себя, чтобы было понятнее. Хоть они имеют один размер, но по задумке те или иные поля или параметры хранят по задумке б0льшие числа в long и меньшие в int.

У меня есть ещё гипотеза о том, что int, по привычке, считали 16-рязрядным, а long в те времена был тру 32-разрядный. Программисты, я думаю, начинали тогда с 16-разрядного кода.

А ещё, вполне возможно, писали с запасом, что было модно. Т.е. думали, вот скоро (рукой подать) станет архитектура 64-разрядной и будет long аж 8 байтов

Надо будет в плагине типы в порядок привести