Blog. Just Blog

Запись в архивы ACE, HA и LIM без помощи архиватора

Версия для печати Добавить в Избранное Отправить на E-Mail | Категория: Образ мышления: Assembler | Автор: ManHunter
Предлагаю вашему вниманию третью, заключительную (надеюсь) статью про запись в архивы различных форматов без помощи архиваторов. Напомню, что в первой части были описаны наиболее популярные архиваторы, во второй части я начал рассказывать про более редкие и экзотические архиваторы, а сейчас тему экзотики можно будет закончить. Как и в предыдущей статье, к каждому примеру приложен сам архиватор и описание внутреннего формата его архивов, чтобы вам не пришлось их искать.

Начну с формата ACE. Это сравнительно свеженький продукт, по крайней мере есть версия под Windows, а сайт датирован 2000-м годом. Разработчики утверждают, что по степени сжатия чуть ли не превосходят архиватор RAR. Однако, в дикой природе я пока что не встречал чего-либо, упакованного этим архиватором, поэтому он и попал в категорию экзотических. Но внутренний формат архивных файлов .ACE очень простой. Не используются никакие "хвосты" в конце архива, есть только главный заголовок архива, после которого идут подряд упакованные файлы с заголовками. Формат заголовка следующий:
  1. ;---------------------------------------------
  2. ; ACE Header
  3. ;---------------------------------------------
  4. ahcrc   dw      ?                       ; CRC32x of the header
  5. ahsize  dw      ?                       ; Size of the header
  6. ahtype  db      ?                       ; Header type (01 = files)
  7. aflags  dw      ?                       ; Header flags (8001h)
  8. acsize  dd      ?                       ; Compressed file size
  9. aosize  dd      ?                       ; Original file size
  10. adtm    dd      ?                       ; Date/Time
  11. aattr   dd      ?                       ; File attributes
  12. afcrc   dd      ?                       ; CRC32x of the file
  13. ainfo   dd      ?                       ; Type and quality of compression
  14. ares    dw      ?                       ; Unknown
  15. aflen   dw      ?                       ; Filename size
  16. afname  rb      (?)                     ; Filename (ASCII)
Архиватор ACE поддерживает длинные имена файлов Windows, поэтому поле для хранения имени файла afname обозначено уже знакомым вам мнемокодом (?), то есть текстовая строка неопределенной длины. В нашем случае хватит MAX_PATH или другой фиксированной длины.

Записываемый файл предварительно надо загрузить в память, после этого заполняем поля заголовка архива:
  • ahcrc = контрольная сумму CRC32x заголовка от поля ahsize до afname включительно;
  • ahsize = длина заголовка от поля ahcrc до afname включительно;
  • ahtype = 1 - тип заголовка - файл;
  • aflags = 8001h - флаг заголовка;
  • aosize = размер оригинального файла;
  • acsize = размер сжатого файла (равен оригинальному);
  • adtm = дата и время создания файла;
  • afcrc = CRC32x оригинального файла;
  • ainfo = 0 - тип компрессии Store;
  • aflen - длина имени файла;
  • afname - имя файла;
Первым делом заполняется имя файла и поле aflen, куда записывается длина имени файла. Строка имени не должна заканчиваться нулевым символом. Затем заполняется длина заголовка ahsize с учетом имени файла. Для подсчета контрольной суммы заголовка и файла используется стандартная функция вычисления CRC32, но с одной небольшой особенностью. Особенность заключается в том, что значение CRC32 не финализируется (по указанной ссылке за финализацию в функции расчета отвечает флаг dFlag), то есть не выполняется заключительная команда XOR EAX,-1. Зачем так было сделано - я не знаю. Может быть ошибка при выпуске первой версии, а может быть по каким-то соображениям так сделано специально. После заполнения всех полей заголовка устанавливаем указатель на конец архивного файла, записываем заголовок, после него записываем наш файл. Все, с внедрением в файлы .ACE разобрались.

HA - еще один из архиваторов-долгожителей под MS-DOS, который ведет свою историю аж с 1993 года (по другим данным с 1994). Хотя времени прошло немало, но архивы, упакованные HA иногда встречаются на дисках с различной документацией. Это связано с тем, что наилучшие результаты по сжатию архиватор показывает именно на текстовых файлах, давая реальный выигрыш до 20% по сравнению с другими архиваторами. Интересующая нас информация для внедрения в файлы .HA состоит из двух частей - главного заголовка архива и заголовка отдельного файла в архиве.
  1. ;---------------------------------------------
  2. ; Главный заголовок архива
  3. ;---------------------------------------------
  4. hid     dw      ?                       ; ID='HA'
  5. hfnum   dw      ?                       ; Number of files in archive
Первые 4 байта файла - это и есть главный заголовок архива. Он состоит из идентификатора "HA" и WORD'а с количеством файлов в архиве. Как вы, наверное, догадались, количество файлов в архиве .HA не может превышать 65535 штук. Вряд ли на практике вы столкнетесь с такими архивами, но знать это будет нелишним.
  1. ;---------------------------------------------
  2. ; HA Header
  3. ;---------------------------------------------
  4. hver    db      ?                       ; Version & compression type
  5. hcsize  dd      ?                       ; Compressed file size
  6. hosize  dd      ?                       ; Original file size
  7. hfcrc   dd      ?                       ; CRC-32 of file
  8. hdtm    dd      ?                       ; Date/Time
  9. hpath   rb      (?)                     ; ASCIIZ pathname
  10. hfname  rb      (?)                     ; Filename (ASCIIZ)
  11. hmlen   db      ?                       ; Length of machine specific info
  12. hmach   dw      ?                       ; Machine specific information
Перед внедрением нашего файла в архив, поля в заголовке надо установить равным следующим значениям:
  • hver = 20h - версия заголовка и тип компрессии Store;
  • hosize = размер оригинального файла;
  • hcsize = размер сжатого файла (равен оригинальному);
  • hdtm = дата и время создания файла;
  • hfcrc = CRC32 оригинального файла;
  • hpath - путь файла в формате ASCIIZ;
  • hfname - имя файла в формате ASCIIZ;
  • hmlen = 2 - размер дополнительной информации;
  • hmach = 2001h - дополнительная информация;
Обратите внимание, что поле даты/времени создания файла hdtm заполняется значением в формате TIMESTAMP, то есть количеством секунд, прошедшим с 00:00:00 UTC 1 января 1970 года. Конечно, можно отконвертировать дату создания файла в TIMESTAMP как это советуют сделать в Misrosoft, или использовать какое-нибудь фиксированное значение, но я сделал хитрее. При внедрении в файл я читаю дату создания первого файла в архиве и использую это значение для внедряемого файла. Кстати, я видел исходники некоторых вирусов и всякие вирусные мануалы, где используется или описывается заражение архивов формата .HA, и везде была одна и та же ошибка - поле hdtm заполнялось как дата/время в формате файловой системы, а не как TIMESTAMP. В моем варианте это поле заполняется абсолютно корректно. Уже при написании этой статьи я подумал, что будет правильно приравнивать дату и время создания внедряемого файла с первым файлом архива не только при работе с форматом .HA, а и вообще со всеми типами архивов. В этом случае не будет такого явного палева с внезапным появлением в архиве новых файлов. Контрольная сумма CRC32 файла считается как обычно, с финализацией, тут никаких сюрпризов нет. Путь файла hpath должен быть пустой строкой, то есть один нулевой байт. Имя файла hfname не должно превышать 255 символов. Назначение полей с дополнительной информацией hmlen и hmach я не знаю, но они обязательно должны присутствовать в файловом заголовке архива и именно с указанными значениями.

При внедрении в архив загружаем файл в память, заполняем поля заголовка. Устанавливаем указатель на конец файла архива и записываем сперва сформированный заголовок, а затем и сам внедряемый файл. Специфических признаков окончания архива нет. Последним действием надо установить указатель на самое начало файла, прочитать главный заголовок архива, увеличить счетчик файлов на единицу и записать его обратно. На этом с архивами формата .HA и закончим.

LIM - формат файлов, создаваемых DOS'овским архиватором Limit от некоего J Y LIM. Судя по дате исполняемого файла и документации, архиватор был создан в 1993 году. Больше про Limit ничего неизвестно, упоминаний в сети мало, архивов и вовсе нет. Никаких описаний формата я также не нашел, с внутренней структурой архивов пришлось разбираться на готовых архивных файлах. К счастью, структура оказалась несложной, удалось идентифицировать все поля, нужные для внедрения. Я сильно сомневаюсь, что вам где-то попадутся архивы .LIM, так что это все не более, чем "proof of concept".
  1. ;---------------------------------------------
  2. ; LIM Header
  3. ;---------------------------------------------
  4. lsign   dw      ?                       ; Sign
  5. lsize   db      ?                       ; Size of Header
  6.         db      ?                       ; unknown
  7.         db      ?                       ; unknown
  8.         db      ?                       ; unknown
  9. ldtm    dd      ?                       ; Date/Time
  10. lattr   db      ?                       ; File attribute
  11.         db      ?                       ; unknown
  12. lmeth   db      ?                       ; Compression method (0 = store)
  13. losize  dd      ?                       ; Original file size
  14. lcsize  dd      ?                       ; Compressed file size
  15. lfcrc   dd      ?                       ; 32-bit CRC
  16. lfname  rb      (?)                     ; Filename (ASCIIZ)
Как я уже говорил, некоторые поля мне не удалось правильно идентифицировать, в заголовке они отмечены комментарием "unknown".
  1. ; Признак окончание архива
  2. tail    db      013h,0F8h,005h,00h,00h
Признаком окончания архива является "хвост" длиной 5 байт, который записывается после последнего файла. Его значение неизменно.
  • lsign = 0F123h - сигнатура заголовка;
  • lsize - размер заголовка от поля lsign до lfname включительно;
  • losize = размер оригинального файла;
  • lcsize = размер сжатого файла (равен оригинальному);
  • ldtm = дата и время создания файла;
  • lfcrc = CRC32 оригинального файла;
  • lattr = 20h - атрибуты файла;
  • lmeth = 0 - метод компрессии Store;
  • lfname - имя файла в формате 8.3, завершается нулевым символом;
При внедрении сперва загружаем наш файл в память, заполняем известные поля заголовка. После этого надо установить указатель файла на 5 байт от конца архива, записать сформированный заголовок, затем наш файл и после этого записать пятибайтовый "хвост" архива. С внедрением в архивы формата .LIM тоже разобрались.

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

Пример программы с исходным текстом (FASM)Пример программы с исходным текстом (FASM)

Store.to.ACE.without.Archiver.Demo.zip (281,465 bytes)

Пример программы с исходным текстом (FASM)Пример программы с исходным текстом (FASM)

Store.to.HA.without.Archiver.Demo.zip (53,858 bytes)

Пример программы с исходным текстом (FASM)Пример программы с исходным текстом (FASM)

Store.to.LIM.without.Archiver.Demo.zip (33,149 bytes)


Поделиться ссылкой ВКонтакте
Просмотров: 6376 | Комментариев: 18

Внимание! Статья опубликована больше года назад, информация могла устареть!

Комментарии

Отзывы посетителей сайта о статье
Hige (29.07.2013 в 00:25):
Пожалуйста! Вообще я когда-то думал разобрать формат этого архиватора, да написать римейк под Windows, да оказался не таким крутым реверсером :( Ну да ладно. Буду теперь заходить и читать ваши статьи. Сайт интересный, в закладки однозначно.
ManHunter (29.07.2013 в 00:08):
Hige, спасибо! Мельком глянул - формат несложный, CRC32 стандартная, остальные служебные поля заголовка легко разбираются на тестовых файлах. Есть запись файлов в режиме "store". Похоже, что придется писать четвертую часть статьи, я как раз еще всяких раритетов накопал. А досовские СУБД не надо, я не некромант :)
Hige (28.07.2013 в 23:52):
http://yadi.sk/d/qeS2bpD07Jpci
Держите :) У этой конторы есть еще какая-то досовская СУБД. Очень мощная на то время, при этом с весьма хитрой защитой. Могу поискать, если вам интересно, вроде где-то было.
ManHunter (28.07.2013 в 20:41):
Ко мне можно обратиться. Интересно посмотреть, может быть действительно что-то еще невиданное.
Hige (28.07.2013 в 20:22):
Здравствуйте! Вот к кому можно обратиться, может вам интересно будет. У меня есть какой-то уникальный архиватор одного чуть-ли не советского НИИ, работает исключительно под DOS, формат файлов никому кроме этого архиватора неизвестен. Если интересно, могу выложить.
ManHunter (22.04.2013 в 16:12):
В первой части я упомянул, откуда пошла эта тема. Да, по молодости баловался вирусней, был грешок :) Но лично мне будет жалко, если пропадут интересные наработки, все-таки я на них угрохал кучу времени, хоть и много лет назад.
Андрей (22.04.2013 в 16:08):
Вспомнились вири пихающие свою тушку в архивы...
Новый виток ? :)
lammer (22.04.2013 в 03:13):
Проверид все CRC32 полиномы из Wiki: CRC-32/Castagnoli/Koopman/32Q
во всех трех вариантах: Normal/Reversed/Reversed reciprocal (http://en.wikipedia.org/wiki/Cyclic_redundancy_check) - ни один не найден.
ManHunter (21.04.2013 в 23:54):
Да уж, видимо все-таки придется расчехлять досовский инструментарий для реверса :(
lammer (21.04.2013 в 23:50):
Если контрольная сумма CRC32, то неважно как именно она вычисляется.

Глянул наспех в версию 1.2
Вот эта строчка явно должна помочь с локализацией (поставить брэйк в старом SI):
seg002:25B3                 db 'File failed CRC-32 check

И еще есть, по крайней мере, парочка странных мест с "rcr" - маловероятно, чтобы это имело отношение к компресии.
ManHunter (21.04.2013 в 23:20):
Второй день сижу и медитирую на листинг. Это какая-то модификация CRC-32, пока не могу понять какая.
lammer (21.04.2013 в 23:16):
Кхе, надо было обновить страницу перед ответом :-(

Судя по тому, что CC там ничего не находит, стандартные полиномы CRC16 не использованы, т.е, кроме реверса ничего не поможет. Была, кажется, статья о ChArc в Компьютерре, но вряд ли там вдавались в детали формата. Исходный код, видимо, никогда не выкладывался.

Единственное, что могу посоветовать (если там в самом деле есть поле контрольной суммы), искать в диз.асм-листинге алго расчета хэша. Как это должно выглядеть, сказать трудно, но когда видишь в листинге хэш, его ни с чем не спутаешь :-)
lammer (21.04.2013 в 23:06):
Вот здесь есть три версии (без исходников): http://old-dos.ru/index.php?pa...=show&id=146
У меня, судя по каталогу компактов, те же версии.
ManHunter (21.04.2013 в 22:47):
lammer, сам архиватор у меня есть, даже три разных версии. А вот алгоритм подсчета CRC ни выдернуть, ни опознать пока не получается.
lammer (21.04.2013 в 22:46):
ChArc рекламировался через "СофтПанораму" и им же паковались ее последние выпуски. Компрессия была на уровне Lharc. Я пороюсь в старых компактах, если найду что-нибудь, дам ссылку.
ManHunter (21.04.2013 в 13:24):
Лучше подскажите где можно найти описание формата ChArc (1990 СП "Диалог", Научный центр при ВЦ АН СССР). По готовым архивам идентифицировал все нужные поля, но не могу найти как считается CRC файла :(
Super_DJ (21.04.2013 в 13:16):
Я бы дополнил про ACE. Формат был сильно популярен до появления 7z (до тех пор как он стал популярен и стабилен). Почти поголовно его применяли пираты 2000-2005 года. А так же из плюшек было то что антивирусы нормально читать его архивы научились как и 7z году так 2006-му.
lammer (21.04.2013 в 00:58):
ACE - когда только появился - был очень популярен среди любителей "рюшечек", так как по степени сжатия шел примерно наравне с RAR, а интерфейс последнего был в то время еще более убогим. Но коммерческого интереса, видимо, не вызвал и все остановилось, кажется, на версии 2.6 (судя по ссылкам на файлопомойках, существует и 2.6.9, но мне помнится, что популярна была только 2.5)

Добавить комментарий

Заполните форму для добавления комментария
Имя*:
Текст комментария (не более 2000 символов)*:

*Все поля обязательны для заполнения.
Комментарии, содержащие рекламу, ненормативную лексику, оскорбления и т.п., а также флуд и сообщения не по теме, будут удаляться. Нарушителям может быть заблокирован доступ к сайту.
Наверх
Powered by PCL's Speckled Band Engine 0.2 RC3
© ManHunter / PCL, 2008-2024
При использовании материалов ссылка на сайт обязательна
Время генерации: 0.11 сек. / MySQL: 2 (0.0125 сек.) / Память: 4.5 Mb
Наверх