Ассемблер

"Убийство острием лишено артистизма. Но пусть тебя это не останавливает, если плоть, раскрываясь, сама себя предлагает."

Ф. Херберт. "Дюна".

Перейдем к непосредственному описанию возможностей HIEW-a. Автор этой книги долго колебался, что писать: "руководство по ключам" или "описание возможностей". В конце концов выбор остановился на последнем. По моему глубокому убеждению, описание на уровне клавиатуры не нужно тем пользовате­лям, которые читают это руководство. HIEW все же хакерский продукт. "А зачем хакеру хелп?" — улыбается Сусликов. Но о возможностях, приемах работы и маленьких секретах читатель узнает с большим удовольствием. И может быть,

тогда начинающие прекратят задавать глупые вопросы: "я знаю, какие байтики подправить, а в HIEW-e их найти никак не могу",

Встроенный ассемблер может быть полезен для многих вещей. Так, например, небольшие файлы удобно набивать сразу в HIEW-e, а не пользоваться masm/tasm-om, которые работают на порядок медленнее. И не понимают многих "извратов". Так, например, когда потребовалось для хитрой защиты ассемблировать смесь шестнадцати- и тридцатидвухразрядного кода со множест­вом команд Pentuinn Pro, никто кроме HIEW-a и собственных ручек не смог этого сделать.

Кроме того, все команды сразу показываются и в hex-кодах, а не после редактирования/ассемблирования/линковки/дизассемблирования (при работе со стандарными средствами), что открывает свободу для экспериментирования и страхует от ошибок. Так, например, тот же TASM частенько даже при задании директивы USE32 почему-то вставляет в непредсказуемых местах ненужные префиксы или (что не лучше) опускает с целью оптимизации расставленные мной. Хотите пример? Попробуйте указать префикс DS для данных. TASM его проиг­норирует (разве что пальцем у виска не покрутит). А теперь представим, что будет, если в самомодифицирующемся коде попытаться изменить префикс, кото­рый был опущен.

Так же незаменим встроенный ассемблер, если в ломаемой программе нужно не просто поменять 7х на ЕВ, а дописать десяток-другой строк кода (а такое случается достаточно часто).

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

Сначала рассмотрим, как происходит загрузка РЕ-файлов. MicroSoft неплохо оптимизировала этот процесс, и РЕ целиком проецируются в память, включая и DOS-секцию. При этом один селектор выделяется для кода и данных. А это означает, что перевод глобальных смещений в локальные осуществляется триви­альным добавлением адреса загрузки, который можно узнать из заголовка РЕ-фай-ла. Поскольку HIEW отображает последний в удобочитаемом виде, то наша задача упрощается еще больше, — достаточно заглянуть в поле Image base. В большинстве случаев там содержатся круглые значения, например 0х400000, 0х010000. Не сложно выполнить все вычисления и в уме, однако к чему напрягаться?Перейдем в начало файла и нажмем Ctrl-F5, после чего введем значение Image base (в нашем случае 400000). Посмотрим, что получилось:

	Дизассемблер	Ассемблер
Без базирования:	.0040119А: call .000401298	0000119А: call 000001298
С базированием:	.0040119A: call .000401298	0040119А: call 000401298

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

Очень удобно, что HIEW при ассемблировании не пытается оптимизировать то, что его не просят. Например, если вы укажете адресацию через DS, то перед командой появится соответствующий префикс ОхЗЕ. Сравните:

00000000: ЗЕД16606 mov ax,ds: [00666]

00000004; A16606 mov ax, [00666]

Любой другой привычный нам ассемблер (tasm, masm) выдал бы идентичные результаты, что не вызывает у меня восторга. За это и любим HIEW: он послушно делает то, что ему говорят.

Ассемблирование вообще процесс довольно творческий. Одна и та же мнемо­ническая инструкция может быть ассемблирована по-разному. Такова уж специ­фика архитектуры линейки 80х86 микропроцессоров от Intel. Микрокод первых процессоров разрабатывался в то далекое время, когда экономить приходилось каждый байт, и поэтому инженеры Intel обратили внимание на ситуацию, когда регистр размером в слово манипулирует непосредственным значением меньшим 0х100. При этом старший байт равен нулю, т.е. теоретически может быть ужат до одного бита, а этот самый бит можно разместить в пустующем поле приемника (ясно, что приемником непосредственный операнд быть никак не может). В результате этих ухищрений экономится один байт. Итак, такую команду можно записать двумя способами:

00000007; 83С266 add dx,066 "f"

0000000A: 81C26600 add dx, 00066 ;" f"

При этом HIEW всегда выбирает первый из них (т.е. пытается оптимизировать код). Это восторга у пользователей не вызывает, ибо часто не соответствует ожидаемому результату.

Диаметрально противоположна ситуация при генерации переходов. По умол­чанию HIEW всегда генерирует близкий (near) переход ОхЕ9. Если необходимо задать близкий переход, то заставить HIEW это сделать поможет команда jmps (jmp short действует аналогично). Позволяя себе слегка покритиковать автора, замечу, что кракеры чаще всего заменяют условный переход на безусловный. При этом jmp near откровенно портит код. Обидно.

Продолжая критику, заметим, что ассемблер также не понимает ни ордина­лов, ни символьных имен, что совсем не радует. Очень хотелось бы в следующих версиях получить полноценную поддержку перечисленных выше форматов.

Б остальном же ассемблер ведет себя корректно и безглючно. При этом имеет встроенный калькулятор. Т.е. он прекрасно переваривает конструкции типа mov ах,[66+11] и даже mov ах,[—77]. Последнее, правда, без учета режима (еще один баг — в копилку'). Отрицательные числа адреса всегда дополняются до слова. При этом в 32-разрядном режиме забавно выглядит попытка ассемблировать •jmp -Г

00000003: E9F7FFFFFF jmp

Заметим, что только извращенцу придет в голову пользоваться последним, однако в защитах это встречается и работает следующим образом. Пусть, например, есть код:

00000000: E9FAFFFFFF jmp -I

00000005: 90 пор

00000006: 90 пор

При этом jmp смещает указатель команд на единицу, и получается:

00000000: FF9090909090 call d,[eax] [090909090]

Что, заметим, никак не очевидно и является довольно любопытным приемом. Вероятно, не всем приходит в голову, что jmp может прыгать в границах своего операнда. Хотя вообще ассемблирование отрицательных переходов в HIEW это один большой баг, или фича. Во всяком случае он не работает так, как ожидается.

Впрочем, это все мелочи, которые в ближайших версиях обоих продуктов будут исправлены.

Еще одним недостатком, приходящим на ум, является упорное нежелание HIEW-a 'переваривать' директиву <ptr>, поэтому выражение

mov Word ptr CS: [077] ,66

не может быть обработано синтаксическим анализатором. Приходится его сокращать до

mov Word CS: [077] , 66

Ужасно неудобно менять свои привычки, но что поделаешь — приходится. Последнее частично скрашивается приятной возможностью сокращать byte/word/dword/pword/qword/tbyte до b/w/d/p/q/t, как показано ниже:

 

Все числа считаются шестнадцатиричными по умолчанию, но никто не будет против постфикса 'h'. А вот с 'х' анализатор не знает что делать и незамедлитель­но начинает ругаться. Это выглядит особенно странно на фоне калькулятора, который такую нотацию как раз понимает, но в свою очередь не переваривает 'h'.

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

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