» FreeArc (часть 4)

Цитата:

В составе программы файл freearc.sfx (и не только он) постоянно определяется как Backdoor.Win32.SdBot.xgi http://www.bit.ly/p5yuoJ

сейчас проверил - модули из 0.666 ни один вирус на VT не детектит, проблемы только у модулей из 0.67


Добавлено:

Цитата:

Так проблема в том, что они детектят как раз таки сам код распаковщика без какого либо .arc архива на хвосте.

да, и я о том же говорю. но причина этого - не в том, что случайно с вредеоносом совпало, а в том что вредонос упаковали в arc-архив, а авирусные аналитики поставили детектирование самого кода sfx вместо кода вируса в архиве

и чтобы реально решить эту проблему - антивирусы должны научиться распаковывать мои архивы

Bulat_Ziganshin, паковал архив с такими параметрами -lc- -msrep:l32+lzma:a1:mfbt4:d250m:fb273:mc1000000:lc8:lp4 и возник вопрос:

фриарк при попытке установи значения d400m выбивает ошибку "невозможно выделить память, необходимую для распаковки...." и параметр сжатия.

У меня 8 гигов оперативки, я так понимаю что эта ошибка возникает из-за неспособности архиватора задействовать полностью всю свободную оперативку. Когда можно ожидать x64 версию?

СНИМАЮ ВОПРОС - УВИДЕЛ ВЫШЕ)))
----------------------------------------------------------------------------------------------------------------------------------
И ещё одно пожелание, профрагер, когда создал SrepInside, модифицировал arc.ini, и таким образом нужно паковать через батник. Если паковать через контекстное меню - архив в итоге не распакуется))

попытался заменить ваш arc.ini на его - архиватор ругается. Пожалуйста, в следующей версии (я сижу на 0,666) добавьте в секции arc.ini
[External compressor:srep] и [External compressor:precomp] строку header = 0

таким образом можно будет паковать из контекстного меню - так имхо удобнее)))

Булат, а предупреждение о превышении размера архива 4 ГиБ и, в результате, отмену вставки SFX-модуля в процессе архивации планируешь добавить, так как винда не поддерживает exe-шники такого размера? Или ещё лучше: создание отдельно SFX-модуля и отдельно data-файла? Также, будет ли многотомность в будущих версиях поддерживать SFX-архивы?

Bulat_Ziganshin

Цитата:

да, и я о том же говорю. но причина этого - не в том, что случайно с вредеоносом совпало, а в том что вредонос упаковали в arc-архив, а авирусные аналитики поставили детектирование самого кода sfx вместо кода вируса в архиве

не сходится. Если бы вирусописатели использовали твой код для распаковки в памяти всоих зверьков, тогда детектились бы и все unarc.dll, unarc.exe и т.д. Если же они исползовали код именно sfx модуля, то распаковка вредоносного кода была бы в отдельный испольняемый exe или dll файл и антивири сжирали бы его, не распаковщик.

coolerru
1. проблемы возникают не с размера ровно 4 гб, и зависят от фрагментации памяти
2. уже. freearc-sfx.exe+freearc-sfx.arc
3. да

Цитата:

-msrep:l32

без l32 сжатие будет лучше

Цитата:

Когда можно ожидать x64 версию?

когда выйдет ghc/win64. пока используй LZMA-x64

Цитата:

Пожалуйста, в следующей версии (я сижу на 0,666) добавьте в секции arc.ini  
[External compressor:srep] и [External compressor:precomp] строку header = 0

давай наоборот, попросим профрагера убрать header = 0? ведь не просто так по умолчанию 1


Добавлено:

Цитата:

Действительно в последней версии стоит

он там стоит уже 4 года

unarc.exe не детектится. а этот "отдельный испольняемый exe файл" детектится ж не по полному содержимому - кому интересны его оверлеи, а по содержимому исполняемой части

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

Добавлено:
ответ от касперов получен оперативно:


Цитата:

Это было ошибочное срабатывание.
Оно будет исправлено.

но честно говоря меня не устраивает. что одну и ту же ошибку допустили 15 антивирусных аналитиков - как-то слабо верится

Добавлено:
... в общем послали они меня

Цитата:

freearc-sfx.exe+freearc-sfx.arc

Прекрасно! Как я понял, нужно просто взять нужный модуль из bin, переименовать его в имя архива (c расширением exe) и держать вместе?


Цитата:

проблемы возникают не с размера ровно 4 гб

Просто WinRAR так пишет. То есть, если в памяти найдётся непрерывный участок нужного размера всё заведётся?

Shuld
занялся я этим rep. вот первые результаты:

сжатие с rep:1g

старый REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%
новый REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%


сжатие с rep:1g+xtor:3

старый REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%
новый REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%


Для сравнения чистый xtor:3

4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%


Т.е. теперь даже на моей машине нет потерь в скорости -m1 от добавления REP, при этом сжатие с REP выше в 1.32 раза

1. да
2. а ты проверь. я лично о деталях особо не в курсе

Bulat_Ziganshin
Цитата:

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

почему-то я сомневаюсь, что магнаты антивирусного бизнеса станут так сразу его добавлять. Формат пока далек от популярности.. Да и на месте вирусостроителей я бы не стал париться с любым файловым форматом хранения данных, использовал бы голые zlib или lzma с не хитрым шифрованием - меньше гемора, меньше шанс, что задетектят, меньше размер конечного продукта..
Еще один аргумент в пользу случайного детекта - основная масса антивирусов на вирустотале детектят его как Trojan-Spy.Win32.Zbot. Можно просто вбить в гугл название и все о нем узнать..Например тут:
http://www.securelist.com/ru/descriptions/6239404/Trojan-Spy.Win32.Zbot.ikh
Как видно из описания размер вируса порядка 60кб, в то время как sfx модули которые детектятся как вреденосные более сотни килобайт (arc-tiny, arc-mini, freearc-tiny, freearc-mini не детектятся антивирусами)

Добавлено:

Цитата:

... в общем послали они меня

печально..но предсказуемо..

Выложил новый REP для тестов на http://freearc.org/download/testing/newrep.7z

может найдёте ошибку какую или ещё что интересное прежде чем я выпущу альфу

кстати, у REP появился новый параметр - :c, размер чанка, аналогично SREP. например, rep:c64==rep:l512:c64 разбивает файл на куски по 64 байта, чтобы найти больше совпадений длиной от 512 байт. параметр :a пока не работает

Новая альфа-версия:Интеграция с Explorer: настройка расширений архивов, ассоциируемых с FreeArc
Сжатие: более быстрые методы для несжимаемых данных (группа $compressed), copy=storing (7z-совместимое имя метода)
GUI: завершён редизайн диалога прогресса, область сообщений скрыта до появления ошибок/предупреждений
UI: показывает xx.x% вместо xx% в индикаторе прогресса только при обработке > 1ГБ (было: >100МБ)
Исправлена ошибка: показывалось "выполнено 0%" по завершении операции над архивом, содержащим 0 байт данных

New alpha version:Explorer integration: configuration of archive extensions to associate with FreeArc
Compression: faster methods for already compressed data ($compressed group), copy=storing (7z-like method name)
GUI: finished redesign of Progress Dialog, message area is hidden while there are no errors/warnings
UI: show xx.x% instead of xx% in progress indicator only for datasets > 1gb (was: >100mb)
Fixed bug: showing "0% done" after operation on archive containing 0 bytes

Посмотрим.
А что, rep стал хуже сжимать?
Это не нужно!
По-моему он и так быстрый, ему бы сильнее сжимать.

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

Цитата:

Интеграция с Explorer: настройка расширений архивов, ассоциируемых с FreeArc

Можно ли чекбоксы приделать, как-то ручками писать не совсем привычно. А вот дописать чего нет - это очень интересная идея.

Shuld
лучше уж среп дорабатывать и прикручивать в алгоритм, чем тратить время на рэп!

Bulat_Ziganshin
Зачем вы его дорабатываете? Какой смысл в этом, если есть лучшая альтернатива?

посмотрим через пару дней когда каспер исправится - как это повлияет на другие авири

Добавлено:

Цитата:

предлагаю внести в шапку изменения

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

по касперу - им отписаться можно через https://my.kaspersky.com/ru/support/viruslab или http://support.kaspersky.ru/virlab/helpdesk.html

текст запроса может быть такой: "Приложенные sfx-модули архиватора FreeArc 0.67 March 18 ошибочно детектятся как вирусы"

slech
а зачем тебе чекбоксы, ты хочешь отключить только часть расширений??

Shuld
окончательное сжатие (с учётом tor/lzma) изменилось несильно, и то в основном в быстрых режимах. а скорости rep, как я уже говорил, было недостаточно для -m1 на многоядерных машинах. в моих результатах это хорошо видно - у меня rep+xtor:3 стал вдвое быстрее

как существенно улучшить результаты rep - я не знаю

vasulpr
у srep есть свои недостатки, в первую очередь неспособность обрабатывать данные чисто последовательно. поэтому я его не прикручиваю к fa. впрочем, методика ускорения там одинакова - я её сейчас опробовал на rep, затем прикручу к srep тоже

Цитата:

slech
а зачем тебе чекбоксы, ты хочешь отключить только часть расширений??

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

Bulat_Ziganshin
Вот и отлично. Верная мысль, подождем пару дней, а там видно будет. И немного не в тему - Вы когда палнируте SREP интегрировать? Кста, мб sfx не паковать юпиксом? Чтобы и редактировать удобнее было. upx -d - не проблема сделать, но мб было бы лучше на выходе сжимать?

Bulat_Ziganshin
Покрутил новый реп.
Везде есть небольшое ускорение.

1. На быстрых методах (tor) ускорение сопровождается небольшим ухудшением сжатия, настолько небольшим, что вполне оправдано!
2. На методах lzma я как правило наблюдаю улучшение сжатия(?!) Приятный сюрприз.
Но непонятный.

Как я понял по умолчанию сделали h26->h24?
У меня на работе есть одна папка, которая при h24 сжимается намного хуже, завтра посмотрю.

:c, размер чанка - мне непонятно, где посмотреть?

Добавлено:
ps я имел ввиду, что Вы уменьшили размер хэша по умолчанию?

Цитата:

например да,

реально хочешь?


Цитата:

а потом я уже и не вспомню

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

Цитата:

Вы когда палнируте SREP интегрировать?

не скоро. технически, сжатие там довольно необычно, без временных файлов не обойтись


Цитата:

мб sfx не паковать юпиксом?

для тех, кто не разбирается в тонкостях, мы даём готовый мелкий exe. кто разбирается - может распаковать, отредактировать и перепаковать как ему надо - их лишний шаг не напряжёт

Добавлено:
кстати, я на днях тестировал упаковку на ram-диске "типичного" бинарного файла (это установленный ms office 2008, собранный в один файл). вот результаты на моём 2600k@4.6:


Код: I:\>arc a a MsOfficeBCJ.obj -m1 -t ; a a MsOfficeBCJ.obj -m2 -t ; a a MsOfficeBCJ.obj -m3 -t ; a a MsOfficeBCJ.obj -m4 -t

Compressed 1 file, 810,411,321 => 435,915,683 bytes. Ratio 53.7%
Compression time: cpu 12.21 secs, real 1.69 secs. Speed 479,506 kB/s
Testing time: cpu 8.17 secs, real 1.13 secs. Speed 716,503 kB/s

Compressed 1 file, 810,411,321 => 354,936,466 bytes. Ratio 43.7%
Compression time: cpu 37.67 secs, real 5.41 secs. Speed 149,707 kB/s
Testing time: cpu 9.34 secs, real 1.30 secs. Speed 621,922 kB/s

Compressed 1 file, 810,411,321 => 340,488,887 bytes. Ratio 42.0%
Compression time: cpu 80.22 secs, real 11.83 secs. Speed 68,489 kB/s
Testing time: cpu 23.67 secs, real 3.22 secs. Speed 251,432 kB/s

Compressed 1 file, 810,411,321 => 326,333,602 bytes. Ratio 40.2%
Compression time: cpu 184.69 secs, real 24.75 secs. Speed 32,747 kB/s
Testing time: cpu 22.53 secs, real 3.45 secs. Speed 235,093 kB/s

Shuld
:c по умолчанию = :l-1, округлённое вниз до ближайшей степени 2. т.е. :l512 -> :c256, :l511 -> :c256, :l513 -> :c512. весь файл разбивается на куски длины :c, и индексируются и ищутся совпадения именно среди них

2. дело в том, что новый REP находит меньше совпадений длины, близкой к 512 байтам (т.е. :l). но поскольку такие совпадения находятся "на грани" и частенько дают даже проигрыш, на результате rep+lzma эти проблемы REP почти не сказываются. а в связке rep+tor важнее скорость

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



Цитата:

Как я понял по умолчанию сделали h26->h24?

да. сейчас по умолчанию размер хеш-таблицы равен учетверённому размеру таблицы, достаточной для сохранения всех хешей чанков. чанк по умолчанию - 256 байт, соответственно при 1 гб словаре у нас 4 миллиона чанков, а хеш-таблица заводится на 16 миллионов (2^24) записей, т.е. 64 мб. при меньшем размере чанка размер хеш-таблицы по умолчанию увеличивается, но не превышает четверти размера буфера. вручную конечно можно поставить больше

а тебе заранее могу сказать, что выигрыша от h26 не будет, поскольку хеш-таблица индексируется хешем, имеющим максимальное значение из 256 (:c) подряд расположенных хешей. поэтому среднестатистически все хеши попадают в диапазон размером 2^32/256==2^24 варианта и больший размер хеш-таблицы при rep:1g:c256 просто почти бесполезен

вот пример как иногда может быть. скрин не мой, но очень реальная ситуация.

Цитата:

Новая альфа-версия:

На этой версии(может на более ранней какой-то, не заметил) отвалилась интеграция в контекстное меню, в win8. Проблема где-то в ArcShellExt папке. Если эту папку старую оставить, например от версии за апрель, то всё нормально.

Цитата:

cpu 8.17 secs, real 1.13 secs

8 ядер?)

Добавлено:
опять я невнимательно прочитал
Цитата:

на моём 2600k@4.6

Добавлено:
у среднего пользователя все равно скорость будет раза в 4 ниже.

С консольной версией пока проблем не заметил.
А FreeArc.exe у меня не работает. Выбираю папку, вызываю контекстное меню, запускаю , задаю -m4 и вылетает.
(Я просто скопировал FreeArc.exe в папку програмфайл вместо декабрьского)