и интенсивно развивающимся продуктам, то

IDA относится и интенсивно развивающимся продуктам, то есть вследствие постоянного совершенствования даже близкие версии могут вести себя по-разному. А по сему оговорюсь: описываемая мной последовательность действий рассчитана на версию 4.1.5.520, самым честным образом купленную. Если у вас другая версия, и мои советы "не проходят", то: во-первых, я не виноват, а во-вторых - для разнообразия попробуйте не только тупо следовать руководству, но еще и головой думать (сорри за грубость).
Что касается дизассемблирования вообще, то тут четко необходимо уяснить для себя одну вещь: вследствие того, что ассемблирование - это однонаправленный процесс с потерями, автоматическое восстановление исходного текста невозможно. Хотя, казалось бы, чего тут сложного - перевод двоичного кода процессора в удобночитаемые мнемоники… а фиг вам, задачка еще та!
Существуют две категории дизассемблеров: автономные и интерактивные. Автономные требуют у юзверя все необходимые им указания до начала процесса дизассемблирования и не позволяют вмешиваться в сам процесс. Соответственно, если результат нас не устраивает или мы желаете попробовать какую-либо дополнительную фичу из предоставляемых дизассеблером, то весь процесс (а для больших программ он может длиться часами!) придется повторять, и, скорее всего, не один раз.
А вот интерактивные позволяют "вручную" управлять процессом "препарирования" программы. В любой момент мы можем сказать дизассемблеру "парень, ты гонишь" и помочь этому парню, например, отличить адреса от констант либо определить границы инструкций и т. д. Соответственно, интерактивные дизассемблеры имеют хорошо развитый пользовательский интерфейс, а некоторые (не буду показывать пальцем, все наверняка уже догадались, какой дизассемблер я имею в виду) имеют даже собственный си-подобный язык скриптов! И более даже более того - являются виртуальной программируемой машиной!

Не знаю, как на вашем дисплее, но на моем 17-дюймовом с разpешением 1024х768 окошко отладчика получилось больно уж маленьким. Чтобы не напрягать глаза, его можно немножко "под себя" настроить. Ок! Давайте попробуем ввести несколько команд, которые позволяют выполнить подобную настройку. Для этого пишем следующие команды:
- SET FONT 2 - и шрифт в окошке немного увеличивается, как и сам размер окна;
- LINES 60 - увеличиваем число строк в окне отладчика;
- WD 22 - задаем число строк под дамп;
- WC 25 - задаем число строк под код;
- CODE ON - разрешить отображать байты инструкций.;
- COLOR A A 20 20 2 - устанавливаем "извращенную" цветовую схему (подробнее о параметрах смотрите в SoftIce Command Reference, битовое кодирование цвета мы рассматривали).
Еще одна команда (я настоятельно рекомендую ее использовать, особенно пользователям W9X) - это FAULTS OFF, которая предотвращает "всплытие" отладчика при возникновении GPF - General Protection Fault, в просторечии также известную как "ваши ручки выполнили недопустимую операцию и будут ампутированы".

Есть ещё один регистр, ассоциируемый со стеком - ebp/bp, и описывается его функция так, что выговорить страшно – указатель базы кадра стека. Такое название этого регистра я нашел в книжке Юрова & Хорошенко "ASSEMBLER, учебный курс". Нет, конечно же, можно назвать калоши "мокроступами", а bitmap "двоично-точечной картинкой", но... "У меня нет слов, у меня есть только выражения в адрес того, кто заворачивает такие коленца" (C) Аркадий Белоусов. А по сему давайте заменим словосочетание "кадр стека" простым народным :) словом "фрейм", а "указатель базы" заменим на просто "база" (или "указатель" - по вкусу).
В результате подобных терминологических "подстановок" получается следующая картина: есть у нас в компьютере некие "фреймы", располагаются они в стеке и адреса этих пока что непонятных нам штук завязаны с регистром ebp/bp.
"Дело в следующем". Любая процедура/функция в терминах любого процедурного языка имеет (может иметь) нуль и больше параметров и локальных переменных. Область памяти, создаваемая (выделяемая) при вызове процедур для аргументов и локальных переменных, и называется фреймом. А чтобы процедура могла быть рекусивной (т.е. могла вызывать саму себя или вызываться из других процедур, которые она вызывает) или реентерабельной (т.е. чтобы код процедуры мог использоваться в параллельных процессах), фреймы для неё должны размещаться в стекоподобной структуре данных - "стеке". А поскольку процедурные языки ближе к "естественному" мышлению, то в наборы инструкций процессоров и ассемблеры вводят поддержку подобных высокоуровневых конструкций.
Существуют нюансы и различия в реализациях, например:

Писюковые сишные компиляторы генерят код, в котором часть фрейма с аргументами после вызова процедуры удаляется вызывающим кодом, а в паскалевских соглашениях о вызове фрейм всегда удаляется самой процедурой (что экономит на размере кода, поэтому это соглашение было принято как стандартное в Windows).
В Паскале существует понятие локальных процедур, которые могут обращаться к параметрам и локальным переменным всех родительских (в смысле статического размещения, а не динамического порядка вызовов) процедур и при этом могут быть рекурсивными (родительские процедуры тоже могут быть рекурсивными, и доступ к переменным должен идти к последнему, активному экземпляру). Для поддержки этой идеи во фреймы добавляются указатели на родительские фреймы, обычно организованные в виде списка.
Фортран вообще язык не рекурсивный, поэтому IBM в реализации Фортрана на IBM/360 (где, кстати, нет поддержки стека) для каждой процедуры заводила фрейм статически, во время компиляции.

Подобные "нюансы" сущности фрейма, конечно же, не меняют. Приведены они по одной единственной причине – чтобы вы поняли некоторую условность такого термина как "фрейм".
Теперь, собсна, про ebp/ep. В случае стекового фрейма его адрес не фиксирован, поэтому адресация параметров и переменных в нём должна быть "базисно-индексной", относительно начала фрейма. На писюке под это идеально подошёл (или изначально проектировался) BP/EBP - в отличие от SP, он может служить базой, и также адресуется относительно SS.
Я знаю, что вы мало что поняли из всего этого бреда, а по сему будем познавать истину путем долгой и продолжительной медитации.

Содержание раздела