UPX 3.00

А зачем он нужен? В памяти всё равно в расжимать надо, а для хранения на диске есть другие, более традиционные, средства.

>А зачем он нужен?

+1

> Для линукса безальтернативный компрессор бинарников 8).

s/безальтернативный/бесполезный

полезный. им емакс можно сжать.

По крайней мере так написано на их сайте...

наверное чтобы дизассемлировать опенсорсное приложение было сложнее :)

Помнится, когда-то в девстве, когда вин2к ещё только появлялась, я на своем старом компе с 545-мб винчом сжал acrobat reader под 98 маздаем до ~1/3 от исходного размера, используя upx. приятно.

по теме - солидарен с остальными: upx бесполезен для linux.

Сабж имхо полезен тоько для Portable-софта. Виндового.

Ибо оперативки жрет больше пакованая прога. Плюс ресурсы - они тоже в оперативку сразу грузятся.

> Copyright (C) 2000-2007 John F. Reiser

ммм...

В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)

Дурацкая новость. Всмысле, дурацкая подача новости. Что значит не нуждается в комментариях? Написано компрессор исполняемых файлов (не бинарников). А нафига он нужен только для исполняемых? :) /usr/bin заархивировать? Я не наезжаю, объясните плиз.

нахрена оно такое нам надо? будим с венды бесполезные костыли преносить ?

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

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

А от дизассемблирования не поможет, т.к. декомпрессить можно

Да, чтоб опенсорс вирусы прятать от нортона под вайном.

Гыы основное предназначение - сжимать статично собранные бинарники..

Помнится на ЛОРе проскакивала инфа о джедаях грозившихся сделать дистр где все программы будут собраны статически, походу upx будет их основным инструментом ;)

> В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)

Этим убогим вечно неймётся, вот и gzexe получается ниасилили.

>Этим убогим вечно неймётся, вот и gzexe получается ниасилили.

Это не юниксвей, так что нехер наезжать :)

> Это не юниксвей, так что нехер наезжать :)

Ага, а "Юникс-вэй" это типа в едро костыли пихать в количествах превышающих все допустимые псевдоразумные рамки?

>Ибо оперативки жрет больше пакованая прога.

почитай Overview:
"...
- no memory overhead for your compressed executables because of in-place decompression...
"

проверял? че языком зря молоть?

Гарик ну е-мое,давай еще к каждому бинарнику по бантику сбоку вешать будем..

Чего по твоему тот-же вайн по трушному надо линковать с каждой вендовой программой пускаемой в линуксе?

Это ж не логично.

> Гарик ну е-мое,давай еще к каждому бинарнику по бантику сбоку вешать будем..

Для систем (в т.ч. и с мало-мало памяти) есть всякие squashfs, и т.п. - всего дело, написать модуль под FUSE. А нафиг вообще сжимать бинарники столь костыльными способами очень и очень неясно. Тем более, что read-ahead на винтах всяко болтается в районе отнюдь не "единиц килобайт", а по новомодным тенденциям (что КДЕ, что Гном) вся логика прячется в .so, а бинари - лишь пускалки большей частью.

> Чего по твоему тот-же вайн по трушному надо линковать с каждой вендовой программой пускаемой в линуксе?

Не, портировать целиком в нативную форму. А вайн и прочие вендовые порождения должны сдохнуть.

> Это ж не логично.

Да в мире суть столько всего ипанутого, что одним моментом больше-меньше - и не заметит никто...

Тэкс, блин 8) Вижу бездну первозданной мысли 8)

Для начала читаем хотя бы то, что идет в комплекте с сабжем. Пробуем давить линкованые бинарники 8) Как ни странно - пашет, несмотря на просвещенное мнение некоторых "отцов" с ЛОРа 8)

А если серьёзно: далеко не так всё тривиально, как кажется на первый взгляд. Советую покопаться - авось сгодится 8)

>Для систем (в т.ч. и с мало-мало памяти) есть всякие squashfs, и т.п. - всего дело, написать модуль под FUSE.

Батько дык жать все надо далеко не всегда ведь. Этож медленнее и сложнее чем сжатие одного конкретного бинарника.Это не тру и попирательство юниксвей в чистом виде.

> А нафиг вообще сжимать бинарники столь костыльными способами очень и очень неясно.

Дык простота же - проблемой unpack'а заниматься приходится системе а не разработчику (пусть и в виде прикрученного унпакера).

> Тем более, что read-ahead на винтах всяко болтается в районе отнюдь не "единиц килобайт",

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

> а по новомодным тенденциям (что КДЕ, что Гном) вся логика прячется в .so, а бинари - лишь пускалки большей частью.

По новомодным тенденциям основа и там и там - система удаленного вызова процедур аля com самзнаешьгде.

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

Т.е. upx мало того, что не очень-то и нужен, но еще и вредить может достаточно сильно, так?

А вот отличная тулуза!

Мне по работе надо было кой чего упихать на cramfs (которая ограничена в размере) так вот без упкса бы и не знаю чего бы делал:)

А чем не устраивает squashfs ?

> Батько дык жать все надо далеко не всегда ведь. Этож медленнее и сложнее чем сжатие одного конкретного бинарника.Это не тру и попирательство юниксвей в чистом виде.

Дык с учётом же контекста нужно действовать - если нужно вбить на 1CD файла, что занимает на 1.5-2.0 оных, как тут иначе?

> Дык простота же - проблемой unpack'а заниматься приходится системе а не разработчику (пусть и в виде прикрученного унпакера).

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

> Дык подумай сам что больше винт терзать будет - сжатая фс или все же один сжатый бинарник

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

> По новомодным тенденциям основа и там и там - система удаленного вызова процедур аля com самзнаешьгде.

Тоже должна сдохнуть :) AI можно построить и без неё, а дальше он сам всё построит.

>Да ну нафиг тогда всё это сжатие на продакшенах, пусть так сидит где оно зело нужно и без него никак,

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

Ты про сбойные процессоры когда-нибудь слышал? А вот про сбойную память пишут постоянно.

>Тоже должна сдохнуть :) AI можно построить и без неё, а дальше он сам всё построит.

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

>А зачем он нужен?

Чтоб негры спрашивали

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

Добавь сам себя в фортунки, у меня рука не поднимется :) А дисковая память нынче стоит копейки, в отличие от памяти оперативной, благодаря добланым вендузятнегам и свисте. Да и ECC-шную память никто не отменял, nforce* её с незапамятных времён поддерживают, Интели так вообще на это дело крупно заложились.

> Ты про сбойные процессоры когда-нибудь слышал? А вот про сбойную память пишут постоянно.

Слышал конечно, иначе нафиг туда встраивают механизмы самотестирования и самокоррекции прямо на лету? Это ещё не считая богомерзких оверклокеров, что ради 5% прироста не пойми чего готовы генератор фреона в квартиру ставить.

> Прежде чем создавать искусственный разум неплохо было бы понять что есть настоящий.Иначе вместо послушного инструмента можно создать skynet и терминаторов.

Ну, дети тоже вырастают непослушными, типа подростковый нонконформизм, ага? Особенно когда вместо деревянных игрушек пулемёт "вулкан" на подвесах, а вместо строгой няни - разьедающие вендовые "мозги" вирусы.

Вот тебе и объяснение "терминаторства" - нафиг браться за воспитание, если ничего в том не смыслишь, а большинство родителей именно что "не смыслят", думая что решают проблему на лету.

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

При загрузке ядра чтение с диска AFAIR происходит без DMA, поэтому скорость и правда маленькая.

В случае gzip скорость распаковки обычных бинарников на Pentium 4 2400 MHz около 40 МБ/с, а степень сжатия - в два раза, скорость чтения при использовании DMA в середине харда - те же 40 МБ/с. Т. е. бинарник размером в 20 МБ сжимается до 10 МБ, он считывается за 0,25 с и распаковывается еще за 0,5 с, итого 0,75 с, когда мог бы просто считаться 0,5 с. А тут еще все это время используются ресурсы процессора, которые могли бы быть использованы на более полезные нужды.

> вся логика прячется в .so

Он и их жмёт :)

Казалось бы н%х он нужен. Однако есть флешка на embedde device сие не вредно. Под ДОСом такие фишки популярны, там где ДОС ещё жив :D

Классная штука, если проги на Qt статически компилишь для чего-нить, то жмёт хорошо да и грузиццо быстрее. (У мну наверн хард голимый)

File size Ratio -------------------- ------ 8454656 -> 2769920 32.76%

Хотя статически компилить можно много чё )

Хм. помнится с upx была ОЧЕНЬ неприятная бага - оно требовало для этой самой in-place decompression МЕСТО НА ДИСКЕ ... которое, на забитом под завязку рам-диске при использовании двух прог разом - КОНЧАЛОСЬ! ....

А демосцена? 64К под линухи? или извраты с dd "заголовком" и gzip юзать?

Тем более, любителям 7-zip приятная новость, его LZMA алгоритм уже в UPX.

Кому не надо или не понимает зачем - RTFM.

Кстати, все высказавшиеся упускают одну маленькую деталь -- он хранит checksum бинарника - и теоретически - это можно использовать для проверки tamperring'а бинарных файлов.

Не, просто присутствующие в курсе что чексумингом ведает пакетный манагер, и гимора с дополнительной работой по проверке бинарей не очень желают. Или вы уже убедили rpm-щиков, deb-ианщиков и прочих сочувствующих юзать сие поделие?

Про лицензионные тонкости тоже забывать не стоит.

А вообще Оберхумеру спасибо стоит сказать вовсе даже не за UPX, а за lzo-навеску, вот где реальная польза для комьюнити.

Устарели на сегодня принципы которые используются в нем... хотя на безрыбьи и это рыба...

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

иногда банальный `strip --strip-unneeded -R .comment -R .note *` уменьшает размер бинарника в несколько раз

Теперь масдайные троянцы ещё лучше упаковываются?

gcc 4.2 -Os, binutils 2.17.50.9> , linking optimisations , gnu only hashstyle , stripe , PAX , prelink, stripe , PAX

Вуаля и даже какойнить монструозный апачь целиком уменьшается в 3-4 раза и безо всяких UPX умещяется в какуюнить убогенькую embeded среду. Ну, а если хочется хардкору то и продукт этих манипуляций можно им зажать, но это даст максимум 1.6х уменьшение объема и увеличение времени старта в 2 раза так как половина того что делает UPX описана выше, а жать из того что получилось ему особо нечего.

Суть: elf32, elf64 megabloated поделия(хотя exe еще трагичнее)

Хреново он работает: распаковывает бинарник в /tmp, потом запускает. Гораздо правильней было бы распаковывать прямо в память, а потом передовать туда управление.

Посему - в топку, ибо bzip2/gzip/rar/7z рулят куда больше.

О, лучший архиватор для вирусов! Сколько приятных минут испытали и нежных слов сказали пользователи M$ Windows благодаря ему!

эта... просветите чайника %)

$ ./upx -9 libQtCore.so.4.3.0 libQtGui.so.4.3.0
                       Ultimate Packer for eXecutables
  Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007
UPX 3.00        Markus Oberhumer, Laszlo Molnar & John Reiser   Apr 27th 2007

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
upx: libQtCore.so.4.3.0: UnknownExecutableFormatException
upx: libQtGui.so.4.3.0: UnknownExecutableFormatException

Packed 0 files.

А зачем ты им пытаешься библиотеки жать?

>эта... просветите чайника %)

UPX - Ultimate Packer for eXecutables

http://upx.sourceforge.net/#formats

> Просветите, кто разбирается. Читал где-то, что в линухе бинарники при старте загружаются в память не целиком, грузятся только нужные секции файла. А если он будет пожат upx, то грузится будет всегда целиком (иначе не распакует).

Так не только в линуксе, но и в винде. При малом размере бинаря, это не так критично. Но при размерах в мег 5-20 это уже ощутимо.

> Т.е. upx мало того, что не очень-то и нужен, но еще и вредить может достаточно сильно, так?

Вы хорошо начали размышлять. Подумайте еще - найдете и положительные стороны данного пакера.

> А зачем ты им пытаешься библиотеки жать?

ну не сам же я это придумал:

--------8<--------

Re: UPX 3.00

> вся логика прячется в .so

Он и их жмёт :)

acheron ** (*) (04.05.2007 1:07:16)

--------8<--------

а жать нада чтоб на 32-метровую флешку всё уместилось вместе с иксами, картами и т.п... хотя проще 64-метровую купить и не париться, но сейчас есть только 32М...

Тогда бери пример с Damn Small Linux - используй ramfs (или что-то) в памяти. isoшка DSL занимает 50 мегов.Вместе с туевой хучей софта.