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

Дизассемблер в 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