Pkzip server for windows что это
Итак, этот цикл расшифровывает код, находящийся в интервале начальный сегмент:[0178h..03E4h]. Причем пока его работа не закончена полностью, мы не можем ставить точки останова (F4) в этом интервале, поскольку цикл расшифровки уничтожит эти точки, и мы будем вынуждены трассировать этот довольно значительный цикл пошагово F7(F8). Также мы не сможем ставить точки останова прямо в оригинальный код pkunzip, поскольку он станет доступен только после его распаковки подпрограммой PKLITE. Рассмотрим более детально, как это происходит: дождемся сначала расшифровки кода от адреса 0178:
rep movsw ; Копировать тело распаковщика PKLITE в последний сегментТаким образом, мы видим, как стартовый цикл расшифровки декриптует код PKLITE, который в свою очередь перебрасывает свое тело в сегмент после упакованного оригинального кода pkunzip и переходит на него. Поскольку при исследовании pkunzip предполагается многократная его загрузка в отладчике, то проще не выполнять каждый раз процедуру декриптования, а сразу (небольшой программкой, повторяющей действия декриптора) расшифровать код, не забыв удалить код декриптора (он исказит нам расшифрованный код). Алгоритм примерно следующий: найти в pkunzip начало зашифрованного кода (байты E6h,59h,BCh. по смещению в файле 00D8), декриптовать их аналогично оригинальному декриптору, дезактивировать код декриптора (например, заменить команду декриптора mov [si],ax на два nop'а: 89h,04h->90h,90h).
Если после такого изменения pkunzip'а загрузить его в отладчик, то можно сразу ставить breakpoint на любую команду PKLITE с адреса 0178 кроме модифицирцуемой команды retf 8CFD - например, на rep movsw.
Трассируя далее уже код PKLITE переходим вслед за ним в последний сегмент и видим, как он начинает распаковывать код pkunzip:
Трассировать код PKLITE также довольно утомительное занятие. Хотелось бы сразу установить прерывание в то место, когда его код полностью отработал и осталось только перейти на распакованный код pkunzip. Как правило, межсегментный переход реализуется с помощью команд retf, jmp far, причем он должен располагаться сразу после всех циклов распаковки PKLITE. Действительно, пролистав вниз код, обнаруживаем такой переход:
; В основном сегменте(cs) pkunzip после его распаковки call 70D4:0004 ; Дальний вызов из вспомогательного модуляОбнаруживаем, что процедура 071E запрашивает пароль - в первом приближении интересующий нас код находится внутри 071E или далее. Установить способ получения пароля можно следующим способом: простая резидентная программа, перехватившая некий набор функций прерывания int 21h или int 16h должна "всплыть", если pkunzip будет использовать одну или несколько функций из этого набора. В данном случае pkunzip'ом используется функция 08h int 21h. Сжимая далее круг поиска, обнаруживаем следующий интересный кусок кода:
; Описание структуры заголовка файлов *.zip и алгоритма проверки пароля . After the header is decrypted, the last 1 or 2 bytes in Buffer should be the high-order word/byte of the CRC for the file being decrypted, stored in Intel low-byte/high-byte order. Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is used on versions after 2.0. This can be used to test if the passwordИтак, из документа следует, что для проверки пароля необходимо сравнить последний байт(слово) некоего расшифрованного буфера с старшим байтом(словом) crc, содержащимся в заголовке файла. Однако мы видим, что в зависимости от некоторго бита (по всей видимости, находящимся в элементе "general purpose bit flag" заголовка) сравнение может быть проведено совсем не с crc, а с старшим байтом времени ("last mod file time").
Остается найти код, формирующий "второй параметр" сравнения - байт в ячейке [BCA9]. В отладчике td нет возможности установить "breakpoint at memory access" (точку прерывания при обращении к памяти), но можно применить все тот же метод "последовательной локализации", только индикатором будет служить изменение (визуальное) ячейки [BCA9]. Для этого необходимо указать отладчику в окне "data" отображать указанную ячейку и, сделав это в момент начала выполнения кода pkunzip'а, следить за ней во время трассировки. Разумным предположением в смысле экономии усилий будет начать поиск с "близлежащего" от места проверки правильности пароля - а именно, подпрограммы 7566. Именно в ней мы и находим сначала следующий код, использующий пароль:
; Подпрограмма использования пароля для изменения им 12 байтного буфера (buff12) ; А также подпрограмма модификации байтом(в al) 12 байтного буфера (buff12)Грубо говоря, каждый символ пароля последовательно передается на вход процедуре add_seg:082A, которая использует его для последовательного изменения трех двойных слов в буфере [0BDF4]. К моменту начала добавления пароля буфер инициализируется значениями 12345678h, 23456789h и 34567890h (оригинальный код не приводится). Мы назовем эти три двойные слова "buff12". При этом используется добавочная таблица размером в 100h двойных слов (см. команды типа xor eax,cs:[edx*4+ecx], размер следует из того, что индекс (edx) всегда меньше 256). Небольшой промах компилятора (xor ecx,ecx, use ecx как базу) не помешает нам понять расположение этой таблицы в памяти - а именно, в сегменте кода дополнительного модуля. Видимо, к основной программе был подключен модуль с функциями криптования, выполненными в far call стиле и активно использующими инструкции 386 процессора. Действуя так же, как и при поиске вышеприведенного кода, пытаемся обнаружить процедуру инициализации добавочной таблицы (назовем ее XOR-таблицей) - хотя бы ориентируясь на факт ее заполнения. Если проявить чрезмерную осторожность и начать следить за ее изменением с самого начала работы программы, то можно обнаружить любопытный факт: таблица заполняется дважды и оба раза . неодинаково ! Первый раз (оригинальный код пропущен) это делается на базе инструкций 8086 процессора, далее следует проверка текущего типа CPU и таблица переинициализируется с использованием инструкций 386 процессора:
Можно предположить гипотетическую ситуацию: файл был заархивирован с паролем на машине 8086, а расшифровывается на 386-ой. Тогда он . не может быть расшифрован !
Чтож, любопытно, однако перейдем к финальной части проверки пароля. Нам осталось выяснить, как формируется байт в [BCA9] и как при этом используется вышеприведенный набор из трех двойных слов, измененных паролем. Прежде всего замечаем, что немного ранее кода изменения двойных слов buff12 (метка 7554) в буфер [BCA9-(0Ch-1)] заносятся те самые двенадцать байт из zip-файла (Hash), которые после изменения двойных слов паролем также модифицируются подпрограммой 2938:
; Подпрограмма использования файлового Hash после использования пароля. mov ax,[BDFC] ; Фактически, младший байт третьего двойного слова call add_seg:07CA ; Опять изменить buff12 байтом из alТаким образом Hash преобразуется (дешифруется) и последний байт его сравнивается либо с старшим байтом crc, либо со старшим байтом временем файла.
Последнее, что осталось рассмотреть - это способ расшифровки потока данных. При его поиске можно, например, опираться на следующие предположения: вероятно, код расшифровки начинает работать после проверки правильности пароля (условный переход на метку 18B2), вероятно, что расшифровкой занимаются подпрограммы дополнительного модуля, аналогичные или совпадающие с приведенными выше - как только в программе встретится дальний вызов подпрограммы из этого модуля, это должно вызвать подозрения. Собственно говоря, процедура расшифровки Hash сама по себе уже является кандидатом на "расшифровщик" потока данных. Действительно, если "на всякий случай" установить breakpoint в ее начало , то он сработает ! Дампируя содержимое памяти по адресу в es:di (адрес дешифруемых байт), идентифицируем их с байтами файла, лежащими следом за Hash файла: процедура дешифровки данных - это тот код, который ранее расшифровал Hash.
Итоговое описание алгоритма проверки пароля с выдержками из авторского описания (APPNOTE.TXT)
Итак, приводим описание алгоритма проверки пароля и дешифровки данных.
Сначала программа запрашивает пароль. Это осуществляется при помощи функции 08h прерывания 21h. Для нас важно то, что эта функция не позволяет вводить символы с следующими кодами: 0,3,8,13,16,19,27.
Инициализируются три двойных слова следующими значениями: 12345678h, 23456789h и 34567890h:
При рассмотрении защиты под отладчиком Keys мы назвали buff12.
Используя пароль, изменяем эти Keys (оригинальный код приведен выше и носит название "Подпрограмма использования пароля для изменения им 12 байтного буфера (buff12)" и "Подпрограмма модификации байтом 12 байтного буфера (buff12)"):
Where crc32(old_crc,char) is a routine that given a CRC value and a character, returns an updated CRC value after applying the CRC-32Способ получения crc32(XOR-таблицы) приведен выше и носит название "Подпрограмма инициализации XOR-таблицы".
Дешифруется буфер из 12 байт, расположенных в zip-файле сразу за именем упакованного файла (ранее мы дали ему название Hash):
The purpose of this step is to further initialize the encryption keys, based on random data, to render a plaintext attack on the Read the 12-byte encryption header into Buffer, in locations10^19, то, даже имея однозначное правило проверки пароля (или соответствующего ему состояния Key), невозможно за приемлимое время перебором всех вариантов обнаружить верный пароль. Если же число возможных состояний состовляет, например, 256^5
10^12 вариантов, то при скорости проверки паролей в 10^5 паролей в секунду имеет смысл выполнять такой подбор. Необходимо только знать критерий проверки пароля, оставляющий конечное число кандидатов в пароли (чтобы можно было проверить их вручную за конечное время) - например, 10000 или немногим более.
Вряд ли, однако, число состояний Key состовляет менее 256^6, что делает бессмысленным полный перебор всех возможных паролей (Key) даже при наличии критерия проверки пароля. Косвенным доказательством служит следующий опыт. Будем подавать на вход процедуре update_keys различные пароли и следить за выпадением первых четырех байт (двойное слово) в интервале от 0 до 255 (или любом другом). Например, в моем опыте подавались пароли из символов от "A" и до конца таблицы длиной от единицы и выше. В результате после подачи
7*10^8 таких паролей выпало не менее
40 Key со значением первого двойного слова в интервале 0..255, из чего можно сделать оценку (очень грубо), что существует не менее 40/256
1/8 состояний Key от максимально возможного (256^12).
Альтернативой алгоритму перебора является получение пароля по следам его использования. В нашем случае пароль используется единожды при изменении начального состояния Key и единственное место, если не считать расшифровку данных, где он проявляет свои свойства - это заданное значение последнего байта расшифрованного "encryption header".
Поток состояний Key, сформированных множеством возможных паролей, способен образовать практически псведосучайные последовательности в виде расшифровки encryption header, следовательно, примерно на каждые 256 входящих паролей один окажется верным с точки зрения алгоритма проверки. Следовательно, даже если бы число возможных состояний Key было конечным, порядка 256^5, мы бы смогли уменьшить число возможных Key не более чем в 256 раз. Вот если бы мы знали исходное состояние encryption header, то мы бы могли практически однозначно проверить любой пароль, либо попытаться получить пароль по результату шифрования исходного состояния. Авторами подчеркивается, что исходное состояние encryption header - это псевдосучайный набор байт.
Так ли это на самом деле ? Проверим это утверждение и найдем отладчиком код, формирующий случайные байты encryption header. Для этого нам придется трассировать уже pkzip (модуль упаковки), правда, по сходной схеме с pkunzip. Вот этот код:
Основная информация о программе
PKZIP – это небольшая, но очень полезная утилита, главной задачей которой является архивирование (сжатие) файлов и распаковка архивов различных форматов. При этом программа сжимает данные, не теряя и не нарушая содержимого самих файлов.
Являясь основоположником формата ZIP, компания PKWARE продолжает в своих программах следовать устоявшимся традициям. Интерфейс программы прост и интуитивно понятен. Перед запуском процесса компрессии файлов, пользователь может выбрать для будущего архива один из трех типов сжатия. В программу включена поддержка множества форматов сжатия, в числе которых ZIP, TAR, BZ2, GZIP, UUEncode, XXEncode, Jar, OpenPGP, TAR BZIP2 и TAR GZIP.
Из дополнительных функций можно выделить возможность архивирования файлов, начиная с определенной даты, разделение архива на части равного размера, сохранение в архиве атрибутов файлов (таких как "скрытый" и "только для чтения") и множество других. В заключение стоит отметить нетребовательность программы PKZIP к мощности процессора и объему оперативной памяти.
PKZIP - это компьютерная программа для архивирования файлов , известная тем, что представляет популярный формат файлов ZIP . PKZIP был впервые представлен для MS-DOS на платформе, совместимой с IBM-PC, в 1989 году. С тех пор были выпущены версии для ряда других архитектур и операционных систем. Первоначально PKZIP был написан Филом Кацем и продавался его компанией PKWARE, Inc , причем оба они носили его инициалы: «PK».
СОДЕРЖАНИЕ
История
К 1970-м годам программы архивирования файлов были распространены как стандартные утилиты с операционными системами. К ним относятся утилиты Unix ar, shar и tar . Эти утилиты были разработаны для сбора нескольких отдельных файлов в один архивный файл для упрощения копирования и распространения. Эти архивы при желании могут быть переданы через служебную программу компрессора потока, такую как compress и другие.
Другие архиваторы также появились в течение 1980-х годов, в том числе ARC от System Enhancement Associates, Inc. (SEA), ZOO Рахула Дхеси , DWC Дина В. Купера, LHarc от Харухико Окомуры и Харуясу Йошизаки и ARJ, что означает «Архивировано Робертом Юнгом».
О разработке PKZIP было впервые объявлено в файле SOFTDEV.DOC из пакета PKPAK 3.61, заявив, что будет разработана новая, но пока еще не названная программа сжатия. Объявление было сделано после судебного процесса между SEA и PKWARE, Inc. Хотя SEA выиграла иск, она проиграла войну за сжатие, поскольку пользовательская база перешла на PKZIP в качестве предпочтительного компрессора. Под руководством сисопов BBS, которые отказались принимать или предлагать файлы, сжатые как файлы .ARC, пользователи начали повторно сжимать любые старые архивы, которые в настоящее время хранились в формате .ARC, в файлы .ZIP.
Первая версия была выпущена в 1989 году в виде инструмента командной строки DOS , распространяемого по модели условно-бесплатного программного обеспечения с регистрационным взносом 25 долларов США (47 долларов США с руководством).
История версий
PKZIP
Формат файла .ZIP
У спецификации есть собственный номер версии, который не обязательно соответствует номерам версий PKZIP, особенно для PKZIP 6 или более поздних версий. В разное время PKWARE добавляет предварительные функции, которые позволяют продуктам PKZIP извлекать архивы с использованием расширенных функций, но продукты PKZIP, которые создают такие архивы, не будут доступны до следующего основного выпуска.
Совместимость
Несмотря на популярность в то время, ZIP-архивы, использующие методы сжатия PKZIP 1.0, сейчас встречаются редко, и многие инструменты для распаковки, такие как 7-Zip , могут читать и записывать несколько других форматов архивов.
Патенты
При сжатии используется динамический LZW , на который Unisys владеет патентами. Патент на алгоритм уменьшения также был подан 19 июня 1984 года, задолго до того, как был выпущен PKZIP.
Первая версия программы вышла в 1989 и была сравнительно популярной. Программа могла использовать три алгоритма сжатия: «shrinking», «reducing» и «imploding». На сегодняшний день файлы в формате PKZIP 1 встречаются очень редко, и большинство других программ сжатия не поддерживают «shrinking» и «reducing».
В 1993 появилась версия PKZIP 2, имеющая только один новый алгоритм (однако с несколькими уровнями сжатия), который автор назвал «deflating». Новый алгоритм (позже формально описанный в RFC 1951) использовал комбинацию LZ77 и алгоритма Хаффмана, был практически свободен от патентов, и стал одним из самых популярных алгоритмов сжатия в операционных системах Windows и в Internet.
В 1999 компания выпустила последнюю версию 2.50 программы для MS-DOS. Последующие версии программы будут работать только под Windows и различными версиями Unix, и будут называться PKZIP for Windows или PKZIP for Server.
См. также
ALZip • Archive Utility • MacBinary • PowerArchiver • Squeez • StuffIt • WinAce • WinRAR • WinZip
ARC • ARJ • JAR • bzip2 • compress • gzip • Info-ZIP • LHA • lzip • lzop • PAQ • PKZIP • RAR • SBC • UPX
- Программное обеспечение по алфавиту
- Архиваторы
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое "PKZIP" в других словарях:
PKZIP — [engl. zip »Reißverschluss«], ein Komprimierungsprogramm der Firma PKWARE Inc. in Brown Deer (Wisconsin, USA), mit dem beliebige Dateien komprimiert und in sog. komprimierte Archive verpackt (»gezippt«) werden können. Von PKZIP erzeugte Archive … Universal-Lexikon
PKZIP — A very popular file compression utility available as shareware. PKZIP not only compresses files to save disk space or cut modem transmission times, but also combines compressed files to create compressed archives. See also PKUNZIP; WinZip … Dictionary of networking
Pkzip — … Википедия
pkzip — ZIP Shareware Komprimierungsprogramm, hauptsächlich auf PC Architektur, implementiert von Phillip Katz … Acronyms
Pkzip — ● np. m. ►PACK Grand classique du petit utilitaire mondialement utilisé, permettant d exploiter la compression Zip … Dictionnaire d'informatique francophone
Читайте также: