Крис Касперски. Главы из неопубликованной книги «Образ мышления ― HIEW»

взято здесь

«Ничто не может возникнуть из ничего»
Ф. Херберт. «Дюна»​

ПАРА СЛОВ ПО ПОВОДУ:

Сказанное ниже является только моим личным мнением и впечатлением от hiew 6.03. Местами оно идет вразрез с мнением автора hiew. После попытки настоять на исправлении ряда моментов я пришел к выводу, что легче написать собственный *view с нуля, чем заниматься перепалкой с автором.
Конкретно, он наотрез отказался поддержать хотя бы интерпретируемый язык скриптов или предоставить мне API (компилятор я мог бы и сам написать), добавить поддержку двоичного ввода в калькулятор, поддержать редактирование заголовков PE\LE\LX файлов.
HIEW это замечательный и необыкновенно мощный инструмент, предназначенный для анализа и редактирования программ непосредственно в исполняемом коде.
Десятилетиями для этой цели традиционно использовались hex-редакторы, которые концептуально мало отличались друг от друга. Менялся интерфейс и предоставляемый сервис ― только и всего. HexWorkShop под Windows и hexed под Агат-9 (может кто помнит такую машину) имеют больше сходств, чем различий. Евгений Сусликов, был первым кто догадался прикрутить в шестнадцатеричный редактор дизассемблер. Это породило продукт с совершенно новыми качествами. Вы пробовали когда-нибудь загружать в IDA или SOURCER исполняемый файл мегабайт эдак под двадцать? Десятки часов жужжания винта и сотни метров свопа явление хорошо знакомое каждому хакеру. А сам дизассемблер? Сколько дискет потребуется, что бы его разместить, если предстоит работа «на выезде»?
hiew лишен всех этих недостатков. Шустрый, компактный, проворный, в умелых руках он способен творить чудеса, при этом ограничиваясь чисто «формальными» требованиями к аппаратуре.
По прошествии нескольких лет, возможности этой утилиты заметно возросли. Конкретно, скачивая версию 6.03 (последнюю на момент написания данного руководства) вы приобретаете в одном флаконе:

• Шестнадцатеричный редактор файлов неограниченной длинны
• Уникальное средство поиска ассемблерных команд по маске
• Встроенный ассемблер (Pentiun Pro)
• Встроенный дизассемблер (Pentiun Pro)
• Интерпретируемая крип-система (Virtual CPU)

Иными словами готовый инструментарий на все случаи жизни. Не хватает только интерпретируемого языка, и интеграции с отладчиками. Впрочем, два последних пункта сейчас обсуждаются с автором и очень возможно, что следующая версия будет поддерживать встроенный язык.
Перечисленные возможности позволяют полностью отказаться от остальных инструментов и проводить анализ программ, не используя ничего кроме hiew. При этом задача взломщика не намного усложнится если даже не сказать наоборот. HIEW относится к ИНТЕРАКТИВНЫМ дизассемблерам, и его мощь в некотором отношении сравнима лишь с мощью IDA.
То есть процесс дизассемблирования тесно связан с пользователем. Последний сам должен определить, где код, а где данные, как интерпретируется та или иная инструкция. Последнее особенно актуально с самомодифицирующимся и шифрованным кодом. В книге «Образ мышления ― HIEW» это будет показано на конкретных примерах, а пока Вам ничего не остается, кроме как поверить мне на слово.
Заметим, что когда IDA или Sourcer дизассемблируют весь файл целиком, что требует длительного времени на анализ, hiew-же показывает за раз только небольшой фрагмент размером с экран. Конечно, если требуется получить хорошо документированный листинг программы, то это покажется крайне неудачным вариантом, однако же в работе хакера последнее обычно и не требуется. Любопытно, что hiew незаменим при анализе программ в в пару килобайт (когда расточительно запускать ради них IDA), так и в пару мегабайт (когда IDA последние дольше будет дизассемблировать, чем хакер сносить защиту с помощью hiew).
Кроме того, HIEW позволяет с легкостью и комфортом прогуляться по LE/PE/NE/LX/ NLM файлам, в исследовании формата и перекраивании, к примеру, таблиц импорта под свой вкус. При этом вообще hiew является единственным шестнадцатеричным редактором поддерживающим таблицы импорта вышеуказанных файлов:
Взгляните на следующий фрагмент:

.00401145:	83EC18	sub esp,018 ;""
.00401148:	57	push edi
.00401149:	33FF	xor edi,edi
.0040114B:	57	push edi
.0040114C:	FF1500204000	call GetCommandLineA ;KERNEL32.dll
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.00401152:	50	push eax
.00401153:	57	push edi
.00401154:	57	push edi
.00401155:	FF1504204000	call GetModuleHandleA;KERNEL32.dll
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.0040115B:	50	push eax

И сравните его, например с qview:

00001145:	83EC18	sub esp,00000018
00001148:	57	push edi
00001149:	33FF	xor edi,edi
0000114B:	57	push edi
0000114C:	FF1500204000	call dword ptr [00402000]
		^^^^^^^^^^^^^^^^^^^^^^^^
00001152:	50	push eax
00001153:	57	push edi
00001154:	57	push edi
00001155:	FF1504204000	call dword ptr [00402004]
		^^^^^^^^^^^^^^^^^^^^^^^^^

Не правда ли потрясающие возможности для шестнадцатеричного редактора? HIEW можно считать полноценным win32\DOS\OS/2 дизассемблером, поддерживающим не только 32-битные инструкции, но и форматы исполняемых файлов популярных операционных систем.
Заметим, что не так много популярных дизассемблеров поддерживают LE-формат. Но hiew ― поддерживает, оставаясь моим незаменимым помощником при путешествиях в дебрях VxD. Использовать для этой цели IDA не всегда удобно ― часто заранее точно неизвестно в какой файл разработчик поместил защитный механизм и требуется окинуть беглым взглядом далеко не один драйвер виртуально устройства. IDA тратит больше времени на загрузку, чем я на анализ. Самое обидно, что анализ-то в большинстве случаев и не требуется, потому что сразу видим, что тут, например, защита и не ночевала:

Код (Text):

1.  .00000007: B800000000                   mov       eax,000000000 ;
2.  .0000000C: B94A000000                   mov       ecx,00000004A ;
3.  .00000011: C7400400000000               mov       d,[eax][00004],000000000
4.  .00000018: CD2014000A00                 VxDcall   VDD.Get_DISPLAYINFO
5.                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.  .0000001E: 66F705020000000008           test      w,[000000002],00800 ;
7.  .00000027: 0F85790D0000                 jne      .000000DA6   -------- (1)

HIEW позволит сэкономить немало драгоценного времени хакера, которое можно потратить на нечто более полезное, чем утомительное ожидание окончания загрузки файла.
Сказанное не должно восприниматься как наезд или повод для отказа от IDA. Отнюдь. Это уникальный в своей категории инструмент, аналогов которому не существует и в обозримом будущем и не предвидится. Но IDA это все же тяжелое стратегическое оружие, а общение c hiew-ом больше напоминает работу разведчика.
Бытует мнение, что анализ программ непосредственно в hiew-е более сложен, чем в отладчике или полноценном дизассемблере. Некоторые это считают «высшим пилотажем». На мой взгляд это не более, чем распространенное заблуждение. За исключением, может быть IDA, hiew обеспечивает весь сервис, предоставляемый другими «полноценными» дизассемблерами, при этом обладая и присущими IDA возможностями ― например, интерактивностью. Когда SOURCER может быть легко сбит с толку хитрым приемом разработчика защиты, с hiew-ом такого не произойдет, поскольку он работает в тесной связке с человеком. Нетрудно обмануть машину, но человек человека перехитрить не может (ну разве что ввести во временное заблуждение).
К сожалению автор hiew-а не позаботился о некоторых мелочах, которые делают жизнь хакера более приятной и экономят его время. Например, ближайший конкурент qview позволяет создавать в файлах комментарии, а hiew ― нет. Впрочем, последнее не вызывает особых проблем и надеюсь будет реализовано в последующих версиях.
Не будем больше заниматься бессмысленным сравнением конкурирующих утилит, а перейдем к описанию пакета поставки. В версию 6.03 входят следующие файлы:

FILES.LST	Файл описания (увы, плохо совместим с DN и др. оболочками)
HIEW.EXE	Собственно сам HIEW (одновременно для DOS и OS\2)
HIEW.INI	Конфигурационный файл
HIEW.HLP	Файл помощи
HIEW.ORD	Символьная информация ординалов распространенных файлов
HIEW.VMM	VMMcall/VxDcall для LE файлов
HIEW.XLT	Файл перекодировок (Windows-1251\KOI-8R)
HIEWR.nnn	Краткое описание на русском языке
HIEWE.nnn	Краткое описание на английском языке
NEDUMP.EXE	Утилита для исследования NE-файлов (не актуальна сегодня)
LXDUMP.EXE	Утилита для исследования LX\LE-файлов
DEXEM.EXE	Утилита для работы с Dual-EXE (NE/LE/LX/PE) файлами
SEN.ASC	Публичный PGP ключ автора

HIEW.exe очень тяжел. Целых 284,855 байт, что отнимает много места, например, на спасательной дискете (а он у меня всегда на ней. Мало ли с какими вирусами воевать придется). На самом деле это DUAL-exe файл, т.е. два файла для MS-DOS и OS\2 одновременно. Это оригинально, но слишком расточительно. (заметим, что такие программы могут существовать и под windows).
Первое, что необходимо сделать ― «разрезать» файл на две половинки и взять «родной» для вашей операционной системы. Для этого предназначена утилита dexem.exe
Подробнее она будет рассмотрена ниже, а пока просто запустим ее следующим образом dexem.exe /S hiew.exe При этом DUAL-exe будет расщеплена на два файла hiew.mz (MS-DOS) и hiew.ne (OS\2) по 102 и 183 килобайта соответственно. Отметим, что 102 много меньше 285, и учитывая, что OS\2 в жизни многих пользователей может быть никогда и не встретится, то хорошим решением будет удалить оригинальный hiew.exe и переименовать в последний hiew.mz
Не зависимо от того сделали вы это или нет, попробуем запустить hiew.exe без параметров. Кто знаком с ранними версиями hiew помнит, что при этом программа просто не запускалась, ссылаясь на отсутствие файла в командной строке.
В версии 6.03 поддерживает встроенную систему навигации по файлам и каталогам, которая активируется всякий раз, когда hiew запускается без явного указания файла в командной строке. Логично было бы предположить, что то же произойдет при задании маски (например hiew.exe *.exe). Но автор мыслил иначе. При этом hiew просто найдет первый попавшийся файл, а если таковых не окажется, то с грустью сообщит

File(s) not found

и закончит работу. Печально, однако.
Но вернемся к навигатору.

Вообще навигатор очень напоминает Norton Commander и общение с ним проблем вызвать не должно. На всякий случай я все же опишу назначение клавиш управления:

Alt+F1_(Drive)	смена текущего дисковода. Замечу что hiew немного некорректно обрабатывает список существующих устройств. Так, например, у меня он обнаружил 'B', хотя тут 'B' отродясь не было. Попытка чтения с него привела к переадресации на 'A', что прошло не без возмущений со стороны WINDOWS
F1_(Help)	Помощь
F2_(Hidden)	отображение скрытых и системных файлов. Кнопка действует как триггер
F3_(Name)	сортировка по именам файлов
F4_(Exten)	сортировки по расширениям
F5_(Time)	сортировка по времени создания
F6_(Size)	сортировка по размерам
F7_(Unsort)	располагать файлы в том порядке, в каком их находит FindNextFile
F8_(Revers)	обратить условие сортировки. Т.е. по умолчанию (за исключением даты) принята сортировка по возрастанию параметра. Реверс приводит к сортировки по убыванию. Действует как триггер
F10_(Filter)	задать маску отображаемых файлов. К сожалению не позволяет задавать более одной маски, что может вызвать неудобства. Маленький баг ― если удалить маску, то hiew ее не восстановит по умолчанию. Для этого необходимо будет задать явно «*.*», что лично мне например, просто неудобно

При этом существует возможность быстрого поиска необходимого файла. HIEW вобрал в себя все лучшие решения от DN и NC и реализовал очень нехилые для простого встроенного менеджера возможности.
Нажатие любой символьной клавиши приводит к появлению консольной строки, в которой можно ввести имя файла. (при этом курсор будет перемещаться по списку синхронно с вводом).
Есть и чисто UNIX-овая возможность дополнения введенного имени до полного, при условии, что последнее однозначно определяет файл. Возможно, что это определение покажется витиеватым, поэтому покажу на примере. Допустим, нам нужно найти файл crackme.exe Если в текущей директории на 'c' есть только один файл, то логично, что он может однозначно быть определен заданием всего одной буквы. Вводим c и нажимаем tab. Hiew, догадываясь, что мы хотим открыть crackme.exe выводит его имя (между прочим без расширения). А что будет если у нас есть два файла crackme1 и crackme2?
Тогда hiew сердито пискнув, напишет только 'crackme' и остановится, ожидая уточнения ― какой именно из двух файлов нам требуется открыть.
Кому-то это может показаться не удобным, тогда можно воспользоваться '*' ― непосредственным аналогом Ctrl+Enter в DN и NC ― последовательному перебору подходящих файлов.
Имеется и очень ценная недокументированная возможность задания списка в квадратных скобках. Например, [cr,h]ack.exe найдет все crack и hack. Если запятую опустить, то hiew будет интерпретировать стоку как [c,r,h]. Т.е. *.[ch] он найдет все файлы c,cpp,h и др. Это очень полезная и вообще уникальная для платформы MS-DOS возможность, которая не существует ни в одной другой аналогичной программе.
Жалко, конечно, что эти возможности большей частью остаются невостребованными ― hiew все же не файловая оболочка и чаще всего редактируемый файл непосредственно задается в строке, хотя бы по чистой привычке, оставшейся от старых версий. (я вот тут думаю, если бы автор предусмотрел еще и запуск из Файлового Навигатора, то многие, включая в первую очередь меня, использовали бы его как оболочку, которая особенно была бы удобной на «спасительных» дискетах).
Если hiew запушен с именем несуществующего файла, то он предложит создать его. Альтернативным вариантом является клавиша Ins в Навигаторе. Последняя возможность просто незаменима, когда новые файлы приходится создавать и открывать непосредственно во время работы. К примеру, может потребоваться сделать некоторые заметки по ходу работы, скопировать фрагмент в новый файл и при этом тут же открыть его и, скажем, расшифровать. (отметим, что навигатор можно вызвать в любой момент работы клавишей F9).
Ctrl+\ обеспечивает быстрый переход в корневую директорию текущего диска, а F10 в материнскую директорию (ту, из которой был запущен hiew). При этом существует полезная возможность быстрого переключения между четырьмя произвольно выбранными директориями. Для этого существуют клавиши Ctrl+F1, Ctrl+F3, Ctrl+F5, Ctrl+F7 которые запоминают текущую директорию и Ctrl+F2, Ctrl+F4, Ctrl+F6, Ctrl+F8 которые соответственно переходят в записанную. При этом есть возможность сохранения текущего состояния в файл и его последующего использования во всех сеансах. Впрочем, последнее реализовано не самым лучшим образом. Нет никакой возможности сохранить состояние непосредственно из навигатора, поэтому приходится открывать файл только для того, что бы получить доступ к клавише Ctrl+F10 ― 'SaveSatus'. К последней мы еще вернемся, а пока отметим, такую приятную особенность, как ведение истории просматриваемых файлов (F9)

При этом кроме собственно имен сохранятся текущий режим и позиция курсора (что особенно приятно). Последнее позволяет использовать hiew для чтения больших текстовых файлов (электронных книг, документации). При этом никогда не придется помнить на каком месте вы в последний раз находились перед выходом. (Впрочем, что бы быть до конца честными отметим, что эта возможность присуща сегодня практически всем современным вьюверам ― qview by AGC, UniversalViewer и MessageViewer by KPNC да и многим другим). Так же позволю себе отметить, что в этом UniversalViewer обогнал других. Тогда как hiew и qview привязываются к имени файла, UV ― к хеш сумме заголовка и окрестностей текущей позиции курсора. Имя файла при этом игнорируется. Последнее вызывает меньше конфликтов, хотя немного медленнее работает. Будем надеяться, что SEN в ближайших версиях реализует нечто похожее.
Перейдем теперь к рассмотрению командной стоки. Большинство ею пользуется все же гораздо чаще, чем непривычным навигатором.
В командной строке можно задавать более одно файла, но при этом будет открыт только первый из них, а остальные доступны по Ctrl+F9, что, впрочем, удобно, т.к. уменьшает время загрузки. Если спецификация файла не будет полной, то hiew найдет все подходящие файлы и добавит их имена в список. Это неудобно и нелогично. Неполная спецификация должна приводить к вызову Навигатора (во всяком случае по моему личному мнению).
Параметр /SAV задает имя SAV-файла, который автоматически будет загружен. По умолчанию принимается hiew.sav, но последнее может быть изменено в hiew.ini:
; StartUp
Savefile = "hiew.sav"
sav-файл полностью сохраняет текущее состояние hiew-а, включая текущую позицию, все закладки и т.д. Обычно чтобы воспользоваться sav ― файлом, нужно запустить hiew без параметров. Заметим, что 'hiew.exe MyFile.exe' не приведет к должному результату. Неудобно, конечно, но приходится мирится. А что же остается делать ― хозяин (SEN) ― барин.
Интересная особенность ― конфигурационный файл можно так же указывать в командной строке после ключа /INI. Это особенно удобно для «корпоративного» использования hiew сразу несколькими людьми. Каждому ― настройки на свой вкус.
Если же требуется показать содержимое вложенный директорий, то можно использовать ключ /S с указанием пути и маски. При этом

hiew /s C:\*.*

с большой вероятностью после продолжительного шуршания диском завершит свою работу с сообщением:

No free memory

Это будет зависеть от количества имеющихся у вас на диске файлов. Если же их относительно немного, то есть шанс, что hiew запустится и можно будет выбрать любой понравившийся файл, нажав Ctrl+F9.
Долгие размышления мне так и не позволили придумать такую ситуацию, в которой данная возможность была бы не заменимой. Ведь всегда же есть под рукой встроенный файловый Навигатор!
После выбора файла hiew автоматически показывает его в текстовом режиме. Не слишком удачный выбор для хакера, поэтому последние обычно первым делом редактируют следующую строку hiew.ini
StartMode = Text ; Text | Hex | Code
Впрочем, если hiew планируется и для просмотра текстовых сообщений, то ничего трогать не надо. Жалко, однако, что нет функции «автодетект», тем более, что реализовать последнюю совсем не трудно.

Вообще же строка статуса может меняться в зависимости от режима, но это не должно вызвать каких-то проблем в понимании. Рассмотри подробнее некоторые элементы:
Левосторонний лифт может показаться непривычным и действительно не очень удобен. Поэтому автор предусмотрел возможность настроить последний по вкусу пользователя, а то и вовсе отключить его. Для этого необходимо отредактировать hiew.ini Если комментариев в файле окажется недостаточно, то обратитесь к главе «КОНФИГУРИРОВАНИЕ HIEW» настоящего руководства.
Направление поиска (прямое или обратное) задается клавшей Alt+ 7 в любой момент или непосредственно во время вызова окна поиска клавишей F2. При этом индикатор направления будет обновлен только после завершения поиска. Не нравится мне последнее. Не плохо бы перенести управление с F2 на ALt+F7 и при этом обновлять индикатор. Но не будем строги к автору - эта возможность появилась только в версии 6.03 и, конечно, до конца еще не отлажена.
Состояние файла может быть следующим:

(R)ead	открыт по чтению
(W)rite	открыт по записи
(U)pdate	изменен

При этом последний режим обрабатывается некорректно. В независимости от того был ли изменен хотя бы один байт, при каждом сбросе буферов редактора (F9) на диск (включая пустые!) всегда выставляется флаг изменения. Впрочем, это не баг, а фича и маловероятно, что бы она была исправлена в ближайших версиях.
Первый же вызов редактора (F3) приводит к автоматическому переоткрытию файла в режиме полного доступа (чтения и записи). Этот режим сохраняется и после выхода из редактора. Т.е. автоматического переоткрытия «Только на чтение» не происходит. А жаль. Индикация просто теряет смысл.
Hiew автоматически распознает следующие типы файлов DOS EXE, NE, PE, LE, LX, NLM но при этом отображает в строке статуса только пять последних из них. DOS-EXE hiew строго говоря не поддерживает (ну за исключением заголовка). Да, собственно, там и поддерживать особо нечего. Можно, конечно, правильно настроить регистр DS, но это было бы слишком для шестнадцатеричного редактора ― все же hiew изначально ну никак не планировался как дизассемблер. Впрочем, если будет встроенный язык (а он все равно будет) ― эти вопросы могут решаться пользователями на месте не дожидаясь новой версии. То же относится и к нестандартным бинарным файлам, например, разным BIOS-ам или дампам памяти. Для всего этого SEN написал замечательную утилиту StructLook, версия 4.20 которой выложена на ftp автора (ftp.kemsc.ru/pub/sen). Она содержит интерпретируемый препроцессор и очень удобна при «низкоуровневой» работе с различными форматами файлов. Но это совсем другая история.
Режим 16/32 определяется автоматически для поддерживаемых типов файлов. Это отличает его от qview, где режимы приходится переключать вручную, в противном же случае код дизассемблируется неправильно, что может приводить к печальным результатам. В режиме 'text', где понятие 16\32 разрядного кода как таково отсутствует это поле выражает номер самой левой отображаемой колонки, считая с нуля.
Очень неплохо продумана работа с закладками. Впрочем, удобно еще не значит привычно. Фирма Borlan установила стандарт де-факто: Ctrk-K-n запомнить состояние, Atl-Q-n восстановить его. Такая точка зрения не была поддержана SEN и он задействовал совсем другие «горячие» клавиши. Grey + запомнить текущее состояние. Этот факт мгновенно отражается в индикаторе. Изображение '-' изменяется на порядковый номер закладки (считая с единицы?!). При этом hiew может запомнить до восьми закладок. Большего обычно и не требуется.
Восстановить текущую закладку (которая индикатор отмечает '') можно нажав Gray -. Выбрать любую другую закладку поможет Alt+1-8. При этом последняя автоматически помечается как текущая. Если ее потребуется удалить, то можно нажать Alt+-. А Alt+0 ― удаляет сразу все закладки без предупреждения. Так что будьте осторожны с этой комбинацией!
В режиме редактора Editor закладки к сожалению становится недоступны по причине того, что последний ограничен всего одним окном. Удивительно, но этот недостаток присущ лишь hiew-у, а конкуренты давно реализовали это достойным образом. Самое интересное, что мне непонятные какие затруднения может испытывать автор с последним... Тем более, что это действительно жесткое ограничение, которое особенно дает о себе знать при расшифровке даже небольших файлов. Поэтому все больше и больше людей склоняются к мысли, что эту операцию лучше делать в qview, где нет таких ограничений. Остается только надеяться, что автор под мощным натиском общественного движения (ау! хакеры!) хотя бы через несколько версий реализует то, что конкуренты имели от рождения.
Длина файла отображается исключительно в неродном для хакеров десятичном исчислении. В купе с шестнадцатеричном смещением это особенно неприятно. Неплохой идеей думается мне был бы переход полностью на шестнадцатеричный режим в decode режиме и соответственно ― десятичный в текстовом. При этом было полезно отделять точкой каждые три знака, что улучшает читабельность больших чисел. Так что поле работы автору в последующих версиях еще есть, а это значит, что они будут выходить, выходить и еще раз выходить (правда при том условии, если SEN-у все это не надоест и он не забросит свое творение в самый пыльный угол винчестера, как это произошло с ДеГлюкером, Cup-ом, InSight-ом... да, собственно долго можно перечислять-то. Я как-то писал в одной своей утилите, что пожалев сейчас 1$ через некоторое время можно потерять в сотни раз больше из-за отсутствия утилиты, которая не была написана именно по причине экономии этого самого доллара. Увы, российские пользователи привыкли, что лучшие программисты страны должны работать «просто так» для их собственного удовольствия)

 

АССЕМБЛЕР

«Убийство острием лишено артистизма,
Но пусть тебя это не останавливает, если плоть,
раскрываясь, сама себя предлагает».
Ф.Херберт «Дюна»​

Перейдем к непосредственному описанию возможностей hiew-а. Я долго колустался между «руководством по ключам» между «описанием возможностей». В конце-концов выбор остался за последним. По моему глубокому убеждению описание на уровне клавиатуры, не нужно тем пользователям, которые читают это руководство. HIEW все же хакерский продукт. «А зачем хакеру хелп?» ― улыбается Сусликов. Но вот возможности, приемы работы и маленькие секреты будут прочитаны с большим удовольствием. И может быть тогда начинающие прекратят задавать глупые вопросы «ну вот я знаю какие байтики подправить, а в hiew-е их никак найти не могу»,
Встроенный ассемблер может быть полезен для многих вещей. Так, например, небольшие файлы удобно набивать сразу в hiew-е, а не пользоваться MASM\TASM-ом, которые на порядок медленнее работают. При этом последние не понимают многих извратов, так например, когда мне потребовалось для хитрой защиты ассемблироваться смесь шестнадцати и тридцати-двух разрядного кода со множеством команд Pentuim Pro. никто кроме hiew-а и моих собственных ручек не смог этого сделать.
Кроме того, все команды сразу показываются и в hex-кодах, а не после редактирования\ ассемблирования\ линковки\дизассемблирвоания, (при работе со стандартными средствами), что открывает свободу для экспериментирования и страхует от ошибок. Так, например, тот же TASM частенько даже при задании директивы USE32 почему-то вставляет в нужных местах ненужные префиксы или (что не лучше) опускает с целью оптимизации расставленные мной. Хотите пример? Попробуйте указать префикс DS для данных. TASM его проигнорирует (и разве, что у виска пальцем не покрутит). А теперь представим, что в самомодифицирующеся коде я пытаюсь менять префикс, которой был опущен.
Так же незаменим встроенный ассемблер, если в ломаемой программе нужно не просто поменять 7x на EB, а дописать десяток-другой строк кода (а такое случается достаточно часто).
К сожалению встроенный ассемблер содержит много ограничений, о которых будет рассказано ниже. Прежде всего самое обидное, что в этом режиме hiew еще не поддерживает локальных смещений и все вычисления адресов приходится проводить вручную. К моему удивлению не все знают как последнее делается. В самом деле все очень просто, достаточно знать формат редактируемого файла.
Покажем на примере, наверное самого распространенного PE-формата файлов, поддерживаемых платформой Win32 (это все же руководство по hiew, а не по взлому). Для этого сначала рассмотрим, как происходит загрузка PE файлов. MicroSoft неплохо оптимизировала этот процесс и PE целиком проецируются в память, включая и DOS-секцию. При этом один селектор выделяется для кода и данных. А это означает, что перевод глобальных в локальные смещения осуществляется тривиальным добавлением адреса загрузки, который можно узнать из заголовка PE файла. Поскольку hiew отображает последний в удобно читаемом виде, то наша задача упрощается еще больше ― достаточно заглянуть в поле Image base. В большинстве случаев там содержатся круглые значения, например 400000h, 10000h. Не сложно выполнить все вычисления и в уме, однако, к чему напрягаться? Я так и не нашел в песках истории с какой версии hiew поддерживает базирование, но это нам не помешает им с успехом воспользоваться. Переймем в начало файла и нажмем Ctrl-F5, после чего введем значение Image base (в моем случае 400000). Посмотрим что получилось;

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

Как мы можем с удовлетворением отметить, базирование решило проблему и можно даже не пинать автора исправить этот недостаток (хотя с его стороны это все же непростительный баг).
Очень удобно, что hiew при ассемблировании не пытается оптимизировать то что его не просят. Например, если вы укажите адресацию через DS. то перед командной появится соответствующий префикс 3Eh. Сравните:

Код (Text):

1.  00000000: 3EA16606                     mov       ax,ds:[00666]
2.            ^^
3.  00000004: A16606                       mov       ax,[00666]

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

Код (Text):

1.  00000007: 83C266                       add       dx,066 ;"f"
2.  0000000A: 81C26600                     add       dx,00066 ;" f"

При этом hiew всегда выбирает первый из них (т.е. пытается оптимизировать код). Последние восторга у хакеров не вызывает, ибо часто не соответствует ожидаемому результату.
Диаметрально противоположна ситуация при генерации переходов. По умолчанию hiew всегда генерирует близкий (near) переход 0E9h. Если необходимо задать близкий переход, то заставить hiew это сделать поможет команда jmps (jmp short действует аналогично). Позволю себе малость покритиковать автора и заметить что чаще всего кракеры заменяют условный переход на безусловный. При этом jmp near откровенно портит код. Обидно, однако.
Продолжая критику заметим, что ассемблер так же не понимает ни ординалов ни символьных имен, что совсем ― совсем не радует. Очень хотелось бы в следующих версиях получить полноценную поддержку перечисленных выше форматов.
В остальном же ассемблер ведет себя корректно и безглючно. При этом имеет встроенный калькулятор. Т.е. он прекрасно переваривает конструкции типа mov ax,[66h+11h] и даже mov ax,[-77h]. Последнее правда без учета режима. (еще один баг ― в копилку!) Отрицательные числа адреса всегда дополняются до слова. При этом в 32-разрядном режиме забавно выглядит попытка ассемблировать 'jmp -1'

Код (Text):

1.  00000003: E9F7FFFFFF                   jmp
2.                                              ^^^^^^

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

Код (Text):

1.   00000000: E9FAFFFFFF                   jmp -1
2.   00000005: 90                           nop
3.   00000006: 90                           nop

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

Код (Text):

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

Что, заметим ну никак не очевидно и является довольно любопытным приемом. Очевидно, не всем приходит в голову что jmp может прыгать в границах своего операнда. Хотя вообще ассемблирование отрицательных переходов в hiew это один большой баг, или фича. Во всяком случае это не работает так, как это ожидается.
Впрочем, это все мелочи и в ближайших версиях обоих продуктов будут исправлены.
Еще одним недостатком приходящим на ум является упорное нежелание hiew-a 'переваривать' директиву <ptr>, поэтому выражение

Код (ASM):

1.      mov Word ptr CS: [77h],66h

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

Код (ASM):

1.      mov Word CS:[77h],66h

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

Код (Text):

1.  ╒= Pentium(R) Pro Assembler =====================================╕
2.  ¦ mov       w,[0077],0022--------------------------------------- ¦
3.  ╘================================================================╛

Все числа считаются шестнадцатеричными по умолчанию, но никто не будет против буковки 'h'. А вот с 'x' анализатор не знает что делать и незамедлительно ругается. Последнее выглядит особенно странно на фоне калькулятора, который такую нотацию как раз-таки понимает, но не переваривает в свою очередь 'h'.
Чем больше я изучаю hiew, тем больше у меня складывается впечатление, что его писали два разных человека. Впрочем, последнее все же больше шутка, чем правда. Однако, не мешало бы попинать автора, что бы привести анализатор в порядок, а то работать порой бывает весьма дискомфортно.
Анализатор ошибок на редкость упрощен, однако это не должно вызывать каких-то проблем, предполагая, что hiew все же рассчитан на тех людей, чей второй язык (после родного) ― ассемблер и достаточно лишь намека что бы понять почему «оно» не ассемблируется.

ДИЗАССЕМБЛЕР

Дизассемблер в hiew великая вещь. Фактически это основной режим работы хакера. Не то что бы некоторые ленились дизассемблировать в уме hex-коды, (что частенько приходится при работе со встроенным просмотрщиком в DN скажем), но ассемблерный листинг все же привычнее глазу и кроме того имеет множество дополнительных возможностей (таких как поиск команд ассемблера по маске) которые заметно ускоряют анализ программ.
К сожалению (и признаться еще большему моему удивлению) автор не считает hiew дизассемблером и не хочет улучшать некоторые моменты чисто из идеологических соображений. Ну что же, будем ждать поддержки языка, где все это все возможно будет делать на лету, не обращаясь за помощью к автору. И всякому на свой вкус. Беда в том, что раскачать автора на встроенный язык или хотя бы задокументированный API (язык-то написать нетрудно) пока никак не получается.
Ну что же, как говориться хозяин ― барин, тем более, что hiew пока пишется лишь для удовольствии последнего и исходя из его же этических соображений. Вот когда автор будет получать за свою работу живую деньгу, тогда и исполнения желаний ждать можно будет, а пока остается только надеяться или садиться и писать собственный Xview. Последнее, кстати, многие активно делают и я не исключение. Впрочем, мой UniversalViever находится в весьма заброшенном состоянии, но если когда-то будет закончен, то... появится еще один конкурент на рынке hex-редакторов. К слову сказать UV изначально рассчитан на мульти-процессорную поддержку и будет очень удобен при анализе эмуляторов виртуальных процессоров.
Но это когда еще будет (и будет ли вообще), а hiew уже есть и поддерживает инструкции вплоть по Pentium Pro. А точнее P6-kernel, которое используется не только в том числе и в Celeron-ах.
Типичный вид дизассемблировано текста следующий:

Код (Text):

1.  .00401207: 50                           push      eax
2.  .00401208: 52                           push      edx
3.  .00401209: E8D2FEFFFF                   call     .0004010E0   -------- (1)
4.  .0040120E: 83C404                       add       esp,004 ;""
5.  .00401211: 50                           push      eax
6.  .00401212: E8A9FEFFFF                   call     .0004010C0   -------- (2)
7.  .00401217: 83C408                       add       esp,008 ;""
8.  .0040121A: 663DF801                     cmp       ax,001F8 ;"°"
9.  .0040121E: 7404                         je       .000401224   -------- (3)
10.  .00401220: 6A03                         push      003
11.  .00401222: EB02                         jmps     .000401226   -------- (4)
12.  .00401224: 6A04                         push      004

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

Код (Text):

1.  .004012B9: 6840314000                   push      000403140 ;" @1@"
2.  .004012BE: 6844314000                   push      000403144 ;" @1D"
3.  .004012C3: FF74240C                     push      d,[esp][0000C]
4.  .004012C7: E834010000                   call     .000401400   -------- (2)

hiew не распознал смещения 403140h и 403144h. Конечно, можно перейти по ним вручную (F5), но это не очень приятно. Но это, как отмечалось, не более, чем мое личное мнение, которое может не совпадать с мнением автора.
При этом поддерживается многоуровневый откат, который по умолчанию находится на '0' (как это изменить рассказано в описании файла hiew.ini). К сожалению буфер отката кольцевой, что не вызывает восторга. Т.к. что бы вернуться в начальную позицию надо держать в голове глубину вложенности (а это весьма проблематично). Было бы гораздо лучше если бы при исчерпании стека hiew пищал хотя бы...
Вообще же навигация по исполняемым файлам дело привычно. В любой момент можно прыгнуть в произвольную точку, нажав F5. При этом адрес будет интерпретирован как локальный, если перед ним находится символ '.' в противном случае всегда осуществляется переход по глобальному смещению внутри файла.
При этом hiew корректно обрабатывает относительные переходы. То есть, например, можно задать +77h или -66h и курсор переместится на 77h байт вперед или 66h назад относительно текущей позиции. Печально, но при этом откат невозможен. Хотя поддержка его была бы не лишней и великолепно вписывающийся в общий антураж программы. Ан, нет... не учел этого автор. Еще один камешек в довод того, что встроенный язык избавил бы его от подобных приставаний.
Аналогично и с поиском перекрестных ссылок. Автоматический откат назад не предусмотрен. С другой стороны последнее настолько уникальная и полезная вещь, что рука не поднимается каким-либо образом критиковать ее. Традиционно для поиска перекрестных ссылок использовали ida или sourcer (который в этом до сих пор обгонят всех конкурентов). Однако, дизассемблеры-монстры очень медлительны и не поворотливы. Для анализа больших файлов не хватит не только терпения хакера, но иной раз и дискового пространства.
Поэтому выбор многих останавливался на hiew-е. Даже когда он не мог делать это автоматически ручной поиск занимал все же меньше времени, чем загрузка файлов в IDA. К тому же в большинстве случаев ссылки на сегмент данных в PE-файлах (например, поиск кода, выводящего строку «key not fond») с легкостью обнаруживались «прямым» поиском локальных смещений (с учетом обратного порядка байтов в двойном слове).
Однако, поиск относительных смещений таким образом был уже невозможен. С другой стороны, требуемое нам смещение лежит «прямым текстом» в дизассемблированном листинге. Остается лишь просканировать последний. Не могу удержаться, что бы не заметить насколько логична в этом случае IDA, которая поддерживает «медленный» поиск подстроки именно в тексте дизассемблера. Это действительно медленно, но на все 100% надежно. hiew же просто дизассемблирует код на лету с шагом в одну команду (или даже байт) и сравнивает непосредственный операнд с текущим смещением, при этом косвенная адресация игнорируется и значения сегментных регистров не отслеживаются. Поэтому хорошо работает такой поиск только на односегментных моделях памяти. Во всех других случаях появятся проблемы (ссылки не будут найдены или найдены неверно).
Последнее, впрочем, исправлению не подлежит без переработки всей архитектуры hiew-а, и мы получим продукт мало отличающийся скоростью от средневзятого дизассемблера. К счастью наиболее популярных сегодня формат win32 PE данные и код хранит в одном сегменте, поэтому в отслеживании сегментных регистров никакой нужны нет.
По умолчанию при дизассемблировании hiew анализирует текст с шагом в одну команду, что многократно ускоряет работу, но не достаточно надежно. Разберем следующий пример.

Код (ASM):

1.      retn
2.      DB 66h
3.      call      666h

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

Код (Text):

1.   00000000: C3                           retn
2.   00000001: 66E86106                     call      000000668
3.                                                    ^^^^^^^^^

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

Код (Text):

1.   00000000: C3                           retn
2.   00000001: 00E8                         add       al,ch
3.             ^^^^
4.   00000003: 61                           popa
5.   00000004: 06                           push      es

Это происходит потому, что hiew не правильно определил границы команд, в результате чего не смог их правильно дизассемблировать. Ни в коем случае не стоит считать последнее «глюком» или недостатком. Это следствие самой концепции элементарного дизассемблера. IDA справляется с этой ситуацией ценой больших затрат времени на анализ программы. Для файлов в в сотни килобайт последние не вызывает проблем на современных быстродействующих процессоров, но даже мощности Pentuim-a II и Clerion-a начинает не хватать, когда счет идет на мегабайты или даже десятки мегабайт (между прочим, типичный размер сегодняшнего исполняемого файла под windows).
Ситуацию может спасти разве, что перекладывание части работы на человека. В приведенном примере ясно, что код после ret вообще собственно говоря кодом гарантированно не является. С таким же успехом это могут быть данные. Что бы это выяснить необходимо найти ссылки на эту область памяти. Устанавливаем курсор на первый байт, переключаем (на всякий случай) шаг сканирования на единицу (Alt+F6) и нажимаем F6. Допустим, hiew нашел следующий код:

Код (ASM):

1.   MOV AL,[0001h]

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

Код (Text):

1.    00000000: C3                           retn
2.    00000001: 00E8                         add       al,ch
3.    00000003: 61                           popa
4.    00000004: 06                           push      es
5.    00000005: A00100                       mov       al,[00001]
6.    00000008: E8F7FF                       call      000000002   -------- (1)
7.              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

Код (Text):

1.    00000002: E86106                       call      000000666
2.    00000005: A00100                       mov       al,[00001]
3.    00000008: E8F7FF                       call      000000002   -------- (1)

Конечно, пример является надуманным, но тем не менее технику работы с примитивными дизассемблерами он иллюстрирует неплохо. Замечу, что «примитивный дизассемблер» вовсе не оскорбление, а соответствующий класс программ, которые выполняют только декодирование инструкций, перекладывая все остальное на плечи пользователя.
Если приведенный пример действительно является com-файлом, то скорее всего hiew не сможет правильно найти ссылки, потому что не правильно вычислит адреса. Это не удивительно, если вспомнить, что com файлы загружаются в память со смещения 100h в текущем сегменте. Пусть оригинальный файл выглядел так:

Код (Text):

1.      0x100: A10401                       mov       ax,[00104h] -¬
2.      0103: C3                           retn                   ¦
3.      0104: 1234                         DB 3412h           <----

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

Код (Text):

1.    00000000: A10401                       mov       ax,[00104] --¬
2.    00000003: C3                           retn                   ¦
3.    00000004: 1234                         adc       dh,[si]      ¦
4.    ........                                                      ¦
5.    00000104: xxxx                                            <----

Разница в том, что ссылка во втором случае указывает «в космос», но никак на переменную 4. Исправить это можно указав hiew-у вручную начальное смещения файла. Выше мы уже сталкивались с этим при анализе PE файлов. В терминологии SEN-а это называется базирование и может быть задано в любой момент анализа, (а не только до загрузки как во многих других дизассемблеров).
Нажимаем Ctrl+F5 и вводим число 100h. Теперь код выглядит следующим образом:

Код (Text):

1.   00000100: A10401                       mov       ax,[00104]  -----¬
2.   00000103: C3                           retn                       ¦
3.   00000104: 1234                         adc       dh,[si]     <-----
4.   00000106: 0100                         add       [bx][si],ax
5.   00000108: E8F7FF                       call      000000102   -------- (1)

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

Код (Text):

1.  000000CE: 2E9A00007100                 call      00071:00000 -------- (1)
2.  000000D4: 9A0D000F00                   call      0000F:0000D -------- (2)
3.  000000D9: 55                           push      bp

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

Код (Text):

1.  000007A0: BA0D01                       mov       dx,0010D ;""
2.  000007A3: 8EDA                         mov       ds,dx

Что такое 10Dh? Это смещение в памяти, которое отличается от смещения в файле только длинной заголовка. В самом деле с отличие от PE файлов, загрузчик DOS-EXE пропускает заголовок, тем самым экономя немного памяти.
Длину заголовка узнать несложно, (значение поле Paragraphs in header умножить на 10h). Аналогично поступим и со значением DS. Итого, 10D0h+90h=1160h смещение сегмента данных в файле.
Смотрим на код ниже:

Код (Text):

1.  000007A0: BA0D01                       mov       dx,0010D ;""
2.  000007A3: 8EDA                         mov       ds,dx
3.  000007A5: 8C063800                     mov       [00038],es

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

Код (Text):

1.   FFFFEF6F: 2E9A00007100                 call      00071:00000 -------- (2)
2.   FFFFEF75: 9A0D000F00                   call      0000F:0000D -------- (3)
3.   FFFFEF7A: 55                           push      bp
4.   FFFFEF7B: 89E5                         mov       bp,sp
5.   FFFFEF7D: 31C0                         xor       ax,ax

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

Код (Text):

1.  FFFFEF31:  10 82 A2 A5-A4 A8 E2 A5-20 AF A0 70-AE AB EC 3A  Введите паpоль:
2.  FFFFEF41:  20 04 59 75-4B 69 12 8F-A0 70 AE AB-EC 20 AD A5   YuKiПаpоль не

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

Код (Text):

1.      FFFFEF88: BF6602                       mov       di,00266 ;"f"
2.      FFFFEF8B: 1E                           push      ds
3.      FFFFEF8C: 57                           push      di
4.      FFFFEF8D: BF0000                       mov       di,00000 ;"  "
5.                                             ^^^^^^^^^^^^^^^^^^
6.      FFFFEF90: 0E                           push      cs
7.      FFFFEF91: 57                           push      di
8.      FFFFEF92: 31C0                         xor       ax,ax
9.      FFFFEF94: 50                           push      ax
10.      FFFFEF95: 9A70067100                   call      00071:00670 --------(5)

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

Код (Text):

1.  00000000:  10 82 A2 A5-A4 A8 E2 A5-20 AF A0 70-AE AB EC 3A  Введите паpоль:
2.  00000010:  20 04 59 75-4B 69 12 8F-A0 70 AE AB-EC 20 AD A5   YuKiПаpоль не

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

 

ПОИСК

«К полной луне призывы...
Шаи-Хулуд поднялся, чтобы ее увидеть;
Красная ночь, сумеречное небо,
Кровавая смерть ― ты погиб.
Возносим молитвы луне: она круглая...
Счастье всегда будет с нами,
Потому, что мы нашли то, что искали,
В стране с твердой землей»
Ф. Херберт. «Дюна».​

HIEW обладает развитым средством поиска, аналогов которому не существует. Можно искать как целые команды, так и любые вхождения. В качестве маски используется символ '?' означающим любую последовательность символов, включая пустую. Иначе говоря, является полным аналогом dos-символа '*'.
Это позволяет искать любые команды и их сочетания в ассемблерном тексте. Мощность и возможности этого механизма не имеют аналогов ни среди отечественных, ни среди зарубежных утилит. Даже IDA не представляет такого сервиса.
SEN в очередной раз продемонстрировал свои способности и оставил всех конкурентов далеко позади. Заметим, что эта возможно впервые появилась еще в версии 4.0, когда подражатели находились еще в зачаточном состоянии.
Как известно, наипервейшая задача хакера локализовать защитный механизм в сотнях килобайт исполняемого кода. Это не так-то просто как может показаться на первый взгляд (при условии, что полный анализ программы просто нереален ввиду огромных трудозатрат на дизассемблирование и изучение).
Поэтому взломщики используют разнообразные хитрости, которые как бы не были различны, но сводятся только к одному ― поиску уникальной последовательности команд, которая предположительно присутствует в защитном механизме. Например, типичной будет конструкция

Код (C):

1.       if !IsValidUser() abort();

или

Код (C):

1.       if IsValidUser()
2.       {
3.        ; // нормальное выполнение программы
4.       }
5.       else
6.         abort();

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

hiew найдет приблизительно следующий код:

Код (Text):

1.  .0001140C: 9A3E172114                   call      001:0173E   -------- (4)
2.  .00011411: 0BC0                         or        ax,ax
3.  .00011413: 7405                         je       .00001141A   -------- (5)

Разумеется, возможно, что call 001:0173E на самом деле не имеет никакого отношения к защите (вероятнее даже, что так скорее всего и будет), но тем не менее ожидается, что в программе не так уж много вышеприведенных комбинаций, и в любом случае это сужает поиск.
Однако, для файла мегабайт десять длинной такое заявление может вызвать лишь легкую улыбку. Возможно, hiew найдет несколько сотен подходящих вариантов и чем их все анализировать легче просто заплатить пару долларов и приобрести легальную версию. Но не будем спешить (хотя все же хакерство ну никак не повод работать на ворованном программном обеспечении) Все что нам нужно собрать доступную информацию о защите и правильно задать команду поиска. Допустим, что мы знаем, что в случае неудачи защита выводит сообщение с известным смещением, предположим, что 406666h. Тогда быть может нам поможет следующая комбинация:

При этом ';;' интерпретируется как любое множество произвольных команд, включая пустое. При этом шансы, что найденный фрагмент окажется именно тем защитным механизмом, который мы ищем, очень хорошие. Если же нет, то не отчаивайтесь, а попробуйте еще один раз.
Очень приятно, что hiew продолжает поиск не с текущей позиции курсора, а с места последнего найденного вхождения. Это дает нам некоторую мобильность в перемещении по файлу.
FindNext сбрасывается при перемещении курсора в начало файла по Ctrl+Home, (или в конец по Ctrl+End). Так же разумеется FindFirst (F7) и совершенно не понятно откуда взявшегося Goto (F5). Последние иногда вынуждает на неприятные «путешествия» по файлу «в ручную» (кирпич на Page Down).
При этом искать можно как во всем файле (по умолчанию), так и в выделенном блоке. Последнее я не представляю для каких целей может быть нужно. Впрочем, тут я все же утрирую. Конечно, это полезная возможность, позволяющая работать с фрагментом файла, например, с защитной процедурой.
К сожалению, в строке поиска нельзя задавать логические конструкции типа 'AND'. 'OR' и другие. Между тем эта возможность очень полезна и в последнее время поддерживается многими популярными системами.

МАНИПУЛЯЦИИ С БЛОКАМИ

«Соединение невежества и знания,
соединение дикости и культуры
не начинается ли оно с того
чувства достоинства, с которым
мы относимся к своей смерти?»
Ф. Херберт «Дюна»​

Выше мы затронули возможность hiew-а работать с выделенным фрагментом текста (блоками). Рассмотрим теперь это подробнее. Для того что бы выделить фрагмент необходимо однократно нажать Gray *. Теперь перемещения по файлу клавишами управления курсором будут приводить к выделению фрагмента и заливке его по умолчанию бардовым цветом. Повторное нажатие Gary * прекращает выделение и активируют клавиши управления блоком.
Это Запись\Чтение блока в файл, а так же заливка его некоторым значением. Рассмотрим окно записи:

Приятной особенностью является возможность записи в файл с произвольным смещением. Это действительно, насущная потребность любого кодокопателя. Скажем, вы решили заменить шрифты в файле или для какой-то цели дописать в его конец маленькую программу (по типу ну скажем вируса). При этом возможно выбрать любую кодировку. Да, я не оговорился, «любую» и это следует понимать буквально плоть по кодировки племен индейцев Северной Америки. Ниже описывается структура файла hiew.hlt, который позволяет это делать.
Замечательно, что все смещения и длина блока выражены шестнадцатеричными цифрами. Это попросту удобно и практично для работы, поскольку средневзятому хакеру десятичная система нравится куда меньше.
То же самое наблюдается и в окне чтения блока. Взгляните:

Загрузка блока ― процесс обратный записи. И не в пример полезный. За мою сознательную жизнь я эту возможность как-то ни разу и не использовал. Не то что бы мой опыт был каким-либо показателем, но я действительно не могу придумать ситуацию, в которой эта возможность была бы незаменима, поэтому не будем на ней останавливаться, а перейдем сразу к «заливке»:

Это окно вызывается по Alt+F3 и следующим образом. Никаких проблем управление им вызвать не должно. Заметим только, что все операции с блоком являются необратимыми и лучше семь раз подумать, чем нажать на кнопку. Резервной копии ведь за вас никто не сделает.

 

ПОДДЕРЖКА LE/PE/NE/LX/NLM ФОРМАТОВ

«Понятие прогресса служит защитным
механизмом, отгораживающим нас от
ужасов будущего»
Ф.Херберт «Дюна»​

Вообще-то шестнадцатеричный редактор идеологически должен быть платформенно-независимым. Введением в него дизассемблера SEN нарушил эту традицию, привязав последний к линейке 80x86 процессоров фирмы Intel.
Однако, в этих пределах hiew все же оставался кросс-платформенным, одинаково хорошо работая со всеми форматами файлов всех существующих операционных систем. Точнее даже, не хорошо работая, а никак не работая, поскольку первые версии не отличали структурированных файлов от простых бинарных.
Десяток лет назад особо поддерживать было еще нечего. В то время господствовали com- и exe-файлы. Первые вообще являлись бинарным образом, а вторые имели крайне простую структуру, которая относилась скорее к загрузке файла в память и была прозрачна для работы с последним «вживую». Я имею ввиду таблицу перемещаемых элементов.
С другой стороны, сегментами кода и данных управляло само приложение непосредственно. Файл все еще оставался простым образом памяти. Это видно хотя бы потому что половина полей заголовка выражается в секторах диска. (когда-то это упрощало загрузку, но сегодня может вызвать разве что легкую улыбку).
Неудивительно, что вся поддержка DOS-EXE свелась к простому отображению заголовка в удобно читаемом виде.

Пояснять значения полей здесь нет смысла ― это гораздо лучше расписано в руководстве программиста для MS-DOS. Ознакомившись с последним можно попытаться отредактировать поля, когда в этом возникнет такая необходимость. hiew позволяет сделать это с комфортом, избавляя от некоторых рутинных вычислений. Так, например F2 автоматически вычисляет значения полей Pages in file и Bytes on last page (это бывает необходимо при манипуляции с размером файла, чаще всего «отрезании» того мусора, который так любят оставлять в конце некоторые распаковщики). При этом hiew никак не учитывает значения поля Overlay length, что может привести к некоторым проблемам и является досадным багом, который автор до сих пор ухитрился не исправить (вероятнее всего потому, что никто из пользователей hiew этого и не заметил. А если кто и заметил, так не имел Интернета, что бы ему об этом сообщить).
Другим приятным сервисом является возможность быстрого перехода в точку входа (F5) и в начало кодового сегмента (F4). Заметим на всякий случай, что это не взаимозаменяемые понятия и редкие exe-файлы начинают выполнение с нуля.
Клавиша F2 поможет быстро перейти в начало оверлея. И вот, пожалуй, все что можно сказать про поддержку old-dos форматов. Предлагаемый набор сервиса типичен для современных hex-редакторов и скопирован практически всеми конкурентами.
Диаметрально противоположно обстоит дело с поддержкой PE-файлов. Выше мы уже неоднократно сталкивались с этим, а сейчас рассмотрим подробнее:

Заметим, насколько усложнился заголовок. Самое интересное, что он не особенно хорошо документирован фирмой MicroSoft (а оно и понятно, это все же внутренняя структура операционной системы и чем меньше приложения о ней будут знать тем лучше).
Когда же сведений, описываемых документацией начинает не хватать, хакеры обычно обращаются к winnt.h ― настоящей сокровищнице, где все структуры хоть и бедно комментированы, но все же хоть как-то расписаны.
Неприятным моментом будет отсутствие возможности редактирования заголовка непосредственно из этого экрана. То ли SEN посчитал, что среднему хакеру это не нужно, то ли просто поленился (кто знает...), но если дело до этого дойдет, то придется вооружившись SDK и MSDN орудовать в hex-редакторе вручную. Или писать свою собственную утилиту, поскольку такая необходимость возникает достаточно часто.
Аналогично поступил автор и с показом флагов (F2). Смотреть можно сколько угодно, а редактировать нет. Печально.

На фоне это довольно качественно реализована навигация по секциям PE-файла (F6) или в терминологии hiew таблице объектов. При этом выдается дополнительная информация о каждой секции. При этом вновь, к сожалению, отсутствует возможность редактирования и все флаги показаны не в бинарном, а в шестнадцатеричном виде. Последнее вынуждать выполнять все расчеты в уме. Действительно, какие атрибуты имеет секция .text? 60000020h можно разложить на 20h+40000000h+20000000h, (если читатель не понял откуда взялись эти цифры, то пусть переведет 60000020h в двоичное представление, оно будет равно 110000000000000000000100000b. Теперь уже нетрудно вычислить, что 100000b=20h; 10000000000000000000000000b=20000000h и 100000000000000000000000000b= 40000000h. Достаточно тривиальные вычисления, которые любой хакер считает в уме даже без помощи калькулятора).
Получается, что секция .text имеет следующие атрибуты ― Code | Can be discarded | Not cachable. Было бы куда нагляднее, конечно, представить всю эту информацию сразу в удобно-читаемом виде. Но, автор признается, что не любит плодить монстров, да и не настолько трудно все эти вычисления выполнить в уме, а то последний стремительно усыхает в наш бурный век думающих машин и автоматических калькуляторов.
Другой вопрос, что утомительно было бы держать в уме все значения флагов (кому приятно запоминать эту чисто справочную информацию?). К счастью автор предусмотрел последнее и включил в контекстную помощь соответствующий пункт, который можно увидеть на рисунке, приведенном ниже:

Код (Text):

1.  ╒===========================[ PE-header ]============================╕
2.  ¦                                                                    ¦
3.  ¦  ╒=Number  Name   VirtSize   RVA    PhysSize  Offset    Flag===¬   ¦
4.  ¦  ¦     1 .text    000004FA 00001000 00001000 00001000 60000020 ¦   ¦
5.  ¦  ¦     2 .rdata   0000051A 00002000 00001000 00002000 40000040 ¦   ¦
6.  ¦  ¦     3 .data    00000168 00003000 00001000 00003000 C0000040 ¦   ¦
7.  ¦  ¦     4 .rsrc    000000F0 00004000 00001000 00004000 40000040 ¦   ¦
8.  ¦  ¦   ╒========================[PE Object flags]=========================╕
9.  ╘  ¦   ¦  -------------------- Flag for object -------------------------  ¦
10.     ╘= C¦  0x00000004       Used for 16-bit offset code.                   ¦
11.         ¦  0x00000020       Code.                                          ¦
12.         ¦  0x00000040       Initialized data.                              ¦

Кроме отображения секций hiew еще умеет читать IMAGE_DATA_DIRECTORY и представлять ее в удобно-читабельном виде. Это действительно, наиболее важный элемент структуры PE-файла и необходимый для поиска таблиц экспорта\импорта и ресурсов. Оставим временно в стороне последние и обратим внимание на таблицу импортируемых функций. Фактически изучение любого приложения начинается с ее анализа. Какие функции вызывает программа? Какие загружает DLL? Ставить ли точку останова на GetWindowTextA или GetDlgItemTextA? На все эти вопросы можно найти ответ, просмотрев список импортируемых функций.
Логично, что при изучении DLL нас наоборот в первую очередь будет интересовать экспорт и соответствующая ему секция. Конечно, мне могут возразить, что для этого существуют специальные программы наподобие dumpbin, которые делают всю работу за нас, генерируя удобно-читаемый список, а в hiew-е по каждой секции еще придется полазить вручную. И уж совсем казалось бы не к месту разговор о ресурсах, в которых с первого взгляда ни одному смертному разобраться не дано. К тому же существуют великолепные визуальные редакторы ресурсов наподобие популярного Borland ReourceWorkShop.
Так-то оно так, да только на первый взгляд. «Популярные и великолепные» редакторы оказываются неспособными поддержать новые элементы Windows и просто при этом необратимо портят ресурс (особенно это относится к Борландовскому редактору, и в меньшей степени и к другим).
Относительно же таблиц экспорта\импорта разница между «структурированным» листингом и «живом» представлении AS IS не так уж и велика. Действительно, взгляните на рисунок. Не нужно большой сноровки, что бы бегло пробежаться глазами по знакомым функциям MSVCRT. Впрочем, для «гурманов» Сусликов включил в пакет несколько специальных программ *dump, позволяющим более детально исследовать формат файла.

Однако, если бы hiew только бы и мог, что отображать некоторые структуры PE файлов, то эта бы возможность скорее всего осталась бы так и не замеченной на фоне таких конкурентов, как dumpbin, делающим, кстати, это значительно лучше hiew-а.
На самом же деле уникальность последнего заключается в другом ― в возможности просматривать непосредственно имена вызываемых функций (или ординалы, если в DLL отсутствует символьная информации) в окне дизассемблера. (К сожалению, встроенный ассемблер все еще не поддерживает этой возможности).
Что бы понять насколько это удобно нужно поработать с hiew-ом хотя бы пару часов. Сравните qview и hiew. Не правда-ли второй значительно информативнее и просто практичнее в работе. Смысл же команд первого совершенно не понятен и загадочен. Даже если перейти по косвенному адресу, все равно там мы ничего не увидим, ибо содержимое этой секции не определено до загрузки файла.
Должен заметить, что автор допустил несколько досадных упущений, которые заметны уже в первые полчаса работы (как это он до сих это не заметил?!). HIEW никак не учитывает косвенной адресации, которая так «любят» использовать все компиляторы, и особенно оптимизирующие компиляторы от MicroSoft.
В результате по-прежнему имя вызываемом функции остается загадкой. Тут на помощь приходит недокументированная особенность, заключающаяся в том, что секция адресов во многих случаях совпадает с секцией имен. Не смотря на то, что она в любом случае будет затерта загрузчиком, это дает нам возможность определить по косвенному вызову ординал и имя функции. Как это сделать подробно рассказывают другие книги, здесь я лишь посоветую обратится по RVA адресу, (если он не равен нулю). Например в нашем случае он равен 2B56h и по которому располагается строка 'AppendMenuA', таким образом mov ebx, [0004021E8] следует читать как mov ebx,AppendMenuA. Если же секция адресов пуста (или там содержится мусор), то необходимо вычислить индекс элемента от ее начала и обратится к секции имен или просто скопировать ее самостоятельно поверх первой. Как уже отмечалось ее содержание некритично и лишь помогает при анализе программы в дизассемблере.

Код (Text):

1.  Qview:
2.   00001730: FF250C214000                 jmp       d,[00040210C]
3.   000019AE: FF25D8214000                 jmp       d,[0004021D8]
4.   00001372: 8B1DE8214000                 mov       ebx,[0004021E8]

Код (Text):

1. Hiew:
2.  .00401730: FF250C214000                 jmp       MFC42.4673
3.  .004019AE: FF25D8214000                 jmp       __CxxFrameHandler ;MSVCRT.dll
4.  .00401372: 8B1DE8214000                 mov       ebx,[0004021E8]
5.                                                        ^^^^^^^^^^^

Вторым по распространенности после ЗК-файлов, является LE формат, который широко используется в VxD файлах. HIEW позволяет осуществлять навигацию по различным его структурам, а так же обеспечивает удобно-читабельное представление некоторых из них.
Заметим, что далеко не все дизассемблеры поддерживают LE-формат файлов, а те которые его все же поддерживают ужасно медленно работают. Поэтому hiew на этом фоне выглядит весьма прогрессивно и предоставляемых им возможностей вполне хватит для серьезной работы с драйверами виртуальных устройств. Невозможно представить себе надежную защиту, не использующую собственный vxd, особенно когда речь идет об обмене данных с электронным ключом например, или ключевой дискетой (к огромному моему удивлению до сих пор встречается разработчики, не расставшиеся с этим пережитком прошлого).
Однако, vxd полезны не только как собственно драйвера устройств. Код, размещенный в них, работает в нулевом кольце защиты и практически без ограничений. Это открывает широкие границы фантазии разработчикам. Действительно, трудно представить себе мало-мальски серьезный защитный механизм, не выходящий за пределы третьего кольца.
Впрочем, анализ vxd файлов не намного сложнее любого другого и ничего в этом таинственного и загадочного нет. Достаточно заглянуть в SDK, что бы хотя бы в общих чертах ознакомится с форматом файла и уже можно начинать в последний вгрызаться дизассемблерм. Hiew-ом, например.
Как видно из рисунка, LE-заголовок ненамного сложнее своего PE собрата и не должен вызвать особых трудностей. Назначение большинства полей понятно из них названия и только несколько моментов могут потребовать уточнения в SDK. Между прочим, MicroSoft не очень-то открыто предоставляет сей формат на общественное растерзание. Описания довольно скудные и отрывочные. Несколько статей по этому поводу в MSDN только возбуждают аппетит и разжигают любопытство, но никак не проясняют ситуацию.
Фактически анализ формата приходится выполнять каждому кодокопателю cамостоятельно. И в этом значительную помощь могут оказать hiew и прилагаемая к нему программ ledumd. Ну к последней мы еще вернемся, а возможности hiew-а опишем прямо сейчас:

Код (Text):

1.   ╒============================[ LE-header ]=============================╕
2.   ¦ Object table count             2 ¦ Page count                      4 ¦
3.   ¦ Starting EIP   00000000:00000000 ¦ Page size                00001000 ¦
4.   ¦ Starting ESP   00000000:00000000 ¦ Bytes in last page       00000490 ¦
5.   ¦ Fixup section size      000002D8 ¦ Loader section size      00000053 ¦
6.   ¦ Object table   000000C4/00000144 ¦ Object page     000000F4/00000174 ¦
7.   ¦ Object iterat  00000000/00000000 ¦ Resident name   00000104/00000184 ¦
8.   ¦ Resource       00000000/00000000 ¦ Number of resource              0 ¦
9.   ¦ Directives     00000000/00000000 ¦ Number of directive             0 ¦
10.   ¦ Fixup page     00000117/00000197 ¦ Fixup records   0000012B/000001AB ¦
11.   ¦ Import module  000003EF/0000046F ¦ Number of module                0 ¦
12.   ¦ Import proc    000003EF/0000046F ¦ Entry table     0000010D/0000018D ¦
13.   ¦ Data pages offset       00000600 ¦ Number preload pages            3 ¦
14.   ¦ Non-resident name       00003A90 ¦ Bytes in non-resident          51 ¦
15.   ¦ Instance in preload     00000000 ¦ Instance in demand       00000000 ¦
16.   ¦ Auto data               00000000 ¦ Heap/Stack      00000000/00000000 ¦
17.   ¦ Debug info     00000000/00000000 ¦ Debug length             00000000 ¦
18.   ╘======================================================================╛

Заглянув в помощь, можно просто поразится возможностям навигации. Можно переходить к LE заголовку, точке входа, таблице объектов и импорта, DDB секции, таблице страниц и ресурсов, кроме того резидентных и не резидентных имен, да всего и не перечислишь!
Немного печально, конечно, что Hiew показывает все вышеперечисленное «AS IS» и не делает никаких попыток улучшить читабельность. Можно, конечно, воспользоваться для этой цели соответствующими утилитами, но в однозадачной MS-DOS крайне неудобно. Легче уж смириться с тем, что есть и разбирать все структуры вручную, надеясь, что все же автор когда-нибудь пойдет на встречу своим клиентам и реализует недостающий сервис (а вот пойдут ли клиенты навстречу автору и не принесут ли они в жертву хотя бы один доллар об этом история умалчивает).
Между тем, hiew все же отображает по крайней мере флаги заголовка, а это уже не мало. Во всяком случае уже не придется копаться в битовых полях, что ускорит работу.
Так же hiew правильно дизассемблирует все вызовы VMM, что между прочим является не такой уж и тривиальной задачей. Qview, например это делает совершенно неправильно, чем и вводит пользователя в заблуждение.
Сравните как дизассемблировали hiew и qview один и тот же фрагмент. Увы, но этот пример не в пользу qview-а, который я все же люблю не смотря ни на что, но должен признать, что он безнадежно проигрывает hiew-у в этом сравнении и вряд-ли в ближайшее время ситуация изменится в лучшую сторону.

Код (Text):

1.  Hiew:
2.  .000002E3: CD208D000100              VMMcall   Save_Client_State
3.  .000002E9: 5F                        pop       edi

Код (Text):

1.  Qview:
2.   000046E3: CD20                      int    20
3.   000046E5: 8D00                      lea    eax,dword ptr [eax]
4.   000046E7: 0100                      add    dword ptr [eax],eax
5.   000046E9: 5F                        pop    edi

К сожалению, SEN допустил досадную ошибку (ну с каким программистом этого не случается!) и его творение спотыкается при попытке ассемблирования VMM-вызова. Взгляните на экран, показанный ниже ― он наглядно иллюстрирует мои слова. hiew «съедает» аргумент и отказывается анализировать любой введенный вручную. Как символьный, так и цифровой.

Код (Text):

1.    ╒= Pentium(R) Pro Assembler =====================================╕
2.    ¦ VMMcall------------------------------------------------------- ¦
3.    ╘================================================================╛

Печально, конечно, но тут речь идет не более, чем о программой ошибке, которая вероятно, будет устранена в ближайших версиях. А пока этого не случилось ассемблировать придется «вручную». А для этого придется познакомится с форматом вызова VMM.
Заглянем в MSDN, там по этому поводу содержится много полезных статей и информации. Но для начала обратим внимание на базовую функцию VMMCall:

Код (ASM):

1.    VMMCall Service, Parameters

Она ассемблируется следующим образом:

Код (ASM):

1.    INT 20h
2.    DW  Parameters
3.    DW  Service

Рассмотрим это на примере показанном ниже. Все настолько просто, что никаких проблем вызвать не должно. Если вы чего-то не понимаете, то обратитесь к MSDN. Там множество примеров, подробно комментирующих вышесказанное.

Код (Text):

1.    .00002665: CD2066661234                 VxDcall   3412.6666
2.                   ^^^^""""                           """" ^^^^

Заслуга автора hiew в том, что последний представляет это в удобно-читаемом виде. Откуда же он берет символьную информацию? Ведь ее явным образом не содержится в файле! Верно, не содержится, поэтому-то автор и создал файл hiew.vxd приблизительно следующего содержания:

Код (Text):

1.     [048B.VCACHE]
2.      ^^^^
3.     Get_Version
4.     Register
5.     GetSize

Формат его очевиден и не требует особых комментариев, достаточно взглянуть на расположенную ниже строку:

Код (Text):

1. .00002665: CD2000008B04                 VxDcall   VCACHE.Get_Version
2.                    ^^^^

Разумеется, этот файл можно как угодно перекраивать под свой вкус и потребности. В частности, вносить поддержку новых vxd, используемых, скажем защитой, или написанных вами.
При этом vxd с ординалом сервиса 0x01 иначе еще называется (в терминологии архитектуры win32 ― VMM (Virtual-Memory Manager). На самом же деле это все тот же vxd и вызов его происходит аналогично:

Код (Text):

1. .00012161: CD2001000100                 VMMcall   Get_Cur_VM_Handle
2.            ^^^^
3. .00002665: CD2000008B04                 VxDcall   VCACHE.Get_Version
4.            ^^^^

Доказательством этого служит следующая стока из hiew.vmm "[0001.VMM]". Вообще-то с названием файла, автор похоже допустил еще одну досадную ошибку, немного сбивающую с толку. Все же это не 'hiew.vmm', а 'hiew.vxd'. Надеюсь, что в последующих версиях это будет исправлено.
Мы еще не упомянули о таком понятии, как VxDjmp. На самом деле вызывается он аналогично, за маленьким исключением ― старший бит параметра в этот случае равен единице, а не нулю. Вот, взгляните сами:

Код (Text):

1. .00005040: CD201C801700                 VxDjmp    SHELL.Update_User_Activity
2.                  ^
3. .00005048: CD2048810100                 VMMjmp    RegOpenKey
4.                  ^

hiew правильно интерпретирует значение этого бита, в противном случае бы он неверно дизассемблировал бы вызов и не смог бы определить функцию. Это еще раз подчеркивает, что автор проделал большую работу и мелкие ошибки в благодарность ему можно и простить. Любопытно, что вместо этого их склонны упорно не замечать, иначе трудно было бы объяснить почему они продержались вплоть до 6.03 версии. Пассивный нынче народ стал, однако...
На этом описание поддержки LE-формата я заканчиваю. Если кому-то оно покажется неполным, пожалуйста, обратитесь к соответствующей документации. После некоторых размышлений я решил не описывать остальные форматы, что бы не повторяться. Не думаю, что бы там было что-то особо интересное.

 

КАЛЬКУЛЯТОР

«Врагу, которым восхищаешься,
легче вселить в тебя ужас».
Ф.Херберт «Дюна»​

Необходимость встроенного калькулятора сегодня сомнений ни у кого не вызывает. Хакеру настолько часто приходится возится с разными системами исчисления, битовыми масками, относительными переходами, что он всего этого голова пойдет кругом, если потребуется проводить вычисления в уме.
Впервые полноценный калькулятор, насколько мне помниться, появился в qview-е, намного опередив конкурентов. В свое время это даже послужило причиной отказа от hiew-а, у которого такой калькулятор появился относительно недавно и, к сожалению, сильно проигрывающий qview-скому.
Признаться мне непонятна позиция автора в этом вопросе. Почему бы ему если не опередить, то хотя бы просто догнать конкурентов? Тем более, что основное различие как-раз и состоит в отсутствии поддержки битовой системы исчисления. То есть как раз того, ради чего калькулятор в большинстве случаев и нужен. Битовые операции в основном приходится выполнять при разборе различных флагов и атрибутов.
К счастью во всем остальном калькулятор hiew-а ни в чем не уступает своим собратьям и поддерживает все типовые логические и математические операции которые подробно будут описаны ниже:

(_)	hiew поддерживает круглые скобки. Если их не ставить, то операции будут выполняться в порядке старшинства операций. Однако, на это я не рекомендую полагаться, а все же не полениться и ставить побольше скобок. Никому они еще никогда не помешали
―	Вычитание, а так же отрицательное число. При этом двойное слово дополняется до нуля. К сожалению выбрать другую размеренность операндов никак не получится. По крайней мере в текущих версиях
+	Сложение, а так же положительное число. Забавно, что hiew переваривает такие конструкции как '+-+-++' и подобные им. При этом '-' изменяет значение всех знаков, стоящих правее в цепочке на противоположное. Математически это верно, но ценность этого сомнительна

*	Умножение. Поддерживает знаковые числа. Конструкции типа '**' не воспринимаются синтаксическим анализатором. (Возведение в степень, увы ― отсутствует)
/	Целочисленное деление
%	Взятие остатка. ВНИМАНИЕ! HIEW Содержит большой и очень-очень непринятый баг ― операция 'X % 0' приводит к аварийному завершению и выходу в DOS без сохранения проделанной работы
^	Битовая операция XOR (исключающее ИЛИ)
&	Битовая операция AND (И)
|	Битовая операция OR (ИЛИ)
!	Логическое (не битовое) отрицание. !0 = 1 !X = 0, где X≠0 Вообще непонятно с чего бы автор ввел логическое, а не битовое отрицание. На редкость бесполезная операция, и к тому же отсутствует логическая NOT, что мне категорически не нравится
>>	циклический сдвиг вправо. Имеет самый низший приоритет, поэтому 0FFh >>1+1 = 3Fh = 0FFh>>2. Не забывайте расставлять скобки. (Заметим, что A >> -x = 0, что является еще одним багом, идущим вразрез с математикой)
<<	Циклический сдвиг влево
>	Логическое «больше». A > B = 1 если A > B и A > B = 0, если это условие ложно. Например (1>2)+3=3 (10>0)+1=2 но 1>2+3=0 обратите внимание на последний баг. Он может служить источником трудно уловимых ошибок, а вообще, если честно эта операция
<	Логическое «меньше»

Все числа по умолчанию десятичные. Шестнадцатеричные записываются как 0xABCD. При этом никакой другой записи или формы исчисления hiew упорно не желает понимать, в том числе и общепринятой 0ABCDh. Вызывает некоторые неудобства, но надеюсь будет исправлено в следующих версиях.
Окно калькулятора можно перемещать стрелочками вверх и вниз. Довольно полезная возможность, когда последний закрывает собой экран с необходимой в данный момент информацией. При этом вправо-влево окно калькулятора упрямо перемещаться не хочет. Не то что бы неудобно, но неприятно.

КРИПТ-СИСТЕМА

«Не считай человека мертвым, пока
не увидишь его тело. И даже тогда
ты можешь ошибиться»
Ф. Херберт. «Дюна»​

Уникальность hiew-а прежде всего в том, что SEN впервые в мире реализовал в нем удобную интерпретируемую крипт-систему. До этого такого попросту не было. Если требовалось расшифровать файл или его фрагмент, то необходимо было писать собственную программу на ассемблере или любом другом языке высокого уровня.
С появлением hiew все изменилось. Стало возможным расшифровывать программы «на лету» не отрываясь от анализа. При этом процесс расшифровки полностью контролировался и сразу же отображался на экране. Практическое применение крипто-системы мы рассмотрим после знакомства с системой команд.
Внешне экран встроенного редактора скриптов показан ниже. Конечно, это не полноэкранный привычный нам редактор, а подстрочник (наподобие того, который был в ZX-SPECTRUM-48), но пользоваться им достаточно удобно. К тому же типичный скрипт занимает всего несколько строк, ради который интегрировать в hiew полноэкранный редактор было бы расточительством.

Хотя в заголовке строки ввода гордо красуется 'Pentium Pro Assembler' hiew понимает только ограниченный набор команд, который даже не покрывает 8086. Было бы неплохо если бы автор изменил заголовок и не вводил пользователей в заблуждение.
Очень большим ограничение является отсутствие операндов в памяти. Из этого следует, что сколь-нибудь серьезный скрипт написать не удастся. Все, что доступно хакеру это 32 байта памяти в виде регистров EAX, EBX, ECX, EDX, EBP, ESI, EDI, ESP. Да, в последнем случае я не оговорился ― в криптосистеме hiew регистр esp ― «общего» назначения и ничто не помешает использовать его для своих нужд.
При этом скорее забавно, чем грустно смотрится отсутствие условных переходов. Pentium Pro Assembler? Ну-ну... С другой стороны программирование с таких «жестких» рамках само по себе представляет увлекательнейшую головоломку и действительно иногда напоминает «высший пилотаж». 32 байта памяти ― примерно столько было было в первых программируемых микрокалькуляторах. Но даже там были условные переходы и прямая адресация памяти. Впрочем, черт, с ними, с условными переходами их бы было можно реализовать исходя из принципа эквивалентности с помощью всего двух команд NOR и OR. Но в hiew-е вообще нет переходов! Нет регистра-указателя команд!
Печально все это, при том, что в qview-е таких ограничений попросту нет. Там управление передается полноценной ассемблерной программе, которая может делать все что ей заблагорассудиться. Однако, это проигрывает в интерактивности. За все, конечно, приходиться платить. Мне по душе все же интерактивноть, поэтому я выбираю hiew. Тем более, что для ряда случаев его все же хватает.
Итак, поддерживаются следующие команды:

Набор регистров:	AL, AH, AX, EAX, BL, BH, BX, EBX. CL, CH, CX, ECX, DL, DH, DX, EDX, SI, ESI, DI, EDI, BP, EBP, SP, ESP
Команды пересылки:	MOV регистр, регистр
	MOV регистр, непосредственный операнд
Арифметические, логические команды, сдвиги:	AND, NOT, NEG, OR, XOR, SUB, ADD, ROL, ROR. MUL, DIV
	SHL и SHR не поддерживаются.
Передача параметров:	На входе AX
	На выходе AX

Как видим, набор инструкций воистину «спартанский». Однако, для большинства задач его все же хватает. Заметим, что чаще всего большинство разработчиков использует операцию XOR, поэтому в hiew-е она выделена в отдельный обработчик.
Самое интересное, что последний работает не только с байтами\словами\двойными словами, но и со стоками любой длины (точнее до 20 символов). Для задания xor-маски нужно нажать Ctrl+F8, но так же это окно вызывается и при нажатии F8, если маска еще пуста.

Очень часто в программировании используется шифр Вернама, сводящийся к ксорению кода некой строкой, допустим 'KPNC++'. (Подробнее о нем можно почитать в главе, посвященной криптографии). Предыдущие версии hiew не имели такой возможности и не поддерживали строки. Разве, что из четырех байт (двойного слова).
К сожалению, остальные команды до сих пор не могут работать со строками, и это сильно удручает. Но вернемся, собственно к интерпретатору скриптов. Рассмотрим простейший пример. Для вызова редактора нажмем Ctrl+F7 и введем следующую последовательность команд:

Ожидается, что она должна расшифровывать текст по xor word,1234h. Однако, это не произойдет. hiew автоматически не может определить размера операндов и поэтому по умолчанию работает только с байтами (См строку статуса в заголовке). При этом старший байт регистра AX действительно будет корректен, но вот инкремент все же будет равен единице, а не двойке, как следовало бы ожидать по логике вещей.
Что бы изменить шаг, необходимо нажать F2, при этом в строке статуса 'Byte' смениться на 'Word'. Так же можно изменить и направление (то есть поменять инкремент на декремент, для чего служит клавиша F3, но в нашем примере мы этого делать не будем).
Команда 'loop' на самом деле никакой не 'loop', а 'jmp', причем направленный только назад. Если вы попытаетесь сделать прыжок «вниз», то произойдет приблизительно следующие:

Ну никак не хочет hiew понимать таких конструкций. Впрочем, так и должно быть. Команда 'loop' последняя в скрипте и все ее назначение ― зациклить программу. При нажатии на F7 (Crypt) hiew шифрует слово\байт и встретив 'loop' останавливается, ожидая следующего нажатия F7, после чего переходит на указанную метку.
Строку 'looo 1' можно опустить. Обычно так и поступают. Но иногда необходимо выполнить только один раз некий иницилизирующий код, как например, показано ниже. При этом строка '1' выполняется один только раз, а все остальное время hiew крутиться в цикле 2-4.

Заметим, что приведенный алгоритм очень популярен среди вирусописателей и разработчиков защит, поэтому применять его вам придется довольно часто. При этом может возникнуть проблема как сбросить текущее значение регистров и начать выполнения скрипта сначала. Действительно, предположим Вы успешно расшифровали один фрагмент и взялись было за другой,
как чувствует, что он начинает расшифровываться некорректно. Разумеется, так и должно быть. Ведь в регистрах остался мусор от предыдущего выполнения и скрипт пытается продолжить расшифровку, ничего не зная, что нужно начать сначала.
Это приходится делать пользователю вручную, нажимая Ctrl+F7 (Crypt-Set), Ctrl+F5 (ClearReg). При этом всплывает еще один баг автора ― «теневой» регистр указателя команд будет так же сброшен, но «визуальный» указатель «>» останется неизменным вводя пользователя в некоторое заблуждение в поисках еще одной клавиши сброса последнего. Но ее нет, достаточно однократного нажатия F5, а на знак «>» просто попытайтесь не обращать внимания.
Использование Crypt в качестве калькулятора довольно любопытный прием, облегчающий хакерам жизнь и страхующий от многих ошибок. Так или иначе, но большая часть вычислений так или иначе связана с анализируемым файлом. При этом утомительно переносить необходимые значения в калькулятор (не ошибившись при этом в порядке следования старших и младших байт), когда просто можно указать hiew-у последние курсором. Ведь крипт принимает входные данные и если сохранить то же самое значение регистра AX на выходе скрипта, шифровка окажется «прозрачной», то есть не изменяющий значение под курсором.
Допустим, нам необходимо прочесть значения двух переменных хранившихся в одном байте в упакованном виде. Пусть три старших байта отводится под одну из них и пять под другую. В калькуляторе это вычислять будет утомительно и неудобно. Кроме того поскольку последний не может обрабатывать двоичных чисел в строке ввода, то и вовсе невозможно. Поэтому прибегаем к довольно бесхитростному скрипту. Но как мы узнаем полученный результат? Очень просто, поскольку значения регистров сохраняются, достаточно вызвать SetCrypt и взглянуть на них. Впрочем, это не намного менее хлопотно, чем ввести то же значение в калькулятор. Поэтому рассмотрим действительно полезный пример. Допустим, нам необходимо узнать хеш-сумму некоторого фрагмента (например для того что бы исправить CRC после правки пары байт в коде). Возьмем к примеру простейший алгоритм суммирования байт (который очень распространен).

Код (Text):

1.                       ╒=[Byte/Forward ]==============╕
2.                       ¦  1>add   bx,ax     ¦ AX=0000 ¦

«Прогоняем» расшифровщик по выбранному фрагменту, теперь вызываем редактор и смотрим на значение регистра BX:

Код (Text):

1.                       ╒=[Byte/Forward ]==============╕
2.                       ¦  1>add   bx,ax     ¦ AX=0121 ¦
3.                       ¦  2                 ¦ BX=7534 ¦

Это и будет искомая хеш-сумма нашего фрагмента. Удобно, не правда-ли? К сожалению, удобно-то оно удобно но не всегда. Большие фрагменты так обрабатывать крайне утомительно. Необходимо будет «вручную» интерактивно прогнать курсор по всему блоку, каждый раз прокручивая страницу и возвращаясь на предыдущее место. Любая ошибка будет фатальной и сделать откат (т.е. вычесть значение из BX) не представляется в текущих версиях возможным. Как это будет не печально, но придется все начинать сначала.
Для таких целей лучше все же подходит qview. HIEW-ом же удобно вскрывать несложные криптосистемы и пары сотен байт, зашифрованных по сравнительно простому алгоритму.
Однако, не смотря на вышесказанное встроенный интерпретатор hiew-а многими горячее любим и интенсивно используется. Быть может потому, что он был первым, а может потому что сделан с любовью. Так или иначе он нужен. И очень большое недовольство вызвало отсутствие крипта в 6.0 версии. К счастью, автор быстро одумался и тут же вернул его на место.
Жалко, конечно, что за всю историю существования hiew-а крипт претерпел наименьшие изменения. Появилась разве что возможность записи скриптов во внешний файл (F10). Это конечно, удобно, но практически этим редко пользуются. А зачем? Обычно скрипты состоят из нескольких строк и не так уж и трудно их вновь «набить» вручную.
При этом записанный файл автор не советует редактировать. Цитирую выдержку из файла read.me «Но так как трансляция во внутреннюю форму происходит в момент ввода строки команды с клавиатуры не стоит пытаться править сохраненный файл, ни к чему это...» На самом деле файл состоит по крайне мере из двух частей. Из отранслированных команд и их строкового представления. При этом никто не запрещает разобраться в логике работы транслятора и изменить сохраненные во «внутреннем представлении» команды.
Разумеется, если отредактировать их «текстовой» образ, то ожидаемого эффекта это никогда не даст. Впрочем, зачем редактировать записанный файл не штатными средствами этого я действительно никак не могу понять.

ОПИСАНИЕ ФАЙЛА HIEW.INI

― «Осторожность ― важное качество
для человека, который будет вождем»
Ф. Херберт. «Дюна».​

HIEW часть настроек хранит в ini файле, который немного напоминает одноименные windows-файлы. Их легко редактировать вручную и структура достаточно проста и не нуждается в описании. Однако, все же я решился подробно рассказать о последнем. Кто знает, какие вопросы могут возникнуть у читателя.
Первая строка непременно должна быть [HiewIni 5.03] независимо от текущей версии. Непонятно, почему так? Если для совместимости «сверху-вниз», то почему бы просто не искать строку «HiewIni»? Тем более, что ini от разных версий между собой не совместимы, т.к. автор частенько удалял один ключи и добавлял другие.
Пустые строки и строки, начинающиеся с «;» игнорируются. Последнее, как нетрудно догадаться, предназначено для комментариев.
hiew.ini не является обязательным файлом. При его отсутствии будут браться параметры по умолчанию, которые совпадают с содержащимися в «дистрибутивном» варианте.

; стартовый режим
[StartMode]	может принимать следующие значения Text, Hex, Code. Выбранное значение будет автоматически установлено при открытии файла. Рекомендую установить 'Hex', а впрочем, воля Ваша
[Beep]	включить\выключить (on\off) звуковой сигнал при ошибочных и нештатных ситуациях. По умолчанию включен и я не вижу смысла изменять это значение
[Bar]	Лифт или другими словами индикатор прогресса. По умолчанию расположен слева (Left), несмотря на то, что пользователь приучен интерфейсом Windows видеть эту полоску справа (Right). Впрочем, в текстовом режиме попытки изобразить что-либо похожее всегда неудачны и поэтому на мой взгляд более подходящим является числовое представление в процентах (Percent). которое к тому же высвобождает одну колонку, что особенно актуально для простора текстовых документов, отформатированных по 80 символов в стоке.
[Wrap]	Перенос длинных строк. Может принимать значения 'on' или «off', но намного более удобен автоматический (Auto) режим, устанавливаемый кстати сказать по умолчанию. При этом для двоичных файлов всегда выполняется перенос строк, а для текстовых нет
[Tab]	Поддержка табуляции. Если установлено значение 'On', то hiew корректно обрабатывает символы табуляции, встретившиеся в просматриваемом тексте. Если же установить «Off', то все символы табуляции будут проигнорированы. Аналогично вышеупомянутому [warp] существует и автоматический режим, который устанавливается по умолчанию и на мой взгляд очень удобен
[StepCtrlRigh]	задает число столбцов, на которые смещается текст при нажатии Ctrl-Left \ Ctrl-Right. По умолчанию равен 20. Очень удобная возможность для просмотра текстовых файлов, отформатированных более, чем с 80 символами в строке и причем так, что перенос строк не представляется возможным. Например, при просмотре таблиц, диаграмм и т.д. Может принимать значения от 1 до 128. Или другими словами signed byte
[DisableMouse]	по идее должен прятать\не прятать мышиный курсор. Однако не зависимо от установленного значения курсор все равно не отображается
[JumpTable]	задает таблицу переходов по call/jmp в дизассемблере. По умолчанию она выглядит следующим образом: «0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ». При этом первый символ ― это клавиша отката, то есть возвращения назад. А.Куленцов нашел довольно оригинальное (хотя на мой взгляд слишком очевидное) решение представить эту строку в виде «0123456789QWERTYUIOPASDFGHJKLZXCVBNM» для удобства работы с клавиатурой. А по мне так хватает и девяти цифровых символов. Заметим, если на экране появится больше ссылок, то остальные просто не будут отображены
[Linefeed]	для текстовых файлов задает символ переноса строки. Из-за того что в разных системах он разный могу возникнуть некоторые проблем с его интерпретацией. Большинство просмоторщиков автоматически определяют используемый формат. Точно так же поступает и hiew (Auto). Однако, если нужно, то можно перевести его и на ручной режим управления. Он понимает следующие значения ― LF (0Ah), CR (0Dh), CRLF (0D0Ah), но к сожалению не правильно интерпретирует (0Ah 0Dh) и (0Ah 0Ah). Впрочем, последнее достаточно редко встречается, что бы вызвать какие-то проблемы. Отметим, что эта возможность впервые появилась только в версии 5.10
[AutoCodeSize]	автоматически определяет разрядность кода (16\32) в LX файлах. (префикс «a» в строке статуса говорит, что активирован автоматический режим определения). Не вижу никакой причины выключать эту возможность, хотя последнее автором за каким-то загадочным случаям все же предусмотрено
[KbdFlush]	управляет очисткой клавиатурного буфера перед вводом. По умолчанию включено. В противном бы случае в окнах ввода информации частенько бы появлялся мусор предыдущих нажатий клавиш. Поэтому я никак не могу представить себе ситуации в которой это было бы полезно. Словом отключать эту возможность можно разве что ради эксперимента
; Маска для показа смещения при поиске с шаблоном и поиске ссылок RunningOffsetMask = 0xFF ; 0 - 0xFFFFFFFF v5.53
[XlatTableIndex]	задает индекс таблицы перекодировки в файле hiew.xlt выбираемый по умолчанию. При этом «0» трактуется как отсутствие таблицы перекодировки, или в терминологии hiew-а «AS IS».
[FlistSort]	задает критерий сортировки файлов в Навигаторе по умолчанию
[FlistSortReverse]	инвертировать критерий сортировки. То есть по умолчанию он задается по возрастанию параметра сортировки. Если это кажется неудобным, то процесс можно и обратить
[FlistShowHidden]	показывать или нет скрытые файлы в Навигаторе. По умолчанию такие файлы не отображаются. Странно, однако. Рекомендую установить этот параметр в «On».
[NextFileSaveState]	сохранять текущее состояние при переключении между файлами. По умолчанию выключено, что мне категорически не нравиться. Рекомендую активировать сей механизм ― это сбережет Вам немало времени и нервов
[SaveFileAtExit]	записывать состояние файла по выходу. По умолчанию выключено (?!) что мне абсолютно непонятно. Это-то на фоне того, что выход происходит без всякого предупреждения пользователя и на Esc и F10 и без того навешено немало других функций, так что ложные нажатия происходят довольно часто. Непременно необходимо включить этот механизм
[ScanStep]	шаг по умолчанию при поиске ссылок (F6 Reference) или команд (F7,F7). По умолчанию имеет значение «Command» но по мне лучше проиграть в скорости, чем надежности и (как было сказано выше) я предпочитаю устанавливать шаг поиска в байт («Byte»)
[Savefile]	задает имя и путь к файлу сохранения состояния. По умолчанию hiew создает файл «hiew.sav» в текущей директории, но это можно изменить. Это бывает полезно, например, когда на текущий диск записать нельзя (ключевая дискета, защищенная от записи, CD-ROM)...

ЦВЕТА

Наконец-то hiew стал поддерживать цветовую раскладку! Теперь каждый может настроить ее под свой вкус. Я, допустим, большой поклонник «зеленым по черному» и все используемые программы настраиваю именно так.
Подробно описывать кодировку цветом цвета нет, она тривиальна. К тому же это гораздо удобнее делать специальной утилитой, (например, похожей на qview) чем делать это вручную.
Структура этой секции hiew.ini ясна из приведенного фрагмента:

ColorMain	= 1Bh	; основной цвет
ColorCurrent	= 71h	; текущий байт

HIEW.XLT

Этот файл служит для перекодировки символов. Может содержать до 15 кодировок, но в распространяемом автором варианте содержит только две ― Win1251 и KOI8R. Имеет довольно витиеватую структуру и для его создания\ просмотра\ редактирования не помешает написать хорошую утилиту. Автор в сопутствующей документации описывает структуру как:

Код (C):

1.    typedef  struct{
2.    BYTE  sign[9],             // "HiewXlat",0
3.          unused[5],
4.          versionMajor,          // 0x05
5.          versionMinor;          // 0x40
6.    }XLAT_HEADER;
7.                  
8.   typedef  struct{
9.    BYTE  title[16],           // заголовок
10.          tableOut[256],       // для вывода
11.          tableIn[256],        // для ввода
12.          tableUpper[256];     // для игнорирования регистров в поиске
13.    }XLAT;

Не думаю, что это вызовет какие-нибудь вопросы. Структура полностью понятна и удобна в обращении. Заметим, что ввод\вывод разделены, что приятно. Аналогично и с переводом регистра. Разумеется hiew не может знать как расположены символы в произвольной кодировке, поэтому регистр автоматом не переводит.
Жалко только, что в комплекте с hiew-ом не идет утилиты для работы с этим файлом. Ну откомпилировать его можно, положим препроцессором, но вот декомпилировать... для декомпиляции потребуется написать специальную программу. Допустим, если вы решитесь добавить поддержку ISO, то потребуется сначала декомпилировать существующий файл, внести исправления и построить опять.
Заметим, что hiew.hlt может отсутствовать. В этот случае поддерживается единственная кодировка по умолчанию DOS или в терминологии hiew-а «AS IS».

 

Крис Касперски. Самомодификация на службе шифрования

фрагмент главы из книги «Компьютерные вирусы изнутри и снаружи»
Взято здесь​

Откомпилируем программу обычным образом (например,

cl.exe /c FileName.C

), получим объектный файл FileName.obj. Теперь необходимо скомпоновать исполняемый файл, предусмотрительно отключив защиту кодовой секции от записи. В линкере Microsoft Link за это отвечает ключ /SECTION, за которым идет имя секции и назначаемые ей атрибуты, например,

link.exe FileName.obj /FIXED /SECTION:.text,ERW

.
Здесь: /FIXED – ключ, удаляющий перемещаемые элементы (мы ведь помним, что перемещаемые элементы необходимо удалять), «.text» – имя кодовой секции, а «ERW» – это первые буквы Executable, Readable, Writable, хотя при желании Executable можно и опустить – на работоспособность файла это никак не повлияет. Другие линкеры используют свои ключи, описание которых может быть найдено в документации. Имя кодовой секции не всегда совпадает с «.text», поэтому если у вас что-то не получается, используйте утилиту DUMPBIN для выяснения конкретных обстоятельств.
Сформированный линкером файл еще не пригоден для запуска, ведь защищенная функция еще не зашифрована! Чтобы ее зашифровать, запустим HIEW, переключимся в HEX-режим и запустим контекстный поиск маркерной строки (F7, «KPNC», ENTER). Вот она! (см. рис.1). Теперь остается лишь зашифровать все, что расположено внутри маркеров «KPNC». Нажимая F3, мы переходим в режим редактирования, а затем давим F8 и задаем маску шифрования (в данном случае она равна 66h). Каждое последующее нажатие на F8 зашифровывает один байт, перемещая курсор по тексту. F9 – сохраняет изменения на диске. После того, как файл будет зашифрован, потребность в маркерах отпадает и при желании их можно затереть бессмысленным кодом, чтобы защищенная процедура поменьше бросалась в глаза.

Рисунок шифровка защитной процедуры в HIEW'e

Вот теперь наш файл готов к выполнению. Запустим его и… конечно же, он откажет в работе. Что ж! Первый блин всегда комом, особенно если тесто замешено на самомодифицирующемся коде! Призвав на помощь отладчик, здравый смыл и дизассемблер, попытайтесь определить, что именно вы сделали неправильно. Как говориться «Everybody falls the first time» (© «The Matrix»).
Добившись успеха, загрузим исполняемый файл в IDA PRO и посмотрим как выглядит зашифрованная функция. Бред сивой кобылы да и только:

Код (Text):

1. .text:0040100C loc_40100C:  ; CODE XREF: sub_40102E+50↓p
2. .text:0040100C  cmp  eax, 0ED33A53Bh
3. .text:00401011  mov  ch, ch
4. .text:00401013  and  ebp, [esi+65h]
5. .text:00401016  and  ebp, [edx+3Bh]
6. .text:00401019  movsd
7. .text:0040101A
8. .text:0040101A loc_40101A:  ; DATA XREF: sub_40102E+6↓o
9. .text:0040101A  xor  ebp, ebp
10. .text:0040101C  mov  bh, [ebx]
11. .text:0040101E  movsd
12. .text:0040101F  xor  ebp, ebp
13. .text:00401021  mov  dh, ds:502D3130h

Листинг внешний вид зашифрованной процедуры​

Естественно, заклятье наложенной шифровки легко снять (опытные хакеры сделают это, даже не выходя из IDA PRO – подробности см. в «Образ мышления IDA»), так что не стоит переоценивать степень своей защищенности. К тому же, защита кодой секции от записи была придумана неслучайно и ее отключение разумным действием не назовешь.
API-функция VirtualProtect позволяет манипулировать атрибутами страниц по нашему усмотрению. С ее помощью мы можем присваивать атрибут Writeable только тем страницам которые реально нуждаются в модификации и сразу же после завершения расшифровки отбирать его обратно
Обновленный вариант функции crypt_it может выглядеть например, так:

Код (C):

1. crypt_it(unsigned char *p, int c)
2. {
3.   int a;
4.   // отключаем защиту от записи
5.   VirtualProtect(p, c, PAGE_READWRITE, (DWORD*) &a);
6.   // расшифровываем функцию
7.   for (a = 0; a < c; a++) *p++ ^= 0x66;
8.   // восстанавливаем защиту
9.   VirtualProtect(p, c, PAGE_READONLY, (DWORD*) &a);
10. }

Листинг использование VirtualProtect для кратковременного отключения защиты от записи на локальном участке
Откомпилировав файл обычным образом, зашифруйте его по методике описанной выше, и запустите на выполнение. Будем надеяться, что он заработает с первого раза.

 

Огромное спасибо Marylin за помощь в изготовлении иллюстраций

 

San01suke. Tribute to HIEW

взято здесь

Навеяно древними воспоминаниями… Проходят года и десятилетия, сменяют друг друга названия операционных систем, но кое-что всё же остается неизменным. Среди всего многообразия около хакерского ПО меня всегда удивлял HIEW; непостижимым образом этой консольной программе удается бороться со временем и быть популярной даже сегодня. HIEW занял свою нишу и стал основным инструментом промышленного вирусного аналитика. Вам может показаться это странным и неудобным, но использовать HIEW для вирусного анализа — очень эффективно.
Итак, начнем-с, пожалуй.
Задача: выделить и классифицировать вредоносное ПО среди горы исполняемых файлов.
Решение:

• использовать динамический анализ неудобно,
• IDA долго (и дорого),
• вывод — используем HIEW.

Опишем примерный алгоритм экспресс анализа исполняемого файла на вредоносность. Первое, что необходимо сделать — выявить возможное заражение анализируемого объекта файловым вирусом.
Загрузим исполняемый файл в HIEW и посмотрим, в какую секцию указывает точка входа (Enter, F8, F6). Здесь возможно несколько случаев.
Вариант первый. Точка входа указывает куда-то в область заголовка PE-файла. Вариант тривиален и обнаруживается визуальным просмотром файла в текстовом режиме.
Вариант второй. Точка входа указывает на последнюю секцию исполняемого файла. Это тоже очень подозрительно и, скорее всего, свидетельствует о заражении файла.
Рассмотрим несколько примеров.
Точка входа имеет следующий вид:

Натренированный глаз режет применение инструкции call +5, что очень не характерно для обычного компилятора. Так же интересна строка 48C030h, где, вероятно, происходит ручная работа с заголовком PE-файла. Посмотрим на атрибуты секции:

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

Вердикт очевиден — файл заражен. После байт, оставленных в конце файла для выравнивания компилятором, следует не только осмысленный код, но и сама точка входа.
Сделаем небольшое лирическое отступление от экспресс-анализа. Напрашивается вопрос: можно ли с HIEW исследовать динамически-расшифровывающиеся объекты? На удивление, это часто удаётся сделать. Рассмотрим предыдущий пример с вирусом Virut. Код вируса невелик, местами зашифрован и расположен в конце файла. Немножко полистав дизассемблерный листинг, натыкаемся на это:

Здесь нетрудно увидеть простейший цикл расшифровки. Однако в случае статического анализа мы не можем определить, что и с каким ключом тут расшифровывается. Но! Вспомним, что HIEW поддерживает поиск перекрёстных ссылок, наведём курсор на начало цикла расшифровки, нажмем F6 и поищем вызовы интересующего нас участка кода:

Очень вероятно, что это и есть код, вызывающий процедуру расшифровки. В этом случае зашифрованный участок находиться по адресу 48C155h ([EAX]), а одно-байтовый ключ находиться по адресу 48C154h ([EAX-1]). Размер блока — 12B2h байт.
Чтобы произвести расшифровку, пользователи IDA побежали бы писать скрипт на idc или питоне. В отладчике, вообще, ничего делать не пришлось бы. Пользователи же HIEW используют встроенные средства обработки блоков данных. Опишем требуемый алгоритм шифрования, выделим границы блока в режиме 16-ричного редактора и запустим скрипт.

Встроенное средство обработки блоков имеет Intel-подобный синтаксис и позволяет производить несложные преобразования по 8, 16, 32 и 64 бита. В результате расшифровки получим вполне пригодные для анализа данные:

Вернемся снова к экспресс-анализу.
Вариант третий. Точка входа указывает туда, куда ей и положено — в секцию кода. Для обнаружения заражения требуется небольшой опыт. Рассмотрим несколько примеров.

В глаза бросаются инструкции call +5; pop reg. Данный прием очень характерен при написании базо-независимого кода. Следует отметить, что вместо прямого перехода на тело вируса часто используются инструкции типа push reg; retn либо mov reg, addr; call reg и другие вариации на эту тему. Нормальные же компиляторы обычно так не поступают, по крайней мере, уж не на точке входа, а в каком-нибудь виртуальном классе. Из всего этого можно сделать вывод, что данный экземпляр так же заражен файловым вирусом. В данном случае это — небезызвестный Sality.
Двигаемся дальше. Допустим мы встретили следующий код:

Несмотря на то, что точа входа сразу указывает на call и jmp, файл не заражен, и это стандартное начало программы С/C++, скомпилированной Microsoft Visual Studio. Данный пример скорее исключение. Обычно при заражении кодовой секции вредоносный код дописывается либо в ее конец (при наличии достаточного количества места), либо делается jmp на вредоносный код прямо с точки входа. Компиляторы же обычно начинают выполнение программы с вызова стандартной функции, имеющей стандартный пролог:

Здесь мы видим начало программы, скомпилированной с помощью компилятора Visual Studio C++. Точка входа указывает на стандартный пролог, далее следует установка собственного обработчика исключений.
Рассмотрим следующий код:

Здесь точка входа указывает на уже известную нам последовательность push addr; retn. Перед нами — Rustock.
После анализа точки входа неплохо произвести просто просмотр секций и оверлеев файла. Иногда встречаются следующие экземпляры:

В данном примере, в оверелее, вероятно, записано зашифрованное тело оригинальной программы. Суть механизма «заражения» можно понять из следующего кода:

По сути, «вирус» заражает файлы следующим образом: полностью зашифровывает оригинальный исполняемый файл, перемещает данные себе в оверлей и перезаписывает получившимся файлом оригинальную программу. При запуске программа расшифровывает оригинальный файл, записывает его на диск во временную директорию и запускает с оригинальными параметрами командной строки.
На этом вирусный анализ как таковой заканчивается. Обнаружить более сложные заражения за короткое время в режиме промышленного аналитика затруднительно (личное мнение). Далее идет работа по определению вредоносного функционала самого анализируемого файла.
Различные вымогатели, фейковые антивирусы и т.п. обнаруживаются просто при беглом просмотре файла в текстовом режиме:

Поскольку ни для кого не секрет, что в России производиться достаточное количество вредоносного ПО, то возможность работы HIEW с русскими кодировками из коробки сильно облегчает жизнь вирусному аналитику.
Так же HIEW позволяет на глаз определить зашифрованные участки файла. Специфика кода и данных такова, что в них присутствует много избыточности, а особенно нулевых байтов. Поэтому при обнаружении, например, следующего блока данных…

…можно сделать вывод, что эти данные зашифрованы. Можно ли их статически расшифровать? В данном случае нам повезло, и мы снова ограничимся одним HIEW. Перейдем на начало зашифрованных данных и поищем перекрестные ссылки:

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

И расшифровываем вредоносниый код:

В случае невозможности быстрой расшифровки, файл направляется на более глубокий анализ, но это уже другая история.
Далее по плану идет определение стандартных троянских программ типа Zeus, SpyEye, Carberp и других. По словам, опытный вирусный аналитик идентифицирует их с первого взгляда (автор же проверить данное заявление не имеет возможности).
В итоге мы можем анализировать и классифицировать экземпляры с практически нереальной скоростью: 1 объект менее чем за 10 минут. Видимо это и стало залогом успеха такой легендарной программы как HIEW.

 

alex_dz,
а как перевести hiew32 в ARM режим? Хьюв поддерживает 64-разряда, по идее, цикл нужно переписывать с учетом новых версий и реалий