Win32 в машинных кодах :: Прикладное программирование

1. Введение в машинные коды для Win32

Мир машинных кодов для процессоров Intel IA-32 захватывающий и фантастический. Он предоставляет такие богатые возможности для творчества, что будет неудивительно, если через некоторое время станут проводить чемпионаты по спортивному программированию в машинных кодах, а лучшие творения кодеров представлять на выставках, как произведения искусства. Множество интересных находок было накоплено за прошедшие годы кодокопателями, среди которых есть как законные системные программисты, так и подпольные авторы вирусов, хакеры и кракеры.

Как когда-то великие путешественники-первопроходцы открывали новые земли, кодеры исследуют бурно разросшееся виртуальное пространство информационных технологий. Несмотря на то, что ее создавали сами люди, эта матрица нашего времени стремительно развивается по каким-то своим законам. Накопились огромные пласты неосвоенных знаний. Развилась целая философия "быстрой разработки приложений" - своего рода "информационный фастфуд". Но разве может забегаловка заменить собой изысканный ресторан?

Можно сказать, информационные технологии проходят сейчас период массового производства, как когда-то автомобильная и другие виды промышленности. Конвейер штампует однотипные универсальные изделия. Но посмотрите на исторические тенденции. Сначала автомобили собирали поштучно. Потом появился конвейер. Но сейчас самые дорогие и качественные машины опять собирают вручную! А разве механические часы исчезли с появлением электронных? Напротив, стали только качественнее и дороже. А когда их сравнивают с электронными, последние презрительно именуют "штамповкой". И как сравнить массовую бижутерию с синтетическими камнями с филигранной ювелирной работой?..

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

Вот с этой целью и появилась задумка систематически рассмотреть с уровня машинных кодов работу наиболее популярной ОС - Windows, чтобы это оказалось доступным самому широкому кругу заинтересовавшихся читателей - от простых пользователей до искушенных программистов. Это и программирование, и изучение работы ОС "изнутри", причем проводимое без всяких посредников в виде языков программирования, вспомогательных библиотек и сред разработки, напрямую, "как есть" в самой ОС. Для работы специально будут использоваться простейшие и даже примитивные инструменты, входящие в состав любой версии Windows от 95 до XP и даже 2003 Server - любой, кто захочет, сможет повторить описываемые эксперименты на самом обычном компьютере.

Хочу добавить пару слов о пользователях, никогда до этого не программировавших. Идея научить их программировать - причем сразу в машинных кодах и сразу под Windows - может, и несколько авантюрная (даже многие низкоуровневики отнеслись к ней скептически), тем не менее, мне кажется, это вполне посильная задача. Особенно если учесть, сколько сил и времени надо затратить, чтобы научиться работать в интегрированной среде разработки, скажем, в том же VisualBasic'е, не говоря уже о том, что надо еще выучить язык. А если, не приведи господи, в набранном из самоучителя тексте окажется опечатка и система выдаст кучу сообщений об ошибках - для новичка продраться через это, по моему глубокому убеждению, гораздо более нереально, чем построить собственными руками подобное же, но работоспособное приложение в машинных кодах.

Не надо бояться окунуться в джунгли машинных кодов. На самом деле, здесь уже есть и проторенные дороги, и тайные заветные тропинки - надо всего лишь их знать и уметь по ним ходить. И я хочу просто показать, как это можно сделать; а уж каждый пусть сам сравнивает, оценивает и решает, сложно это или элементарно, нужно это ему или нет - это будет осознанный выбор, основанный на его собственных знаниях и опыте, а не на чьих-то стереотипах из прошлого.

Что ж, пора перейти от вступлений к сути. Архитектура процессоров Intel IA-32 относится к CISC-модели (с усложненным набором инструкций). Одна из самых примечательных особенностей этих процессоров - формат команды с переменным размером. Команда процессора может быть от 1 до 15 байтов длиной (включая возможные префиксы). Любители комбинаторики могут подсчитать количество возможных инструкций при такой схеме. Но и без подсчетов ясно, что число астрономическое. Команда может иметь один или несколько так называемых префиксов; собственно код операции (он называется опкодом) состоит из 1 или 2 байтов, а дальше идут байты, описывающие операнды - данные (или ссылки на данные), над которыми производится соответствующая операция. Даже если считать командой лишь байты опкода, то возможны 255 однобайтных команд и столько же двухбайтных (в двухбайтных опкодах первый байт всегда одинаков и равен 0Fh). Т.е. получаем свыше 500 команд процессора (на самом деле, не все возможные опкоды используются в настоящее время; кроме того, некоторые опкоды могут иметь дополнительные поля в байтах для операндов и т.п., но это уже тонкости, которые мы можем пока опустить).

Пугаться этого не следует. На самом деле, для программирования под Windows требуется весьма ограниченный набор инструкций, и скоро мы сможем в этом убедиться. Мы будем изучать нужные нам инструкции по мере необходимости. А сейчас кратко рассмотрим "суть" программирования в машинных кодах, а она довольно проста.

Компьютер - это машина для обработки информации. Для этой цели вся информация, которую нужно обработать, делится на более-менее элементарные "кусочки". Необходимая обработка тоже подразделяется на более-менее элементарные действия. Элементарный "кусочек" обрабатываемой информации называется операндом, а элементарное действие - командой. Таким образом, инструкция процессора представляет собой команду и связанные с ней операнды (которые, кстати, могут подразумеваться, а не быть явно заданными в инструкции). А сама программа представляет собой набор инструкций.

Все уже знают, что информация в компьютере представлена в виде двоичных чисел. Обычно в этом месте положено рассказывать об основах двоичного и шестнадцатеричного счислений и способах перевода чисел из одной формы представления в другую, но мы этого делать не будем. Во-первых, это несколько отвлекает от нашей непосредственной темы; во-вторых, кому надо, без труда найдет соответствующие сведения; а в-третьих, все это и так запомнится при практической работе. А если на первых порах будут проблемы, в Windows есть стандартное приложение - калькулятор, который можно использовать для перевода чисел из одной формы в другую. Только в меню "Вид" калькулятора установите "Научный", и в верхнем ряду слева увидите 4 кнопки-переключателя "Hex", "Dec", "Oct", "Bin", которыми и нужно пользоваться.

Windows сильно упрощает программирование - это относится к машинным кодам в значительно большей степени, чем к любому языку программирования на высоком уровне (обстоятельство, которое упускают из виду противники низкоуровневого программирования). Для программирования под Windows нам вполне достаточно рассматривать процессор, как обычный калькулятор. В свое время был такой программируемый калькулятор - Б3-34. Он имел 14 регистров для хранения чисел. В процессоре тоже есть набор 32-разрядных регистров общего пользования, и их всего 8. На ассемблере их обозначают как EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI. Понятное дело, в машинных кодах никаких букв нет, и регистры кодируются тремя битами (в указанном выше порядке - от 000 до 111). Но в разговоре для удобства мы будем использовать и их "названия".

Еще одна особенность интеловских процессоров - они несут на себе "печать своего детства": когда-то регистры были 16-разрядными, и именовались соответственно как AX, CX, DX, BX, SP, BP, SI, DI (причем с такими же кодами, как для 32-разрядных регистров). Еще раньше микропроцессоры были 8-разрядными, и регистров у них было поменьше; очевидно, это тоже оставило свой след, поскольку к четырем 16-разрядным регистрам (AX, CX, DX, BX) можно обращаться побайтно, т.е. отдельно к старшему и младшему байтам. Эти отдельно взятые байты четырех общих регистров обозначаются как AL (младший байт AX), CL, DL, BL, AH (старший байт AX), CH, DH, BH; а коды их тоже соответственно от 000 до 111 (совпадают со значениями для "полных" регистров.

На рисунке показано взаимоотношение адресуемых частей для регистра EAX; регистры ECX, EDX и EBX имеют подобную же схему. Регистры ESP, EBP, ESI и EDI "включают" в свой состав лишь 16-разрядные SP, BP, SI, DI и не допускают обращения к отдельным байтам.

Как же узнать, к какой именно части регистра происходит обращение, тем более, если коды регистров одни и те же (как в случае EAX, AX и AL)? Эта информация заложена в саму инструкцию. Многие опкоды имеют так называемый бит w, который указывает на размер используемого регистра (или операнда в целом): если он равен 0, это байт, если 1, "полный" регистр. В 16-разрядном режиме бит w обозначает размер операнда 8 или 16 бит. Но современная Windows работает в 32-разрядном режиме, и состояние бита w обозначает размер операнда 8 или 32 бита. Обращение к 16 младшим битам регистра тоже возможно, но для этого используется другая схема с применением префиксов (об этом поговорим в другой раз).

Есть еще два регистра, с которыми придется иметь дело: это регистр флагов EFLAGS и указатель инструкций EIP. Состояние регистра флагов может меняться после каждой инструкции в зависимости от полученного результата; подробнее об этом поговорим в другой раз. Регистр EIP содержит адрес начала следующей инструкции в памяти. Его значение увеличивается каждый раз, когда из памяти извлекается для исполнения очередная инструкция, на величину размера этой инструкции.

Обрабатываемые инструкцией данные могут находиться не только в регистре, но и в памяти, а также входить в состав самой инструкции. При обращении к памяти в инструкции указывается адрес, по которому расположены данные. Рассмотрим различные способы доступа к данным на примере инструкции (а вернее, группы инструкций) перемещения данных, которыми мы будем очень активно пользоваться. На ассемблере группа данных инструкций обозначается мнемоникой MOV.

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

Код:

1011 w reg <байты данных>

В зависимости от значения бита w за опкодом следует либо 1, либо 4 байта, содержащих непосредственное значение (и это значение попадет соответственно либо в 1-байтную часть регистра, либо заполнит регистр целиком). В архитектуре IA-32 используется так называемый "little-endian" порядок следования байтов (его называют обратным): сначала (по младшим адресам в памяти) размещаются младшие байты числа. Т.е. 16-ричное ABCDh будет представлено как байты CDh ABh, а 12345678h - как 78h 56h 34h 12h. Подробнее об этом поговорим в следующей статье, а пока пример: загрузим в регистр EAX единицу. Регистр 000, бит w=1 (полный регистр), а данные - внимание - 4 байта для одной единицы!

Код:

10111000 00000001 00000000 00000000 00000000

Или в 16-ричном виде: B8 01 00 00 00. А вот как то же значение передается в младший байт регистра EAX (т.е. AL): регистр тот же - 000, бит w=0 (1 байт), а вот данные уже - 1 байт - 01:

Код:

10110000 00000001 (B0 01)

Обратите внимание - если в регистре EAX до этого содержался 0, последняя инструкция будет равносильна первой. Но в общем случае это не так.

Теперь эту же единицу загрузим в старший байт регистра AX (2-й байт EAX): тоже один байт (w=0), но код регистра AH уже другой (100):

Код:

10110100 00000001 (B4 01)

Удовольствие составления различных инструкций с данным опкодом оставим вам для самостоятельных упражнений и перейдем к другой команде, которая перемещает данные между памятью и регистром EAX (AX, AL):

Код:

101000 d w <байты адреса>

Этот опкод содержит бит w, но не содержит кодов регистров, поскольку он предполагает работу лишь с регистром EAX (или его частью). Зато есть другой характерный бит - d (direction), указывающий направление перемещения данных - из памяти в регистр (0) или из регистра в память (1).

В этом примере мы видим одну важную особенность обращения к данным в памяти: размер операнда и размер его адреса в памяти - разные вещи. В данном случае операнд находится в памяти и может занимать 1, 2 или 4 байта, тогда как адрес (входящий в состав самой инструкции) в любом случае занимает 4 байта. Составим инструкцию для перемещения в регистр EAX значения, которое хранится по адресу 1. Используется полный регистр (w=1), направление - из памяти в регистр (d=0):

Код:

10100001 00000001 00000000 00000000 00000000 (A1 01 00 00 00)

А теперь то же значение загрузим в регистр AL (w=0, d=0):

Код:

10100000 00000001 00000000 00000000 00000000 (A0 01 00 00 00)

Изменился всего один бит инструкции! Между тем результат операции будет разительно отличаться: в первом случае в регистр EAX будут скопированы четыре (!) байта, начиная с адреса 1, тогда как во втором случае - в регистр AL будет скопирован лишь один байт по тому же адресу, остальные 3 байта регистра EAX останутся без изменений.

Архитектура IA-32 предоставляет очень богатый набор способов адресации памяти. Сейчас отметим лишь, что возможна еще и косвенная адресация, когда адрес операнда в памяти находится в регистре, а инструкция ссылается на соответствующий регистр. Для работы с такими случаями, а также для перемещения данных между регистрами используется так называемый байт способа адресации (ModR/M). Этот байт следует непосредственно за опкодом, который предполагает его использование, и содержит следующие поля:

Код:

2 бита MOD - 3 бита REG - 3 бита R/M

Байт ModR/M предполагает, что имеются два операнда, причем один из них всегда находится в регистре (код которого содержится в поле REG), а второй может находиться (в зависимости от значения поля MOD) либо тоже в регистре (при MOD = 11; при этом поле R/M содержит код регистра), либо в памяти (R/M="register or memory"). В последнем случае адрес памяти, по которому находится операнд, вычисляется следующим образом (см. табл.):

SIB означает, что после байта ModR/M следует еще один байт способа адресации (Scale-Index-Base - SIB), который мы рассматривать не будем. При MOD=00 нужный адрес памяти находится в соответствующем регистре, кроме R/M=101, когда 4 байта адреса следуют непосредственно после опкода и байта ModR/M (как в случае команды 101000dw). В ассемблере для указания того, что в регистре содержится адрес операнда, а не его значение, регистр заключают в квадратные скобки.

Если MOD=01, за байтом ModR/M следует байт, значение которого добавляется к значению соответствующего регистра и таким образом вычисляется адрес операнда. При MOD=10 за ModR/M следуют уже 4 байта; значение этого числа тоже суммируются со значением соответствующего регистра для вычисления адреса.

Присутствие байта ModR/M обычно требует также наличия битов d и w. Рассмотрим еще одну команду:

Код:

100010 d w

При d=0 данные перемещаются из регистра, закодированного в REG, в регистр или память, определяемые по R/M. При d=1 наоборот - из R/M в REG. Составим, например, инструкцию для копирования данных из EAX в EBX. Сначала "составим" байт ModR/M: оба операнда в регистрах, поэтому MOD=11; 1-й операнд в EAX - REG=000; 2-й операнд в EBX - R/M=011; итого - 11000011 (C3). Опкод: полные регистры - w=1; копирование от REG к R/M - d=0. Итоговая инструкция - 10001001 11000011 (89 C3).

Теперь фишка: 1-й операнд в EBX (REG=011), 2-й - в EAX (MOD=11, R/M=000), бит d установим (1). Итог: 10001011 11011000 (8B D8) - но эта инструкция делает абсолютно то же самое, что и предыдущая! На ассемблере обе инструкции записываются одинаково: MOV EBX, EAX. Аналогичные примеры можно привести с инструкциями (A1 78 56 34 12) и (8B 05 78 56 34 12), (89 D7) и (8B FA) и т.д. Проверьте! Да и сами вы теперь сможете составить кучу таких же. А что делают инструкции (88 E4) и (8A C9)?

Это характерная особенность работы с машинными кодами. Подобные этим трюки могут использоваться для создания защит и антиотладочных приемов. Между тем даже ассемблер генерирует для подобных команд лишь один вид кода, тем самым значительно вас обкрадывая, не говоря уже о компиляторах с языков высокого уровня.

Только не надо пугаться и думать, что при программировании в машинных кодах все время придется делать выбор из сотен возможных вариантов. На самом деле в Win32-программировании постоянно будут встречаться одни и те же инструкции, так что мы их помимо своей воли выучим наизусть. Хотя в этой статье оказалось много разнообразного материала, вы можете считать его одой свободе и богатству выбора, которую несут с собой машинные коды. В будущих статьях мы непременно сможем убедиться, насколько простым может быть программирование под Windows в машинных кодах, особенно если вы сумели уловить логику построения инструкций.

2005 © Roustem

2. Инструменты

Чтобы вводить двоичные значения в компьютер, необходим шестнадцатеричный редактор. Поскольку мы решили обходиться стандартными средствами, имеющимися в любой типичной поставке Windows, используем в качестве шестнадцатеричного редактора старый досовский отладчик debug. Рассмотрим лишь те возможности этого отладчика, которые нам понадобятся в работе.

Сначала имеет смысл создать отдельную папку для проводимых экспериментов, например, \exp. Теперь запустим командную строку DOS, перейдем в созданный каталог (cd \exp) и наберем: debug. Появляется черточка - приглашение отладчка; можно набирать команды. Сразу о том, как завершить работу debug: для этого служит команда q (quit).

Debug позволяет создавать и записывать на диск файлы, но у этого процесса есть некоторые особенности. Дело в том, что создаваемые файлы будут в старом досовском формате com. Для нас это означает, что при записи на диск отладчик использует данные, начиная со смещения 100h кодового сегмента (адрес которого содержится в регистре CS), это надо учитывать. Если наши данные будут начинаться со смещения 0, первые 256 (100h) байтов окажутся утерянными (для содержимого регистров CS и DS по умолчанию). Либо надо вручную изменить (увеличить на 10h) значение регистра DS.

Попробуем создать простейший файл. Запускаем debug. Для записи служит команда w (write); однако вначале должно быть определено имя файла с помощью команды n (name). В принципе, имя может быть любым досовским именем (в коротком формате 8.3), но расширение не может быть exe или hex. Лучше использовать расширение bin, а потом переименовать файл. Набираем:

Код:

n first.bin

Теперь необходимо указать размер создаваемого файла. Это значение должно быть в регистрах BX:CX, причем младшее слово содержится в CX, старшее слово - в BX (отладчик debug 16-разрядный, поэтому он не работает с 32-разрядными регистрами и смещениями). Для начала запишем лишь 1 байт; введем с помощью команды r (register) 1 в регистр CX (в BX по умолчанию содержится 0):

Код:

r cx
1

Таким способом можно изменять значения любых регистров. Собственно запись осуществляется командой w. Смотрим - в нашем каталоге должен появиться файл 'first.bin' размером в 1 байт.

Перейдем к формированию наших данных. Одна из полезных команд - f (fill), она позволяет заполнить участок памяти указанными данными. После f первым параметром идет смещение (начальный адрес) заполняемого блока, затем либо параметр l (length) и число, указывающее на длину заполняемого участка в байтах, либо смещение его конца. После этого - собственно данные, которыми будет заполняться данный участок. Причем данные могут быть как в виде 16-ричных чисел, так и в виде заключенных в апострофы или кавычки строк, причем их можно чередовать. Например, заполним первые 256 (100h) байт строкой "This is the filling string":

Код:

f 0 l 100 'This is the filling string'

Чтобы просмотреть содержимое памяти, служит команда d (dump). Как и в случае с командой f, первый параметр указывает смещение начала отображения данных (дампа), а за ним - либо l с указанием размера дампа, либо конечное смещение. Используем для разнообразия второй вариант (учтите, все используемые числа в debug - 16-ричные):

Код:

d 0 ff

Как видим, указанный участок заполнен повторяющейся строкой, которую мы указали в качестве параметра команды f. Разумеется, это лишь пример, а в реальности мы будем эту команду использовать для очистки (заполнения нулями) блоков памяти. Например, очистим первый килобайт (400h байт):

Код:

f 0 400 0

Если в команде d указать лишь один параметр, она по умолчанию отображает 80h байт, начиная с данного смещения. А если не указать и его, то отображаются очередные 80h байт с того места, на котором остановились в прошлый раз. Поэтому мы можем набрать:

Код:

d 0

Посмотрев первые 80h байт дампа, набираем d и смотрим следующую порцию и т.д.

Теперь проделаем эксперимент, демонстрирующий особенность сохранения файлов в debug. Создадим файл, первые 100h байт которого заполнены символами '0', вторые 100h байт - символами '1' и т.д. до, скажем, '9'. Дадим файлу имя 'first.txt' (или любое другое с расширением .txt), а размер его будет a00h (2,5 Кб).

Код:

n first.txt
r cx
a00
f 0 l 100 30
f 100 l 100 31

и т.д. до f 900 l 100 39. 16-ричные числа 30, 31, ... , 39 являются ASCII-кодами цифр 0-9. После этого набираем w и смотрим, что получилось.

Открываем 'first.txt' в Блокноте. Но что это? Файл начинается с единиц, а в конце какой-то мусор? Смотрим в debug'е: d 0 ff - все нормально, заполнено цифрами 0 (30h). Вот это и есть та особенность отладчика, о которой мы говорили в начале. В файл записываются данные начиная со смещения 100h относительно кодового сегмента.

Исправить эту ситуацию можно попытаться двумя способами. Рассмотрим еще одну команду отладчика: m (move). Она позволяет копировать данные из одной области памяти в другую. Первый параметр, как и ранее, является смещением начала участка памяти, который необходимо скопировать, второй - либо смещением конца копируемого участка, либо (при наличии буквы l) его длиной, третий параметр - смещение места назначения, куда надо скопировать данные. С помощью этой команды мы можем "передвинуть" весь наш блок данных так, чтобы он начинался со смещения 100h:

Код:

m 0 l a00 100

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

Второй способ - изменить значение регистра сегмента данных DS таким образом, чтобы он указывал на область со смещением 100h относительно начала кодового сегмента. Т.е. надо просто добавить к старому значению DS 10h. Допустим, в DS было значение 2020. Изменим его на 2030:

Код:

r ds
2030

Теперь затрем старые данные, скажем, числом ff:

Код:

f 0 l a00 ff

Запишем это в старый файл командой w и убедимся, что файл изменился. И повторим старую операцию:

Код:

f 0 l 100 30
f 100 l 100 31
...
f 900 l 100 39
w

Результат аналогичный ранее сделанному.

Команда e (enter) позволяет вводить данные по конкретным адресам. Первый параметр указывает начальный адрес, остальные рассматриваются как данные для ввода. Причем здесь тоже можно использовать как 16-ричные числа, так и символьные строки, чередуя их между собой произвольным образом.

В связи с данной командой рассмотрим особенность процессоров IA-32, о которой говорилось в прошлой статье. Речь идет об "обратном" представлении чисел в памяти; хотя по внимательном рассмотрении этого вопроса представление чисел в процессарах IA-32 как раз является естественным ("нормальным"), а "обратным" оказывается наша традиционная запись. Попробуем разобраться.

Мы читаем и записываем слева направо. Если записать порядковые номера, они будут увеличиваться тоже слева направо. Естественно таким же образом нумеровать объекты, скажем, байты памяти: 1, 2, 3, 4 и т.д. Значения возрастают слева направо. Теперь посмотрите на числа, у которых увеличиваются разряды: 1, 10, 100, 1000. Каждый новый разряд мы добавляем слева, т.е. возрастание числа получается справа налево - порядок, противоположный традиционному письму. Если сохранять в памяти текст, т.е. строку символов, при добавлении новых символов они будут помещаться "правее", т.е. по возрастающим адресам памяти (поскольку мы нумеруем их слева направо). А как быть, если увеличивается значение числа и оно перестает помещаться на старом месте? Скажем, вместо байта требуется уже слово (два байта)? Новый байт можно добавить "слева" (с меньшим адресом) или "справа" (с большим адресом). Поскольку адресом многобайтной конструкции по соглашению считают самый младший адрес, он может указывать либо на байт, в котором хранятся старшие разряды числа, либо на байт, в котором хранятся младшие разряды. Первый способ называется "big-endian", второй - "little-endian". Так вот, в процессорах IA-32 используется "little-endian", т.е. старшие разряды добавляются "справа" (по старшим адресам памяти) - порядок, обратный нашей записи чисел. Говорят, в свое время Фибоначчи, заимствуя цифры у арабов, не учел особенностей их письма: арабы пишут справа налево, в отличие от нас. И так же располагались разряды их цифр. Фибоначчи использовал тот же порядок, хотя европейцы писали в обратном направлении - вот где корень всех наших бед

.

Таким образом, если мы хотим разместить по адресу 10h число 12h, мы набираем:

Код:

e 10 12

Если же мы хотим разместить по этому же адресу число 1234h, два байта, его составляющих, нам придется вводить следующим образом:

Код:

e 10 34 12

А если по тому же адресу нужно записать число 12345678h, ввод будет таким:

Код:

e 10 78 56 34 12

Только в этом случае в результате исполнения инструкции копирования данных из памяти (по адресу 10h) в регистр EAX, которую мы рассматривали в прошлой статье, в регистре EAX окажется нужное нам значение 12345678h.

Как вы уже, очевидно, заметили, в 16-разрядной системе используется сегментная модель памяти. Это создает дополнительные проблемы; в частности, команды заполнения (f) и перемещения (m) не работают через границы сегментов. Поэтому, хотя debug в принципе позволяет сохранять файлы размером более одного 16-разрядного сегмента (64 Кб), при составлении таких файлов у нас могут возникнуть проблемы. Их можно решить другим путем - собирая в debug отдельные "модули", не превышающие 64 Кб, и соединяя их с помощью команды DOS copy.

Для доказательства такой возможности соберем простой текстовый файл размером в 1 Мб. Собирать будем из 16 модулей в 64 Кб, сохраненных средствами debug; каждый модуль будет заполнен единственным символом - 16-ричной цифрой, значение которой равно номеру модуля (для контроля).

Сначала настроим регистр DS (если он не был настроен ранее), увеличив его значение на 10h. В регистр CX должно быть значение 0, в BX - 1 (это соответствует размеру файла 10000h байт, или ровно 64 Кб):

Код:

r ds
<ввести значение на 10h большее прежнего>
r cx
0
r bx
1

Если параметр с буквой l в командах равен 0, длина участка памяти считается равной размеру полного сегмента, т.е. 64 Кб. Будем последовательно заполнять весь сегмент символом очередной 16-ричной цифры (от 0 (30h) до 9 (39h) и далее от A (41h) до F (46h)) и сохранять его под новым именем:

Код:

n 0.bin
f 0 l 0 30
w
n 1.bin
f 0 l 0 31
w
. . .
n 15.bin
f 0 l 0 46
w

В нашем каталоге должны появиться 16 файлов с расширением bin и размером 64 Кб каждый. Теперь выходим из debug (q) и набираем в командной строке:

Код:

copy /b 0.bin+1.bin+2.bin+3.bin+...+15.bin 16.txt

Естественно, вместо "..." здесь должны быть имена остальных файлов, соединенных знаком "+". Откроем итоговый файл 16.txt в WordPad (Блокнот для этой цели не годится - слишком большой файл) и убедимся, что он заполнен введенными нами символами и что в нем нет ничего лишнего.

Осталось рассмотреть лишь некоторые методы автоматизации нашей работы. Работать с debug, все время вводя данные в интерактивном режиме, может оказаться утомительным - удобнее использовать заранее подготовленные шаблоны, внося в них каждый раз небольшие изменения. Для этого воспользуемся еще одной возможностью ОС - перенаправлением ввода-вывода.

Все необходимые команды для debug записываются в текстовый файл, который затем подается на вход отладчика при его запуске следующим образом:

Код:

debug < batch.txt

Для испытания этого способа повторим тот же алгоритм, который мы использовали при создании файла "first.txt". В Блокноте создаем файл "batch.txt" со следующим содержимым:

Код:

n first.txt
r cx
a00
f 0 l 100 30
f 100 l 100 31
. . .
f 900 l 100 39
m 0 l a00 100
w
q

В конце файла надо не забыть поставить q - иначе мы останемся в отладчике. Результаты работы все еще выводятся на экран. Их можно записать в файл (иногда это бывает полезно), использовав второе перенаправление:

Код:

debug < batch.txt > batch.lst

Теперь в консольном окне сообщения не выводятся, зато в файле batch.lst оказались записанными введенные нами команды и ответы на них отладчика. Заметим, что таким способом мы не можем использовать команды, требующие анализа ответов отладчика. Например, мы не сможем воспользоваться изменением значения регистра DS, поскольку заранее (в общем случае) неизвестно его значение.

Наконец, рассмотрим еще одну команду - a (assemble). Эта команда позволяет войти в режим ассемблирования, т.е. ввода инструкций на ассемблере, которые debug автоматически преобразует в машинные коды. Однако делает это он в 16-разрядном режиме, что нам совершенно не подходит. Но мы можем воспользоваться в этом режиме директивой db, позволяющей вводить отдельные байты, как в команде e. Это может напомнить путешествие из Петербурга в Москву через Владивосток; однако, удобство этого метода в том, что отладчик будет автоматически подсчитывать смещение следующей вводимой инструкции (в нашем случае - байта), и можно не считать все самим.

Параметром команды a является адрес (смещение), с которого мы начинаем вводить инструкции. Чтобы выйти из режима ассемблирования, необходимо просто нажать 'Enter' еще раз (в тексте пакетного файла в этом месте должна быть пустая строка). Потренируемся в использовании этой команды с использованием инструкций в машинных кодах, которые мы составляли в прошлый раз (впрочем, ничто не мешает составить и новые). Сначала поработаем в интерактивном режиме:

Код:

a 100

В ответ слева появится что-то типа 2020:0100. Старшее слово (сегмент) нам неинтересно, а младшее (справа) как раз и является текущим смещением от начала сегмента. Набираем:

Код:

db b8 01 00 00 00

После нажатия 'Enter' появляется новое смещение - 105. К старому смещению автоматически прибавилась длина введенных нами данных. Вводим:

Код:

; конец инструкции

Смещение осталось тем же. Все содержимое строки после точки с запятой игнорируется. Очень удобно - можно использовать, как метки для соответствующих смещений. Продолжаем:

Код:

db b4 01
; конец второй инструкции
db "Some text"

Как видим, длина текстовых строк тоже подсчитывается автоматически и добавляется к смещению. Запишем все в файл, выйдя из режима ассемблирования (для этого просто нажимаем на 'Enter' еще раз):

Код:

<Enter>
n second.bin
r cx
10
w

Заметим, что длину введенных данных подсчитать теперь очень просто: отнимаем от конечного смещения (в данном случае 110h) начальное: 110-100=10h.

Но преимущества режима ассемблирования станут очевидными при работе с перенаправлениями. Создадим файл "second.txt" и наберем в нем те же данные (не забыв про пустую строку в соответствующем месте и команду q в конце). В командной строке DOS запишем:

Код:

debug < second.txt > second.lst

В данном случае нас особо интересует именно выходной файл - second.lst. Теперь все смещения записаны в файле. Это дает возможность при "первом проходе" (черновом) вводить приблизительные значения (здесь это могло бы быть, например, значение регистра CX). Выходной файл используется затем для получения точных значений смещений и подстановки их в исходный файл с командами для "второго прохода" (чистового).

Завершим знакомство с отладчиком способами загрузки созданных заранее шаблонов. Для загрузки файлов служит команда l (load). При этом имя файла должно быть уже указано командой n. Файл загружается по смещению 100h. Либо имя файла можно указать в качестве параметра при вызове отладчика:

Код:

debug first.txt

Произведя нужные изменения, файл можно сохранить под другим именем. При этом, если работа с debug ведется со смещениями, меньшими 100h, новое имя файла нужно вводить заранее, т.к. debug записывает имя в эту область, и данные могут оказаться испорчеными.

Для примера рассмотрим, как можно загрузить в качестве шаблона созданный ранее файл "first.txt" и сохранить его после сделанных изменений. Сначала создаем "автоматизирующий" файл с командами ("third.txt"):

Код:

n third.bin
m 100 l a00 0
f 100 l 100 ff
m 0 l a00 100
w
q

Теперь в командной строке набираем:

Код:

debug first.txt < third.txt > third.lst

В данном случае отладчик загружается вместе с файлом "first.txt", затем он исполняет команды, содержащиеся в "third.txt" (создавая в процессе работы файл "third.bin"), а отчет записывает в файл "third.lst".

Финальный штрих - полная автоматизация создания исполняемого файла. Для этого создается bat-файл, в котором записываются вызов самого debug, а также другие необходимые действия, например, составление одного большого файла из отдельных модулей с помощью команды copy или переименование файла с расширением bin в файл с расширением exe. Создадим в Блокноте файл "make.bat":

Код:

@echo off
debug < second.txt
ren second.bin second.exe

Теперь можно запустить этот файл на исполение (двойным щелчком по его имени в Проводнике или набрав имя в командной строке). Строка "@echo off" нужна для того, чтобы команды в bat-файле не выводились на экран. Однако, результат работы debug все равно будет отображаться на экране; чтобы его не было, можно использовать второе перенаправление - либо в файл, либо, если файл с результатами работы не нужен, сюда можно записать nul:

Код:

debug < second.txt > nul

Результатом работы будет файл second.exe. Кстати, можете попробовать запустить его - ничего страшного не произойдет, система просто сообщит, что это не настоящий исполняемый файл Windows. Отметим, что это простейший случай; на самом деле в bat-файле может быть записано множество вызовов debug с различными заранее подготовленными файлами для создания сразу нескольких модулей и последующего их объединения в один результирующий.

Каков же итог? Любой файл - будь то картинка, векторная или трехмерная графика, музыка, видео или исполняемый - это всего лишь сохраненный набор двоичных чисел. А итог таков, что мы умеем теперь создавать файлы практически любого размера и с любым содержанием. Единственное, что при этом надо - это изучить формат соответствующего типа файла. Этим мы и займемся в следующей статье применительно к исполняемым файлам Windows.

2005 © Roustem

Модерирует : ShIvADeSt
Версия для печати • Подписаться • Добавить в закладки