Subj: АVР разбор полетов_____________________

Необходимое замечание

Вирусная энциклопедия AVPVE (кстати, положенная в основу книги "Компь­ютерные вирусы в MS-DOS") — это великолепное и уникальное произведение, на сегодняшний день не имеющее аналогов.

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

Словом, хотелось выбрать индивидуально-предпочтительный интерфейс рабо­ты с энциклопедией (сконвертировать текст в HTML для просмотра через браузер; извлечь все "демонстрационные эффекты" в отдельные файлы для последующего дизассемблирования любопытных экземпляров и т.д.)

По-видимому, я не был одинок в своих желаниях, поскольку в разных источниках появлялись "выломанные" из AVPVE фрагменты описаний и демок. Судя по "мусору" в концах файлов, ясно, что их выдирали "вручную" в дебагере, а тексты (скорее всего) получали экранными грабилками. Понятно, что перепе­чатки без ведома автора — плохая практика.

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

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

Я отдаю себе отчет в том, что, зная формат dem-файлов, некоторые личности смогут их видоизменить таким образом, что демонстрация может (к большому удивлению юзера) покрошить ему диск. Поэтому я настоятельно рекомендую не "сливать" никаких компонентов "Вирус­ной энциклопедии" из сомнительных источников.

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

Результат своих изысканий я привожу ниже. Замечу, что пока я не разобрался с некоторыми (в общем-то некритичными) полями, поскольку необходимости в них не возникло.

Формат файлов (общее)

По моему мнению, формат файлов вирусной энциклопедии плохо продуман, неоптимально реализован, часто противоречив и местами исходит из соображе­ний "авось и так сойдет".

Сказанное выше не повод для наезда или оскорбления, а констатация очевид­ных фактов. Однако это никак не должно ущемлять Автора, ибо излишняя гениальность в наше время до добра никого не доводит и экономически нецеле­сообразна. Вся информация, приведенная ниже, получена путем дизассемблиро-вания вирусной энциклопедии avpve.exe IDA 3.6 и уточнения ряда моментов под Soft-Ice 2.8; назначение многих полей определялось простым визуальным просмот­ром, благо что было логичным и вытекающим из содержимого.

Большинство секций всех файлов упакованы по усовершенствованному LZk (k от Касперского) алгоритму, который не меняется от файла к файлу и от версии к версии.

Некоторые секции шифрованы тривиальным XOR [b],OxAD. Смысл этого мне абсолютно не ясен (разве погонять процессор), но, как говорят, хозяин — барин.

Алгоритм LZk

Префикс Префикс Префикс ~/~

word data word data word

Структура префикса:

lxjxixixixixlxlxlxlxlxlxlxlxlxlll Data I • '•

^________________ ^

x - незначащий бит Неупакованный байт данных

^____________________^ Указатель Длина L упакованного фрагмента данных + 2

Указатель Длина L упакованного фрагмента данных + 2

Если L==1, то пропустить следующий за префиксом байт как незначащий. Если L==0, то следующий за префиксом байт—длина фрагмента+1.

Если L==0 и следующий за префиксом байт==0, то конец распаковке.

Данной информации хватает для написания пакера/анпакера, хотя пакер необ­ходим только для эффективной перепаковки после внесенных изменений. Если дисковое пространство не критично, то можно прописать в префиксах Oxffff, оставив файлы не упакованными. Но лучше все же написать полноценный упаковщик.

Данный механизм обеспечивает сжатие примерно в 1.8 раз для текстовых данных с незначительными накладными расходами.

Формат файла языковой поддержки AVP.LNG

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

Ограничения: секция строк ограничена Ox7DOO байтами, (32000 в десятичном представлении), а секция адресов Ox7DO (2000 в десятичном представлении), впрочем, размер секции адресов при редактировании файла не изменяется, поэтому это ограничение можно не учитывать.

Файл состоит из трех частей: заголовка Ох1А байт, следующей за ним секции строк и адресов.

Заголовок Секция строк Секция адресов Ох1А

Рассмотрим подробнее заголовок:

section.string section.addr

"-VLanguageSupport",0 UNP_SIZE PCK_SIZE UNP_SIZE PCK_SIZE

0х12 word word word word

Первые 0х12 байт — это сигнатура, которая проверяется при загрузке файла, UNP_SIZE — оригинальный размер упакованной секции строк/адресов, PCK_SIZE — размер запакованной секции строк/адресов.

Секция строк представляет обычные строковые ресурсы а-ля-Виндоус, которая поксорена по XOR [byte], OxAD; больше ничего интересного не наблюдается. Никаких CRC не предусмотрено.

Сразу за секцией строк начинается секция адресов. Для нее все аналогично, с тем различием, что она не зашифрована.

Обе секции пожаты по описанному выше алгоритму LZk. Секция адресов состоит из far-указателей на строки. Сегмент может быть произвольным, так как при загрузке он устанавливается программой самостоятельно; смещение отсчиты­вается от 0х4 (именно такое смещение бывает у выделенных блоков функцией malloc). Это совсем неправильно, ибо нельзя столь беспечно полагаться на системную библиотеку компилятора. Секция адресов сжата, но не шифрована. Однако могу заметить, что глупо использовать такой алгоритм, так как нужно было сохранять одни смещения, а не тянуть за собой никому не нужный сегмент.

Формат файлов HLP

Файлы HLP содержат много структур, точнее, все вместе: и таблицы смеще­ний, и данные, и ссылки на внешние файлы (например dem).

Формат HEAD OEM section.TitleOffset section.OffsetOffset section.text

Формат файлов HLP довольно необычен и содержит несколько подструктур, хотя можно было бы обойтись и одной глобальной структурой; но зато он оптимизирован для медленных машин и ограниченного объема памяти и tiny(!) модели памяти.

Алгоритм работы в общих чертах такой — сначала распаковывается secti­on.OffsetOffset, которая содержит точки входа в структуру TitleHeap. Каждый вход содержит подструктуру TitleOffset, которая имеет переменную длину (вот поэтому и потребовалась вспомогательная подструктура OffsetOffset). В структу­ре TitleOffset описываются гиперссылки, ссылки на секцию text и ссылки на внешний ресурс.

Заголовок

'.VHG' 1р * OffsetOffset lp * text OEM text

dword dword dword not define

Заголовок содержит, кроме традиционной сигнатуры, ссылки на две секции section.OffsetOffset и section.Text; смещения отсчитываются от начала файла.

Указатель на секцию section. TitleOffset в заголовке отсутствует по той причине, что он на него ссылается. Элемент ОхС секции OffsetOffset. OEM text, показанный здесь входящим в заголовок для наглядности, на самом деле к заголовку скорее всего не относится, — но это сути не меняет, ибо он совершенно бесполезен... Разве что как копирайт.

Section. OffsetOffset

OffsetOffset — это основной ключ к пониманию структуры файлов hip. Эта секция содержит смещения относительно начала файла на структуры, которые содержат все необходимые ссылки на нужные ресурсы. Все гиперссылки ссыла­ются на section.OffsetOffset.

Сжатый формат OffsetOffset

Numer Index Real Numer Index not use данные

word word word

Numer Index — число индексов в секции. Все индексы — двойные слова. Real Numer — число реально используемых индексов. not use — а вот это поле однозначно не используется в AVPVE.exe. Секция OffsetOffset упакована по алгоритму LZk и не шифрована.

Распакованный формат

???? ____ INDEX I INDEX 2 INDEX 3 -/-0х30

dword dword dword

Все индексы содержат смещения относительно начала файла.

Назначение первых 0х30 байт неясно. Но и без их понимания все хорошо работает.

Структура TITLE

x_lnk x_offs lp *demo N_Link LINK loc_offset lp *vol

word word dword word *** word dword

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

x_offs — это поле не используется в текущих версиях, но, возможно, будет использовано в последующих. Содержит смещение топика в разделе.

lp *dem — смещение относительно начала файла внешнего ресурса dern; если равно нулю, то внешнего ресурса нет.

N_LINK — число гиперссылок в разделе. Если нуль, то гиперссылок нет. LINK — секция описания гиперссылок (локальная). Размер секции 5*N_LINK. loc_off — локальное смещение подзаголовка в разделе. lp *vol — смещения раздела относительно начала секции section.text.

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

Но внимание привлекает любопытная деталь — встроенное кеширование. Дело в том, что несколько заголовков (для улучшения сжатия?) пакуются в один раздел, поэтому для определения необходимого подраздела вводится еще одно двухбайтовое поле loc_offset, которое представляет смещение в распакованном фрагменте. Двухбайтовая величина наводит на мысль от том, что максимальный размер раздела Oxffff байт — полезный штрих для практической реализации.

Интересный момент — avpve.exe не использует кеширования и при чтении следующей главы в уже распакованном разделе повторно его распаковывает! Ну что тут можно сказать...

Структура ссылок

INDEX offset Length

word word byte

INDEX — это индекс структуры OffsetOffset.

offset — смещение начала гиперссылки в разделе. Используется браузером для "подсветки" гиперссылок.

Length — длина гиперссылки, также нужна браузеру для выделения.

Структура TITLE

Первая секция:

N_TOPIC SIZE TOPIC flag? ____text____

word word word

Последующие секции:

SIZE TOPIC flag? text

word word

N_TOPIC — число подразделов в разделе. SIZE_TOPIC — размер подраздела в байтах. flag — не разбирался. Но и без него работает. Структура DЕМ-файлов

a?-v word

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

Формат ресурсов

PCIGSIZE d a t a dword

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

Поле PCK_SIZE — это размер упакованного ресурса. Двойное слово. Сами данные упакованы и шифрованы.