Inf_ostype

Короткое целое хранящее тип операционной системы для загруженного файла (не среды запуска дизассемблера!)

Должна принимать следующие значения:

OSTYPE_MSDOS	0x0001	MS-DOS
OSTYPE_WIN	0x0002	MS Windows
OSTYPE_OS2	0x0004	OS/2
OSTYPE_NETW	0x0008	Novell NetWare

Да, именно должна, ибо MS-DOS файлы возвращают ноль, а не единицу и, следовательно, OSTYPE_MSDOS не сработает.

Пример использования:

Message("%d \n",

GetShortPrm(INF_OSTYPE)

);

0

Inf_apptype

Короткое целое, содержащие информацию о типе дизассемблируемого приложения. Часть полей (APPT_CONSOLE, APPT_GRAPHIC, APPT_1THREAD, APPT_MTHREAD) инициализируются FLIRT. Если исследуемой программе не соответствует ни одна библиотека сигнатур и FLIRT не сработал, то все вышеперечисленны поля будут содержать нулевые значения.

Тип приложения (EXE\DLL\DRIVER) не актуален для MS-DOS программ, как и разрядность (16 или 32 бит). В этом случае функция всегда возвращает нулевое значение.

APPT_CONSOLE	0x0001	Console
APPT_GRAPHIC	0x0002	Graphics
APPT_PROGRAM	0x0004	EXE
APPT_LIBRARY	0x0008	DLL
APPT_DRIVER	0x0010	DRIVER
APPT_1THREAD	0x0020	Singlethread
APPT_MTHREAD	0x0040	Multithread
APPT_16BIT	0x0080	16 bit application
APPT_32BIT	0x0100	32 bit application

Пример использования:

Message("%x \n",

GetShortPrm(INF_APPTYPE)

);

104

Inf_start_sp

Длинное целое, содержащие значение регистра SP (ESP) при запуске программы. Для получения этой информации IDA читает соответствующие поля заголовка файла. В противном случае (например, для com или дампов памяти) она устанавливает SP на верхушку сегмента, то есть присваивает ему значение –1.

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

Однако, обычно точное значение SP (ESP) не критично и в общем случае не влияет на правильность дизассемблирования кода.

Пример использования:

Message("%x \n",

GetShortPrm(INF_START_SP)

);

ffff

Inf_start_af

Это поле содержит короткое целое, управляющие настойками анализатора IDA. Иначе к ним можно добраться через меню «Options\ Analysis options\ Kernel analyser options 1»

Все они доступны как для чтения, так и для модификации. Назначение битов флагов приведены ниже.

AF_FIXUP	0x0001	Создавать сегменты и смещения, используя информацию из таблицы перемещаемых элементов
AF_MARKCODE	0x0002	Автоматически преобразовывать типичные последовательности инструкций в код
AF_UNK	0x0004	Удалять инструкции без ссылок
AF_CODE	0x0008	Трассировать выполнение
AF_PROC	0x0010	Автоматически создавать функции
AF_USED	0x0020	Поверхностный анализ программы
AF_FLIRT	0x0040	Использовать FLIRT сигнатуры
AF_PROCPTR	0x0080	Создавать функции в 32-битном сегменте, если это ссылка на сегмент данных
AF_JFUNC	0x0100	Переименовывать jump-функции как j_...
AF_NULLSUB	0x0200	Переименовывать пустые функции как nullsub_...
AF_LVAR	0x0400	Создавать стековые переменные
AF_TRACE	0x0800	Отслеживать указатель стека
AF_ASCII	0x1000	Автоматически создавать строки
AF_IMMOFF	0x2000	Преобразовывать операнды 32-инструкций в смещения
AF_DREFOFF	0x4000	Преобразовывать 32-данные в смещения
AF_FINAL	0x8000	Сворачивать все unexplored регионы

AF_FIXUP

если этот бит установлен, то IDA будет использовать информацию из таблицы перемещаемых элементов и представлять соответствующие непосредственные операнды в виде смещений или сегментов.

Например:

Код	AF_FIXUP == 1	AF_FIXUP == 0
B8 01 00	mov ax, seg dseg	mov ax,1001h
8E D8	mov ds, ax	mov ds, ax

Значение перемещаемого элемента, выделенного красным цветом, равно 0x1. В любом случае IDA автоматически суммирует его с адресом загрузки (в нашем примере 0x10000).

Если флаг AF_FIXUP установлен, то IDA преобразует непосредственный операнд в сегмент, в противном же случае оставит его без изменений.

AF_MARKCODE

Установка этого флага приведет к тому, что IDA будет находить все типичные для выбранного процессора последовательности инструкций и будет преобразовывать их в код, даже если на него отсутствуют явные ссылки.

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

Например, для 80x86 процессоров типичной последовательностью инструкций будет инициализация регистра BP (EBP) при входе в процедуру.

.text:00401020 push ebp

.text:00401021 8B EC mov ebp, esp

Обратите внимание, что этот механизм запускается только во время загрузки файла и динамическое его изменение во время работы дизассемблера будет проигнорировано.

AF_UNK

Этот флаг будучи установленным приводит к тому, что IDA будет каждый раз при пометке инструкции (инструкций) как unexplored автоматически отслеживать все потерянные перекрестные ссылки, помечая соответствующие регионы как unexplored.

AF_CODE

IDA умеет трассировать следование инструкций, отслеживая условные переходы и вызовы процедур. Например, если встретится:

seg000:22C3 E8 5F 00 call sub_0_2325

то можно быть уверенным, что IDA преобразует в инструкции и код, находящийся по смещению 0x2325. В противном случае (если бит AF_CODE сброшен) это выполнено не будет. Более того, при загрузке IDA не дизассемблирует ни одной инструкции, предоставляя это пользователю сделать самостоятельно.

Этот флаг имеет смысл сбрасывать всякий раз, когда IDA неправильно отслеживает ссылки или же вам нужно изучить только отдельно взятый фрагмент кода и дизассемблировать весь файл не к чему.

AF_PROC

Автоматически создавать функции на месте вызова инструкцией call. В противном случае функции будут создаваться только для библиотечных процедур. Например:

AF_PROC == 0 AF_PROC == 1

Seg00:0124 call loc_0_284	Seg00:0124 call loc_0_284
Seg000:0284 loc_0_284: seg000:0284 push ds seg000:0285 mov ax, 3500h seg000:0288 int 21h seg000:028A ret	Seg000:0284 sub_0_284 proc near seg000:0284 push ds seg000:0285 mov ax, 3500h seg000:0288 int 21h seg000:028A ret seg000:02C6 sub_0_284 endp

AF_USED

В документации на IDA сообщается, что сброс этого бита приводит к тому, что IDA выполняет поверхностный анализ программы. То есть примитивное дизассемблирование, без создания перекрестных ссылок и дополнительных проверок.

Однако, практически значение этой опции никак не влияет на дизассемблируемый текст и в обоих случаях получаются идентичные листинги.

AF_FLIRT

Уникальная FLIRT технология позволяет IDA определять имена библиотечных функций наиболее популярных компиляторов по их сигнатурам. Сравните два примера:

AF_FLIRT == 1	AF_FLIRT == 0
dseg:039A push offset aHelloSailor dseg:039D call _printf dseg:03A0 pop cx dseg:03A1 retn	dseg:039A pushoffset aHelloSailor dseg:039D call sub_0_1035 dseg:03A0 pop cx dseg:03A1 retn

AF_PROCPTR

Установка этого флага приведет к тому, что IDA будет проверять все перекрестные ссылки из 32-разрядного сегмента данных в сегмент кода. Если ссылка указывает на машинную инструкцию, то IDA автоматически преобразует ее в код и создаст на этом месте функцию.

Например:

AF_PROCPTR == 1	AF_PROCPTR == 0
.data:004085E0 dd offset sub_0_405AAC	.data:004085E0 dd 405AACh
.text:00405AAC sub_0_405AAC proc near .text:00405AAC push ebp .text:00405AAD mov ebp, esp	.text:00405AAC db 55h .text:00405AAD db 8Bh .text:00405AAE db 0ECh

Данный метод не безгрешен и в некоторых случаях может приводить в к ошибкам (тем более возможно предположить умышленное противодействие автора дизассемблируемого текста против IDA) поэтому иногда его приходится отключать.

AF_JFUNC

Установка этого флага приведет к тому, что IDA будет переименовывать функции, состоящие из одной только команды jmp somewhere в j_somewhere. Это заметно улучшает читабельность листинга и ускоряет анализ алгоритма его работы.

AF_JFUNC == 1	AF_JFUNC == 0
seg000:22DD j_MyJmpTrg proc near seg000:22DD jmp short MyJmpTrg seg000:22DD j_MyJmpTrg endp	seg000:22DD sub_0_22DD proc near seg000:22DD jmp short MyJmpTrg seg000:22DD sub_0_22DD endp

AF_NULLSUB

Установка этого флага приведет к тому, что IDA будет переименовывать «пустые», то есть состоящие только из одной инструкции возврата, процедуры в nullsub_xx.

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

AF_NULLSUB == 1	AF_NULLSUB == 0
seg000:22DF nullsub_1 proc near seg000:22DF retn seg000:22DF nullsub_1 endp	seg000:22DF sub_0_22DF proc near seg000:22DF retn seg000:22DF sub_0_22DF endp

AF_LVAR

Механизм отслеживания текущего значения регистра SP (ESP) дает возможность поддержки локальных переменных. То есть тех, что лежат в стеке с отрицательным смещением относительно BP (EBP).

Это становится невероятно полезным при дизассемблировании кода, сгенерированного оптимизирующими компиляторами, которые уже не опираются на BP (EBP), а адресуют локальные переменные относительно стекового регистра ESP. Это приводит к тому, что невозможно понять к какой именно переменной обращается та или иная инструкция, до тех пор пока не будет вычислено значение указателя стека в конкретной точке кода.

IDA взяла на себя эту рутину работу и поддерживает оба типа стековых переменных самостоятельно.

AF_LVAR == 1	AF_LVAR == 0
.text:0040112A mov ecx, [esp+40h+var_1C]	.text:0040112A mov ecx, [esp+24h]

AF_TRACE

Установка этого флага заставляет IDA отслеживать значение регистра указателя стека в каждой точке кода. Главным образом это необходимо для поддержки локальных переменных (см. AF_LVAR)

AF_PROCPTR == 1	AF_PROCPTR == 0
dseg:187A off_0_187A dw offset loc_0_B45	dseg:187A word_0_187A dw 0B45
dseg:0B45 mov dx, 183Ch	dseg:0B45 mov dx, 183Ch

AF_ASCII

IDA может автоматически создавать строки, если элемент на который указывает ссылка состоит более чем из четырех символом ASCII для 16-сегмента (и шестнадцати символов в остальных случаях).

Стиль строки определяется настойками о которых будет сказано ниже.

AF_IMMOFF

Этот флаг имеет смысл только для 32-разрядных сегментов. Если он установлен, то IDA будет преобразовывать 32-разрядные операнды в смещения. Для этого необходимо, что бы операнд был больше минимально возможного адреса загрузки 0x10000.

Значительно облегчает дизассемблирование 32-разрядных приложений, автоматически корректно распознавая большинство смещений и указателей. Поскольку большинство приложений редко оперируют подобными величинами, то вероятность ложных срабатываний (то есть ошибочного преобразования константы в смещение) относительно невелика.

AF_IMMOFF == 1	AF_IMMOFF == 0
.text:00401000 push offset aHeloSailor .text:00401005 mov ecx, offset ord_0_408900	.text:00401000 push 408040h .text:00401005 mov ecx, 408900h

AF_DREFOFF

Если этот флаг установлен, то IDA будет автоматически пытаться преобразовать в смещения все двойные слова, содержащие ссылки из 32-разрядных сегментов.

Преобразование в общем случае осуществляется успешно, если содержимое двойного слова больше, чем 0x10000

AF_DREFOFF == 1	AF_DREFOFF == 0
.data:00408330 off_0_408330 dd offset unk_0_408980 ; DATA XREF: .text:00404758o	.data:00408330 dword_0_408330 dd 408980h

Поясним этот пример. Допустим, в 32-сегменте кода встретится следующая инструкция:

.text:00404758 mov eax, 408330h

Если флаг AF_IMMOFF (см. выше) установлен, то константа 0x408440 будет автоматически преобразована в смещение, так как 0x408440 > 0x10000.

По этому смещению находится следущая ячейка:

.data:00408330 dword_0_408330 dd 408980h

Поскольку 0x408980 больше 0x10000, то, скорее всего, оно представляет собой смещение, в которое и может быть преобразовано, если флаг AF_DREFOFF будет установлен.

AF_FINAL

Если этот флаг установлен, то дизассемблер в последнем проходе анализа автоматически преобразует все байты, помеченные как unexplored, в данные или инструкции.

Правила, по которым происходит это преобразование, не документированы и меняются от версии к версии. В идеале IDA должна была бы практически во всех случаях «угадать» чем является каждый элемент – данными или инструкцией. Однако, на практике она часто допускает ошибки, особенно com файлах, где данные и код могут быть сложным образом перемешаны.

Для win32 файлов с раздельными сегментами кода и данных, эта проблема отсутствует.

Рекомендуется сбрасывать этот флаг (по умолчанию он установлен). И вот почему – рассмотрите пример, приведенный ниже. Очевидно, что по адресу seg000:210D расположены строки:

seg000:210D aDir db '..',0

seg000:2110 aMask db '*.*',0

Но IDA, не найдя на них ссылок (поскольку невозможно для 16-разрядных приложений отличить смещения от констант) превратила их в малоосмысленный массив.

Очевидно, что программа была дизассемблирована не правильно. Поэтому лучше не полагаться на автоматически алгоритмы IDA, а исследовать unexpored байты самостоятельно.

ЗАМЕЧАНИЕ: для некоторых типов файлов (например, PE) значение этого флага в ряде случаев игнорируется и остаются unexplored байты.

AF_FINAL == 1	AF_FINAL == 0
seg000:210D db 2 dup(2Eh), 0, 2Ah, 2Eh, 2Ah, 0	seg000:210D db 2Eh ; . seg000:210E db 2Eh ; . seg000:210F db 0 ; seg000:2110 db 2Ah ; * seg000:2111 db 2Eh ; . seg000:2112 db 2Ah ; * seg000:2113 db 0 ;