Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор - Часть 2

Модерирует : gyra, Maz

Widok (07-09-2009 19:15): Лимит страниц. Продолжаем здесь.  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102

   

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей


Официальный сайт | Скриншоты | Скачать
Документация на консольную версию | Документация на GUI версию
Сообщество пользователей FreeArc | Вики | Трекер (рассылка по ошибкам)
Проект на SourceForge.net | SVN-репозиторий | Поддержка InnoSetup
Обсуждение на encode.ru (англоязычное)

Скачать последний релиз - FreeArc 0.51 от 28 апреля 2009 г. Что нового: GUI с 14 локализациями, SFX/инсталятор, авто-определение типов файлов, очередное увеличение скорости и сжатия, словарь в lzma до 1 гб, исправлено 5 ошибок (рас)паковки (подробнее)
 
Текущая альфа версия: скачать (распаковывать поверх установленного FreeArc 0.51). Список исправлений, блог

MiniFAQ...

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Планы дальнейшего развития
Что подразумевается под "интеграцией с Explorer"
Старая FreeArc wiki (включая описание формата архива)
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оболочки для работы с FreeArc
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip - менеджер архивов с поддержкой большого количества форматов, для Windows и Linux

Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 12:02 30-01-2009 | Исправлено: Bulat_Ziganshin, 22:15 30-08-2009
crotoff

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Giesmos
Отличная идея! Мож, записать в issues? Как это будет по-английски?
 
Добавлено:
Bulat_Ziganshin
кстати, подумалось о внешних и внутренних компрессорах... для чего понадобилось встраивать "внутренние" методы в arc.exe, ведь существуют консольные аналоги rep, dict, lzp и т.п. Не проще ли было покидать исполняемые файлы в bin и вызывать их по мере надобности? И удобнее было бы совершенствовать методы - допустим появился lzma2 - просто закинули lzma2.exe в папочку и прописали его в arc.ini, а сам arc.exe остался бы неизменным. И насчёт обратной совместимости голова не будет болеть. Если в дальнейших планах полноценная поддержка внешних компрессоров в SFX - то так ведь легче будет. К SFX модулю приклеятся только те упаковщики и препроцессоры, которые были использованы при создании архива, и в этом ракурсе неважно будет - "свои" они или разработаны левыми людьми

Всего записей: 961 | Зарегистр. 17-04-2007 | Отправлено: 23:16 23-05-2009 | Исправлено: crotoff, 23:37 23-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
http://encode.ru/forum/showpost.php?p=7422&postcount=1089
 
новая версия all2arc:
 
2009-05-23 v0.5
    Preliminary Unicode support
    Added processing of multiple archives at once ("all2arc.exe -- archive1.rar archive2.7z")
    Possibility to pass arguments to FreeArc ("all2arc.exe -mx -md128 archive1.rar")
    Compilation parameters improvements, resulting in smaller file (thanks Bulat)
    Showing errors/questions in GUI through MessageBox
    Improved check for existing archives
    Improved cleaning up of temp folders in case of failure

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 00:41 24-05-2009
ICESCREAM



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
 
И насчёт обратной совместимости голова не будет болеть. Если в дальнейших планах полноценная поддержка внешних компрессоров в SFX - то так ведь легче будет. К SFX модулю приклеятся только те упаковщики и препроцессоры, которые были использованы при создании архива, и в этом ракурсе неважно будет - "свои" они или разработаны левыми людьми

Это обсуждалось на compression.ru в самом начале.

Всего записей: 164 | Зарегистр. 28-07-2006 | Отправлено: 04:29 24-05-2009
crotoff

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ICESCREAM
пролистал темы FreeArc 0.36, FreeArc 0.40, нашёл только упомянутые вскользь похожие моменты

Цитата:
Nabljudatel писал(а):
кстати, скоро там версия 0.4? а то формат архива планируется пометь. Будет ли обратная совместимость?
 
пока что да. в этой версии формат архива не изменится, только добавятся алгоритмы сжатия и будет полная обратная совместимость. планирую..


Цитата:
У меня есть несколько вопросов.
1.А почему ECM обяательно должен быть внешним? Вроде, исходники есть... Или времени нет, нужно сначала выпустить финальную версию, а потом добавить ?
2. BCJ2 нет, как я понимаю, потому, что у него 4 выходных потока?

Возможно оттого что встроенные методы быстрее работают или ещё из каких соображений, просто интересны были мотивы автора

Всего записей: 961 | Зарегистр. 17-04-2007 | Отправлено: 10:44 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
для чего понадобилось встраивать "внутренние" методы в arc.exe, ведь существуют консольные аналоги rep, dict, lzp и т.п. Не проще ли было покидать исполняемые файлы в bin и вызывать их по мере надобности? И удобнее было бы совершенствовать методы - допустим появился lzma2 - просто закинули lzma2.exe в папочку и прописали его в arc.ini, а сам arc.exe остался бы неизменным. И насчёт обратной совместимости голова не будет болеть. Если в дальнейших планах полноценная поддержка внешних компрессоров в SFX - то так ведь легче будет. К SFX модулю приклеятся только те упаковщики и препроцессоры, которые были использованы при создании архива, и в этом ракурсе неважно будет - "свои" они или разработаны левыми людьми

 
1. вызов внешних программ - довольно медленное удовольствие. если для распаковки 5-килобайтного файла потребуется вызвать 4 внешних проги - это будет не очень здорово
 
2. первоначально arc.exe был самодостаточен, это сейчас появилась целая куча файлов которые так и так нужно тащить за собой
 
3. сама идея внешних упаковщиков появилась гораздо позже
 
4. до сих пор внешние упаковщики поддерживают далеко не все возможности, которые есть у внутренних. кстати, есть ещё и CLS  
 
5. sfx с внешними упаковщиками пока тоже не поддерживаются, а авто-подклеивание не стоит даже в планах. кстати, хорошая идея - сделать один "пустой" базовый sfx, а всё остальное добавлять к нему по необходимости в виде dll, включая инсталлер, gui, поддержку linux...

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:03 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
crotoff
May be...
Arc.exe and freearc.exe execute PATH command in console mode (before call preprocessors and etc.). PATH set paths to preprcessors and etc.

Цитата:
Не проще ли было покидать исполняемые файлы в bin и вызывать их по мере надобности?

А не отразится ли это сильно негативно на производительности? Разве что сам FA будет определять типы файлов (например, по заголовкам), а после передавать по группам различным прероцессорам, препаковщикам и пр., после чего производить уже, непосредственно, объединение в один архив. При создании sfx, в комплект должны будут "докладываться" используемые для данного архива препроцессоры и пр.
Для больших объемов данных - это было бы отличным решением. Но что делать с архивом в мару МБ, если для его упаковки будет применено с десяток препроцессоров (допустим)? Если же не создавать "автономные" sfx, то встает проблема совместимости с более ранними версиями - так не очень-то "наобновляешься".
Если же подобное реализовать, то стоит сделать обязательно опцию включения используемых при упаковке препроцессоров внутрь архива, в какую-нибудь скрытую область, чтобы они при распаковку помещались во временную папку или вызывались напрямую (как в приложениях виртуализации, вроде thinstall). И тогда бы еще было бы логично что-то делать с прогресс-баром, какм-то образом свзязывать его с внешними модулями, которые, в свою очередь, эстетичнее было бы не отображать на экране.

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 12:22 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
добавил http://code.google.com/p/freearc/issues/detail?id=79
 

Цитата:
Я как раз говорю о том, чтобы сам архиватор, при запуске командной строки, указывал бы пути. Т.е. выполнял команду PATH, где указывал бы папки с препроцессорами и пр.

http://code.google.com/p/freearc/issues/detail?id=78
 

Цитата:
1) Сейчас упаковка большого количества файлов идёт порциями по 20 тыс штук - если увеличить порцию до 100 тыс штук, то явно размер требуемой памяти будет больше?  

сейчас программа составляет полный список файлов, сортирует его, затем бьёт на куски по 20к, и каждый кусок попадает в отдельный directory block. это позволяет уменьшить память для распаковки, не более того
 

Цитата:
3) Можно ли данную опцию выставить в ГУИ или нужно прописывать её руками (например, в ГУИ в дополнительных параметрах)?

вручную
 

Цитата:
-mrep:1g
в логе
tempfile+rep:1gb
блок 1024м - есть, 256m -нет.
должен был сразу скинуть настройки, зачем tempfile?  

счас посмотрю
 
Добавлено:

Цитата:
Если же подобное реализовать, то стоит сделать обязательно опцию включения используемых при упаковке препроцессоров внутрь архива, в какую-нибудь скрытую область, чтобы они при распаковку помещались во временную папку или вызывались напрямую (как в приложениях виртуализации, вроде thinstall).

так делать нельзя - это прямая дорога вирусам. полноценную виндовую VM встроить не предлагайте

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:22 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
1. вызов внешних программ - довольно медленное удовольствие. если для распаковки 5-килобайтного файла потребуется вызвать 4 внешних проги - это будет не очень здорово  

Ввести "границы" применимости внешних модулей, основываясь на количестве, размерах и типах файлов. Например, если в архивируемой папке всего пара-тройка txt, общим объемом в десяток кБ и еще 1 jpeg на полсотни, то FA не будет вызывать ppmonstr и packjpg. "пороговые" значения можно рассчитывать, основываясь, к примеру, на размерах самих применяемых модулей. Допустим, если мы пакуем пяток МБ чистого текста, то включение в состав ppmonstr будет нивелировано повышением степени сжатия на объем больше 75 кБ, занимаемых модулем.

Цитата:
2. первоначально arc.exe был самодостаточен, это сейчас появилась целая куча файлов которые так и так нужно тащить за собой  

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

Цитата:
4. до сих пор внешние упаковщики поддерживают далеко не все возможности, которые есть у внутренних. кстати, есть ещё и CLS  

Можно чуть подробнее, из-за чего так? И о каких возможностях идет речь?

Цитата:
5. sfx с внешними упаковщиками пока тоже не поддерживаются, а авто-подклеивание не стоит даже в планах. кстати, хорошая идея - сделать один "пустой" базовый sfx, а всё остальное добавлять к нему по необходимости в виде dll, включая инсталлер, gui, поддержку linux...  

Чего уж мелочиться? Сделать сразу кросс-платформенное приложение с автоматической компиляцией под любую ОС и процессор
А если черьезно, включение внешних модулей в архива - это такая плохая идея? В чем именно ее критические недостатки, которые перекрывают (гипотетически) положительные стороны?

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 12:40 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Ввести "границы" применимости внешних модулей

ты готов провести исследования всех упаковщиков на предстапвительном объёме данных и расписать полностью этот алгоритм?
 

Цитата:
Можно чуть подробнее, из-за чего так? И о каких возможностях идет речь?  

потому что не сделано. например, выбор словаря по объёму памяти
 

Цитата:
А если черьезно, включение внешних модулей в архива - это такая плохая идея?

в архив - плохая, в sfx - хорошая

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:49 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
так делать нельзя - это прямая дорога вирусам. полноценную виндовую VM встроить не предлагайте

От вирусов поможет защита хэшированием модулей и, может быть, даже самого архива. А если уж, мало ли каким чудом, модули в архиве оказались заражены, то обязательно указывать версии используемых при упаковки модулей, чтобы можно было всегда распаковать с использованием внешних версий.
 
А скрытую обдасть, я имел ввиду область архива. Необязательно делать ее совершенно невидимой, просто сделать так, чтобы модули не распаковывались прямо в п туже папку, что и остальные файлы, или, по крайней мере, сразу оттуда удалялись по окончанию процедуры. Полностью скрывать не стоит еще из-за того, что если очень понадобится, чтобы можно было вытащить модули из состава наружу.
 
Кстати, одно из преимуществ thinstall-приложений в том, что они могут работать только в своей "песочнице", хоть с вирумаси, хоть без, не угрожая реальной системе, тоже самое верно и наоборот.
 
Полноценная виндовая VM пока есть только в Windows 7

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 12:50 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами
 

Цитата:
Кстати, одно из преимуществ thinstall-приложений в том, что они могут работать только в своей "песочнице", хоть с вирумаси, хоть без, не угрожая реальной системе, тоже самое верно и наоборот.  

вот для этого и надо иметь встроенную VM

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:54 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
ты готов провести исследования всех упаковщиков на предстапвительном объёме данных и расписать полностью этот алгоритм?

С удовольствием. Только диплом допишу
Я серьезно.

Цитата:
выбор словаря по объёму памяти  

Доступной системной или выделенной для конкретной степени сжатия?

Цитата:
в архив - плохая, в sfx - хорошая  

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

Цитата:
нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами  

Каким образом? Предположим, моя машина заражена вирусом, добавляющим свой код ко всем exe-файлам. Я создаю архив с помощью FA, с применением внешних модулей (да, пусть это бутет архив фоток в jpg). Можно сделать проверку хэшей уже при упаковке. Изначально FA известны хэши модулей и самого себя (самый примитивный, но далеко неидеальный вариант - прописывание хэшей в arc.ini - неидеальный, потому что слишком легко изменить, хотя, если кто-то захочет засунуть внутрь зараженный файл, думаю, это у него в любом случае получится). Если при проверке, хэш не сходится, то FA выдает предупреждение об этом.
Тоже самое должно происходить при распаковке (есть же проверка CRC у sfx рара и я ее на себе уже испытывал...). Т.е. если FA при попытке распаковки sfx определяет, что хэш не сходидся, то выдается сообщение о повреждении архива и (может еще предложить распаковать с помощью внешних, заведомо незараженных, модулей). 100% защиты от вирусов не бывает, в любом случае.

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 12:59 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
есть надёжный механизм - цифровые подписи, основанные на асимметричном шифровании. т.е. зашифровать/создать подпись могу только я (зная закрытый ключ), а расшифровать/проверить подпись - любой, знающий открытый ключ (этот ключ просто вшивается в fa)
 
но таким образом можно распространять только модули, которые я сам написал/проверил, т.е. полной автономности от меня не будет. у нас кстати была в своё время мысль - загружать недостающие модули вообще по инету

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 13:16 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами  

Если же речь идет о W32/Perrun, но тоже самое произойдет при использовании любого из существущих архиваторов. При использовании внешних модулей, вполне возможно, этого как раз получится избежать. Я не уверен, что зараженный W32/Perrun jpeg также легко переварится packjpg, как и незараженное изображение.

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 13:18 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
100% защиты от вирусов не бывает, в любом случае.

как ни странно, сейчас любые типы архивов 100%-но защищены от того, что при их распаковке машину могут заразить вирусы

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 13:20 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

есть надёжный механизм - цифровые подписи, основанные на асимметричном шифровании. т.е. зашифровать/создать подпись могу только я (зная закрытый ключ), а расшифровать/проверить подпись - любой, знающий открытый ключ (этот ключ просто вшивается в fa)  
Это надежно, но, как выходит, не панацея. Под рар уже появился киген, с которым можно подписывать архивы электронной подписью, что было невозможно ранее. Точно неизвестно, каким образом это получилось, но факт...
Просто интересно, каким образом защищаются от вирусов инсталляторы, упаковщики и др.? Да и если моя машина заражена, а в архив я положу не только безобидные txt, но и уже рараженные PE-файлы, то толку от цифровой подписи никакой не будет. Кстати, ведь если я заражу sfx модуль рара или 7z, то будет, фактически, тоже самое.
 
Добавлено:

Цитата:
как ни странно, сейчас любые типы архивов 100%-но защищены от того, что при их распаковке машину могут заразить вирусы

Обычные - да, sfx - нет.
Но с "внедрением" модулей в обычные архивы, вроде бы, разобрались, что так делать не стоит, т.к. алгоритмы упаковщиков и препроцессоров меняются очень редко.
 
Добавлено:

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

Интересная мысль. А почему ее не "превратили" в своеобразный web-update?
 
Кстати, что касается совместимости старых и новых версий (в случае, если нужно обновлять модули или сам FA для распаковки). К примеру, разные версии архивов образов, созданных Acronis True Image далеко не всегда (мягко говоря) открываются всеми версиями. И ничего - пользователей от этого как-то не убывает. Я не призываю к намеренному внесению такого рода изменений, но это не так ужасно. Рар, в свое время тоже пержил переход на третью версию, несовместимую со старыми (меньше 2.80). И 7z сейчас вводит LZMA2, несовместимый со тарыми версиями. И тоже это воспринимается почти в порядке вещей.

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 13:29 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

взломать асимметричное шифрование - невозможно. что сделано в раре и что там на самом деле взломали - я не в курсе
 

Цитата:
Просто интересно, каким образом защищаются от вирусов инсталляторы, упаковщики и др.? Да и если моя машина заражена, а в архив я положу не только безобидные txt, но и уже рараженные PE-файлы, то толку от цифровой подписи никакой не будет. Кстати, ведь если я заражу sfx модуль рара или 7z, то будет, фактически, тоже самое.  

в том-то и дело, что это две разные вещи. запуская sfx, человек доверяет источнику его получения. распаковывая архив, он должен быть уверен, что это ему ничем не грозит
 
Добавлено:

Цитата:
Интересная мысль. А почему ее не "превратили" в своеобразный web-update?  

прверка новых версий сейчас есть. на большее как всегда не было времени
 

Цитата:
Кстати, что касается совместимости старых и новых версий  

в fa добавляются новые алгоритмы. мы здесь обсуждали именно внешние модули

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 13:37 24-05-2009
Giesmos

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
в том-то и дело, что это две разные вещи. запуская sfx, человек доверяет источнику его получения. распаковывая архив, он должен быть уверен, что это ему ничем не грозит

Я, к примеру, если возможно распаковать любой sfx (даже инсталлер) без его запуска (сторонним ПО) - так и делаю. Если говорить о доверии источнику, но не зря же на очень многих сайтах, откуда что-то можно скачать, пишут, чтобы файлы дополнительно проверялись антивирусами. И если, все-таки, говорить о внедрении внутрь не sfx архива дополнительных модулей, то их хэши должны проверятся самим FA, с помощью которого будет производиться распаковка. И еще, если версий моделей установленного FA хватает для распаковки архива, то внутренние модули (в архиве) не должны затрагиваться.
 
Один момент с заражением exe-файлов... Во-первых, такой тип вирусов встречается в разы реже различных троянов и malware. Во-вторых, симптомы заражения просто не дают спокойно пользоваться ПК (тот же FA должен проверять хотябы свой хэш при запуске, т.к. если заражен хотя бы один exe-файл в папке FA, то будут заражены и все остальные).
...
Вот... Примерный вариант для предотвращения заражения стороннего ПК, разархивирующего не-sfx архив, созданный на зараженном ПК.
 - FA при запуске проверяет свой хэш. Если он не совпадает, то архиватор выдает предупреждение о повреждении файла, возможно вирусом. После чего, использование, потенциально также зараженных внешних модулей зарещается. (т.е. выходит, что на зараженном ПК архив, содержащий возможно зараженные модули, не сделаешь)
 - модули, используемые FA могут иметь расширение, отличное от exe, что значительно уменьшит вероятность заражения.
 - модули, используемые FA могут хранится в zip (или 7z или еще каком-либо) архиве, позволяющем быстро получать доступ к отдельным файлам. (это также кардинально уменьшает вероятность заражения модулей)
 - при распаковке арихива с модулями, FA должен заранее спрашивать, использовать ли эти модули или использовать свои внешние.
 
Такие варианты возможны? Так лучше?
 
Добавлено:

Цитата:
в fa добавляются новые алгоритмы. мы здесь обсуждали именно внешние модули

Я именно о внешних моделях и писал...

Всего записей: 59 | Зарегистр. 21-09-2003 | Отправлено: 13:59 24-05-2009 | Исправлено: Giesmos, 14:03 24-05-2009
4kusNick

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
что сделано в раре и что там на самом деле взломали - я не в курсе

Там закейгенили алгоритм на эллиптических кривых (ECNR):
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
 
Добавлено:
http://aagern.com/blog/2009/03/взлом-алгоритма-цифровой-подписи-winrar/

Всего записей: 343 | Зарегистр. 13-06-2007 | Отправлено: 14:04 24-05-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Я именно о внешних моделях и писал...

ты писал об acronis/rar/7z и на их примере убеждал меня, что можно добавлять новые алгоритмы
 

Цитата:
Я, к примеру, если возможно распаковать любой sfx (даже инсталлер) без его запуска (сторонним ПО) - так и делаю. Если говорить о доверии источнику, но не зря же на очень многих сайтах, откуда что-то можно скачать, пишут, чтобы файлы дополнительно проверялись антивирусами.  

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

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 14:08 24-05-2009
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор - Часть 2
Widok (07-09-2009 19:15): Лимит страниц. Продолжаем здесь.


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru