Дизассемблер

Дизассемблер в HIEW великая вещь. фактически это основной режим работы хакера. Не то чтобы некоторые ленились дизассемблировать в уме hex-коды, (что, скажем, частенько приходится делать при работе со встроенным вьюером в DN), но ассемблерный листинг все же привычнее для глаза и, кроме того, имеет множество дополнительных возможностей (таких, как поиск ассемблерных ко­манд по маске), которые заметно ускоряют анализ программ.

К сожалению (и, признаться, еще большему удивлению), автор не считает HIEW дизассемблером и не хочет улучшать некоторые моменты чисто из идеоло­гических соображений. Ну что же, будем ждать поддержки языка, где все это можно будет делать на лету, не обращаясь за помощью к автору. И сообразно со вкусами каждого. Беда в том, что раскачать автора на встроенный язык или хотя бы задокументированный API (язык-то написать нетрудно) пока никак не получа­ется.

Ничего не поделаешь: как говорится хозяин — барин, тем более что автор пишет HIEW пока лишь для собственного удовольствия и исходя из своих этических соображений. Вот когда автор будет получать за свою работу "живые" деньги, тогда и можно будет ждать исполнения желаний, а пока остается только надеяться или садиться и писать собственный Xview. Последнее, кстати, многие активно делают, и автор этой книги не исключение. Впрочем, его UniversalViewer находится в весьма заброшенном состоянии, но если когда-то будет закончен, то... появится еще один конкурент на рынке hex-редакторов. К слову сказать, UV изначально рассчитан на мультипроцессорную поддержку и будет очень удобен при анализе эмуляторов виртуальных процессоров.

Но это когда еще будет (и будет ли вообще), а HIEW уже есть и поддерживает инструкции вплоть до Pentium Pro. А точнее, до Рб-kernel, которое используется и в Celeron-ax.

Типичный вид дизассемблированного текста таков:

.00401207: 50 push eax

.00401208: 52 push edx

.00401209: ESD2FEFFFF call. .0004010EO -------- (1)

.0040120E: 83C404 add еsр,004 ;

.00401211: 50 push eax

.00401212: E8A9FEFFFF call .0004010CO -------- (2)

.00401217: 83C408 add esp,008

.0040121A: 663DF801 cmp ax,OOIF8 ;

.0040121E: 7404 je .000401224 -------- (3)

.00401220: 6A03 push 003

.00401222: EB02 jmps .000401226 -—-—-- (4)

.00401224: 6A04 push 004

Hiew позволяет "путешествовать" по файлу, входя в процедуры и выполняя условные/безусловные переходы. Для этого нужно нажать цифру, которая показана в круглых скобках справа. Переходы в IDA реализованы несколько лучше. Переход осуществляется по адресу, на котором находится курсор. Это действительно удобнее, так как позволяет "гулять" и по смещениям, передавае­мым через стек или регистры. Например:

.004012B9: 6840314000 push 000403140 ;"@1@"

.004012BE: 6844314000 push 000403144 ;"@lD"

.004012C3: FF74240C push d, [esp] [OOOOC]

.004012C7: E834010000 call .000401400-------- (2)

Hiew не распознал смещения 0х00403140 и 0х00403144. Конечно, можно перейти по ним вручную (F5), по это не очень приятно. Впрочем, общественное мнение может не совпадать с мнением автора.

При этом поддерживается многоуровневый откат, который по умолчанию находится на '0' (как это изменить, рассказано в описании файла hiew.ini). К сожалению, буфер отката кольцевой, что не вызывает восторга. Так как чтобы вернуться в начальную позицию, надо держать в голове глубину вложенности (а это весьма проблематично). Было бы гораздо лучше если бы при исчерпании стека HIEW пищал хотя бы...

Вообще же навигация по исполняемым файлам дело привычное. В любой момент можно прыгнуть в произвольную точку, нажав F5. При этом адрес будет интерпретирован как локальный, если перед ним находится символ '.'; в против­ном случае всегда осуществляется переход по глобальному смещению внутри файла.

При этом HIEW корректно обрабатывает относительные переходы. Например, можно задать +77 или -66 и курсор переместится на 77h байт вперед или 0х66 назад относительно текущей позиции. Печально, но при этом откат невозможен. Хотя поддержка его была бы не лишней и великолепно вписывающейся в общий антураж программы. Еще один довод в пользу того, что встроенный язык избавил бы его от подобных приставаний.

Аналогично обстоит дело и с поиском перекрестных ссылок. Автоматический откат назад не предусмотрен. С другой стороны, это настолько уникальная и полезная вещь, что рука не поднимается каким-либо образом ее критиковать. Традиционно для поиска перекрестных ссылок использовались IDA или SOUR-CER (который в этом отношении до сих пор обгонит всех конкурентов). Однако монстроватые дизассемблеры очень медлительны и неповоротливы. Для анализа больших файлов не хватит не только терпения хакера, но иной раз и дискового пространства.

Поэтому выбор многих останавливается на HIEW-e. Даже когда он не мог делать это автоматически, ручной поиск занимал все же меньше времени, чем загрузка файлов в IDA. К тому же в большинстве случаев ссылки на сегмент данных в РЕ-файлах (например, поиск кода, выводящего строку 'key not found') с легкостью обнаруживались "прямым" поиском локальных смещений (с учетом обратного порядка байтов в двойном слове).

Однако поиск относительных смещений таким образом был уже невозможен. С другой стороны, требуемое нам смещение лежит "прямым текстом" в дизасссм-блированном листинге. Остается лишь просканировать последний. Не могу удер­жаться и не заметить, насколько логичен в этом случае IDA, который поддержи­вает "медленный" поиск подстроки именно в тексте дизассемблера. Это действительно медленно, но на все 100% надежно. HIEW же просто дизассембли-рует код на лету с шагом в одну команду (или даже байт) и сравнивает непосредственный операнд с текущим смещением, при этом косвенная адресация игнорируется и значения сегментных регистров не отслеживаются. Поэтому такой поиск хорошо работает только на односегментных моделях памяти. Во всех других случаях появятся проблемы (ссылки не будут найдены или найдены неверно).

Последнее, впрочем, не подлежит исправлению без переработки всей архитек­туры HIEW-a, и мы получим продукт, мало отличающийся скоростью от средне­статистического дизассемблера. К счастью, наиболее популярный сегодня формат Win32 хранит РЕ-данные и код в одном сегменте, поэтому в отслеживании сегментных регистров никакой нужды нет.

По умолчанию при дизассемблировании HIEW анализирует текст с шагом в одну команду, что многократно ускоряет работу, но недостаточно надежно. Разберем следующий пример:

retn

DB 0х66

call 0х0666

Для сот-файлов это достаточно типичный случай. Как вы думаете дизассем-блирует его HIEW? Разумеется HIEW не догадается, что '0х66' переменная, и выдаст следующий результат:

00000000:C3 retn

00000001: 66ЕВ6106 call 00000066В

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

00000000:03 retn

00000001: ООЕ8 add al,ch

00000003: 61 popa

00000004:06 push es

Это происходит потому, что HIEW неправильно определил границы команд, в результате чего не смог их правильно дизассемблировать. Ни в коем случае не стоит считать последнее "глюком" или недостатком. Это следствие самой концеп­ции элементарного дизассемблера. IDA справляется с этой ситуацией ценой больших затрат времени на анализ программы. Для файлов в сотни килобайт это не вызывает проблем на современных быстродействующих процессорах, но даже мощности Pentuirn-a II и Celeron-a начинает не хватать, когда счет идет на мегабайты или даже десятки мегабайт (между прочим, размер типичного испол­няемого файла под Windows).

Ситуацию может спасти разве что перекладывание части работы на человека. В приведенном примере ясно, что код после ret, собственно говоря, не является обязательно кодом. С таким же успехом это могут быть данные. Чтобы разобрать­ся, необходимо найти ссылки на эту область памяти. Устанавливаем курсор на первый байт, переключаем (на всякий случай) шаг сканирования на единицу (alt-F6) и нажимаем F6. Допустим, HIEW нашел следующий код:

Mov al, [01]

(Впрочем, не факт, что версия 6.03 его найдет, но для простоты будем считать, что HIEW к моменту чтения этого опуса уже научился поддерживать и такую адресацию). Ясно, что 0х01 — это переменная размером в байт. Отмечаем это (карандашом в блокноте, так как HIEW все еще не поддерживает комментариев) и переходим к ячейке 0х2. Вновь нажимаем F6 и изучаем код, манипулирующий с этим адресом. Пусть он выглядит следующим образом:

ОООООООО: СЗ retn

00000001: ООЕ8 add al,ch

00000003: 61 popa

00000004: 06 push еs

00000005: A00100 mov al, [00001]

00000008: E8F7FF call 000000002 -------- (l)

Чтобы привести код в удобочитаемое состояние, достаточно перейти по адресу 0х2, для чего можно нажать 1' (переход по ссылке) или даже <F5> "02".

00000002: Е86106 call 000000666

00000005: А00100 mov al, (00001]

00000008: E8F7ff call 000000002-------- (l)

Конечно, пример является надуманным, но тем не менее технику работы с примитивными дизассемблерами он иллюстрирует неплохо. Замечу, что "прими­тивный дизассемблер" вовсе не оскорбление, а соответствующий класс программ, которые выполняют только декодирование инструкций, перекладывая все осталь­ное на плечи пользователя.

Если приведенный пример действительно является corn-файлом, то скорее всего HIEW не сможет правильно найти ссылки, потому что неправильно вычис­лит адреса, Это неудивительно, если вспомнить, что corn-файлы загружаются в память со смещения 0х100 в текущем сегменте. Пусть оригинальный файл выглядел так:

0х100: A10401 mov ax,[00104h]—<1

0х103: СЗ retn

0х104; 1234 DB 3412h <1—

Hiew же дизассемблирует его как:

00000000: A10401 mov ax, [00104]

00000003; СЗ retn

00000004; 1231 adc dh,[si]

………………..

00000104:xxxx

Разница в том, что ссылка во втором случае указывает "в космос", но никак не на переменную 0х4. Это можно исправить, указав HIEW-y вручную начальное смещение файла. Выше мы уже сталкивались с этим при анализе РЕ-файлов. В терминологии SEN-a это называется базированием и может быть задано в любой момент анализа (а не только до загрузки, как во многих других дизассемблерах). Нажимаем Ctrl-F5 и вводим число 0х100. Теперь код выглядит так:

00000100: А10401 mov ax, [00104]—

, 00000103: СЗ retn

00000101: 1234 adc dh, [si] <—

00000106: 0100 add [bx] [si], ax

00000108: E3F7FF call 000000102-------- (i)

И все ссылки при этом работают правильно. Заметим, что базирование никак не влияет на вызовы процедур и переходы, поскольку в архитектуре процессоров Intel они относительные.

Рассмотрим более сложный пример, в котором код и данные размещены в разных сегментах. HIEW ничего не знает о последних и поэтому неверно вычисляет все ссылки. Рассмотрим, например, любую программу на Pascal. Загрузим ее в HIEW и перейдем в точку входа (F8, F4, но об этом чуть позже).

ООООООСЕ: 2Е9А00007100 call 00071:00000 ------ (1)

OOOOOOD4: 9AODOOOFOO call OOOOF:OOOOD------ (2)

OOOOOOD9: 55 push bp

Поскольку после загрузки файла регистр DS указывает на сегмент PSP, то приложение должно настроить его самостоятельно. В программах, компилирован­ных turbo-pascal, это происходит в модуле SYSTEM (самый первый вызов). Входим в него нажатием 1' и изучаем следующий код:

000007АО: BAODOI mov dx,OOIOD ;

000007АЗ: 8EDA mov ds,dx

Что такое OxIOD? Это смещение в памяти, которое отличается от смещения в файле только длиной заголовка. На деле, в отличие от РЕ-файлов, загрузчик DOS-EXE пропускает заголовок, тем самым экономя немного памяти. Длину заголовка узнать несложно (значение поля Paragraphs in header нужно умножить на 0х10). Аналогично поступим и со значением DS. Итого OxIODO + 0х90 ==== 0х1160 смещение сегмента данных в файле.

Смотрим на код, стоящий ниже:

000007АО: BAODOI mov dx,OOIOD ;

000007ДЗ: 8EDA mov ds,dx

000007A5: 8C063800 mov [00038], es

Чтобы узнать, на какую ячейку ссылается [0х038], надо к последней добавить 0х1160. Не правда ли, утомительно? Было бы гораздо лучше, если бы HIEW выполнял такой пересчет автоматически. Попробуем для этой цели использовать базирование. Установим курсор на адрес 0х1160 и нажмем Alt-F5. Теперь надо добиться, чтобы текущее смещение равнялось нулю. Очевидно, для этого необхо­димо задать базирование, равное по модулю, но противоположное по знаку. Т.е. '-0х1160'. Однако HIEW поддерживает и относительные смещения, отмеченные префиксом '*'. Это действительно удобно и избавляет от лишних математических вычислений. При этом Ctrl-F5, Ctrl-F5 действует аналогично '*0'.

Мы добились того, что смещения в сегменте данных начинаются с нуля, но... Маленькое, но грустное "но". Взгляните на сегмент кода:

FFFFEF6F: 2Е9A00007100 call 00071:00000 -------- (2)

FFFFEF75: SAODOOOFOO call OOOOFlOOOOD —-——- (3)

FFFFEF7A: 55 push bр

FFFFEF7B: 89E5 mov bp,sp

FFFFEF7D: 31CO xor ax, ax

Печально, не правда ли? Впрочем, это не так актуально, поскольку в кодовом сегменте большинство смещений относительные и будут нормально функциони­ровать независимо от базирования.

Так-то оно так, но Turbo Pascal имеет странную привычку располагать некоторые данные в кодовом сегменте. Взгляните:

FFFFEF31: 10 S2 Д2 Д5-Д4 AS Е2 А5-20 AF АО 70-АЕ ДВ ЕС ЗА >Введите пароль; FFFFEF41: 20 04 59 75-4В 69 12 8F-AO 70 ДЕ AB-EC 20 AD Д5 *УиК1*пароль не

И вот обращение к этой строке:

FFFFEF88: mov di,00266

FFFFEF8B: push ds
FFFFEF8C push di
FFFFEF8D mov di, 000
FFFFEF90 push cs
FFFFEF91 push di
FFFFEF92 xor ax,ax
FFFFEF94 push ax

FFFFEF:95 call 0071:00670

Кто бы мог подумать, что в кодовом сегменте эта строка располагается с нулевым смещением! Однако это действительно так, в чем можно убедиться: F5,90Ctrl-F5, Ctrl-F5:

00000000: 10 82 А2 A5-А4 A8 Е2 A5-20 AF А0 70-AE AB EC ЗА ^Bвeдитe пароль: 00000010: 20 04 59 75-4В 69 12 6F-AO 70 AE AB-EC 20 AD А5 «УиКИПароль не

Но теперь "уползли" все смещения в сегменте данных. И необходимо при первом же обращении к нему вернуть все на место. Как-то неаккуратно получа­ется. К тому же маловероятно, чтобы это было как-то исправлено в последующих версиях. Автор HIEW-a изначально рассчитывал на поддержку только одного сегмента. Теперь же, когда DOS-файлы уходят в прошлое, это ограничение выглядит уже не таким существенным.