Ru-Board.club
← Вернуться в раздел «Программы»

» EXE, DLL, OCX, PE-распаковка|упаковка|pack|unpack|decrypt

Автор: leputain
Дата сообщения: 14.12.2002 18:14

Выбор программы сжатия исполняемых файлов
Последние события на рынке и новинки
В каких случаях имеет смысл сжимать программы и чем это черевато?
Что делать, если необходимо изменить программу, а она запакована

Этим и многим другим смежным вопросам сжатия исполняемых файлов посвященая эта тема.


Ссылки

Aaron's page@ EXETools.com
Распаковщики на WASM.ru
UnASPack by Y0da
UnPAKiNG G0ds


Определители упаковщиков

PEiD & Plugins
Автор: NT
Дата сообщения: 14.12.2002 22:36
leputain
не так оно. запакованная процессор жрет больше.
Автор: QuickeneR
Дата сообщения: 15.12.2002 00:10
leputain

Цитата:
стоит ли игра свеч?

Каждый выбирает для себя...
что ему важнее, место на винте или память плюс время загрузки (точнее не время даже, т.к. распаковывается очень быстро, а загрузка проца при запуске программы, как правильно заметил NT)
Автор: vito333
Дата сообщения: 15.12.2002 04:20
я перегрузок памяти или проца особых не заметил - хотя машина не супер - жму все, что можно - аспаком или апксом ...

Добавлено
да и многие софтины приличные все чаще и чаще жатые ...
Автор: leputain
Дата сообщения: 15.12.2002 18:27
vito333
неееееее, я сверял, памяти жрут больше.
не буду юзать, ну только если для огромных .exe-шников
Автор: AndreyMVT
Дата сообщения: 15.12.2002 18:48
Если бы я писал коммерческие проги, то обязательно юзал бы проги, которые пакуют и шифруют exe-файл! Тогда над взломом проги хоть помучаться придется!!!
Автор: QuickeneR
Дата сообщения: 15.12.2002 21:42
AndreyMVT
Помучиться пришлось бы только тебе. :-) При некоторой практике все стандартные протекторы снимаются за 5 минут.
Автор: Da_Neil
Дата сообщения: 15.12.2002 22:44
Уж лучше сжатие NTFS использовать - оно хотя бы файлы не портит.
Автор: leputain
Дата сообщения: 15.12.2002 22:56

Цитата:
При некоторой практике все стандартные протекторы снимаются за 5 минут.

точно. анпакеры ж есть. время уйдёт только на поиск оного.
Автор: vito333
Дата сообщения: 16.12.2002 03:21
leputain
ты уж тогда приведи цифры - может я тогда перестану тоже все сжимать на винте - да и интересно ...
Автор: leputain
Дата сообщения: 16.12.2002 06:26
ок. домой доеду, замерю, отпишусь.
Автор: leputain
Дата сообщения: 17.12.2002 16:56
итак жмём нотепад (хр):
оргинал=
66048 байт, запускаю...
2004кб памяти, 2 процента цпу (когда переключаюсь на него)
сжатый upx120w=
47616 байт, (upx -9 notepad.exe), запускаю...
2070кб паияти, цпу так же.
плохой пример =(
винамп2.81:
оригинал=
622080 байт, запускаю...
5888кб памяти, 5 процентов цпу (то 5, то 0)
сжатый upx120w=
262144 байт, (upx -9 winamp.exe), запускаю...
8956кб *!!!!* памяти, 5 процентов цпу

вот такие дела. надо что-то выбирать, у меня памяти 256мб, но под хр всё равно как-то задумываюсь... так что я против них.
ими видимо жмут проги, чтоб места меньше занималии если в инет выкладывать или просто стыдно, что .exe > 1mb... ну, конечно, это актуально в той или иной степени. и, да, чем больше прога, тем больше пямяти в сжатом состоянии она жрёт, вот так!


Добавлено
ххххха! два дня ехал до дому....
Автор: Felix
Дата сообщения: 17.12.2002 18:01
leputain а смысл паковать UPXом данные программы??? дело в том, что когда пишется код на VCL, то к примеру проект занимает 1,3 Мб.... а что в этом коде??? шелуха...., после упаковки ~ 400-500 (~36%) разница очевидна...
Автор: leputain
Дата сообщения: 17.12.2002 18:13
Felix

Цитата:
а смысл паковать UPXом данные программы???

а чем? pklite или aspack?
просто выбрал upx и всё тут.


Цитата:
дело в том, что когда пишется код на VCL, то к примеру проект занимает 1,3 Мб.... а что в этом коде??? шелуха...., после упаковки ~ 400-500 (~36%) разница очевидна...

к чему это вообще?
в чем разница? в размере - да, но память-то жрется.....
Автор: vito333
Дата сообщения: 17.12.2002 18:14
leputain
вообще-то маловато цифр - да и я например пакую почти все аспаком - блин, ну не замечал я увеличения прожорливости - а машина у меня не очень - ноут пень2-266 со 128 мег - так что я поневоле борец и с гигантами на винте и с гигантами в памяти - но уже давно все пакую...
Сейчас под рукой была Рехетка от YMY сжатая и не сжатая - посмотрел - обе 1.7-1.9 мег в памяти ...
Думаю - надо спросить специалиста - того же YMY - он как-то где-то отрицательно отзывался о пакерах - и свои таблетки поэтому не жмет ...
Автор: Felix
Дата сообщения: 17.12.2002 18:19
а по поводу поедания памяти предположение такое, что она идёт на оперативную распаковку данных, используемых в процессе.
На счёт загрузки CPU, то на неё смотреть не стоит, т.к. простейшая программа

repeat
Application.ProcessMessage;
until Бесконечность....

способна процентов на 98-99% загрузить процессор.

Если интересно, то могу привести данные для сжатой и несжатой программой на Delphi


Добавлено
Но не сегодня....
Автор: vito333
Дата сообщения: 17.12.2002 19:01
конечно приведи - вопрос интересный ...
Автор: ymy
Дата сообщения: 17.12.2002 20:16
Тута аж двое почти одновременно прислали в ПМ, ну чего могу сказать вот копия моего поста в FSDialere

Цитата:

Ситуация такова, где-то я на форуме это уже писал, пакование EXE не только не полезно, но и вредно.
Единственный плюс место на диске меньше, но если всё уж так критично можно запаковать сам файл или диру с прогой используя стандартную возможность NTFS.
Минусов куча:
1. Время запуска не уменьшается, а увеличивается, и немало.
То что в качестве рекламы пишут, что дескать, так как упакованный файл занимает меньше места на диске, следовательно при запуске он быстрее загружается в память, а распаковка происходит быстро, поэтому получается даже быстрее, чем с запуском неупакованного, это всё миф.
На самом деле неупакованный файл виндузня не считывает весь сразу в память, а только необходимые части, и потом зачитывает по мере необходимости (файл становится как-бы частью свопа, используется так называемая проэкция файла в виртуальную память)
2. ЖРЁТ ПАМЯТЬ.
Дополнительная память нужна для распаковки, но это не самое страшное. Самое страшное, что теперь файл весь закачивается в память и там распаковывается, так что после запуска в памяти полнотью весь упакованный файл + он же, но уже распакованный!!!, а ещё страшнее, что при запуске второго и третьего экземпляра проги (мало-ли надо бывает), в памяти создаются новые полные копии!!!, в то время как в случае неупакованных EXEшниках и DLLках ничего этого не происходит.


Добавлено
И чем больще пакуемый EXE тем хуже будет.
Автор: vito333
Дата сообщения: 18.12.2002 01:21
мля ... ужасы...
но чего-то не убедили меня - придется вплотную заняться подсчетами ...

Добавлено
где-то я видел доку по этой части - попробую найти ...

Добавлено

Цитата:
1. Время запуска не уменьшается, а увеличивается, и немало.


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


Цитата:
2. ЖРЁТ ПАМЯТЬ.

не вижу такого в упор ...

но, повторюсь, будем посмотреть...
Автор: leputain
Дата сообщения: 18.12.2002 10:47
vito333

Цитата:
где-то я видел доку по этой части - попробую найти ...

ждём-с..
Автор: Felix
Дата сообщения: 18.12.2002 12:22
сегодня надеюсь руки дойдут до подсчётов, и я выложу данные по вермени запуска, загрузке цпу и пожиранию памяти (для сжатых и несжатых VCL программ на Delphi) но результаты будут только в пятницу....
ymy интересный вопрос заключается в том, для каких пакеров справедлива цитата?!?, алгоритмы-то у всех разные....., да зачастую и концепции...

vito333 кучу док (правда на английском) можо найти отталкиваясь от UPX, NRV, LZO и т.п.


Добавлено
кстати:


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

Автор: leputain
Дата сообщения: 18.12.2002 12:32
по-моему, всё уже понятно...
но всё равно интересно
Автор: QuickeneR
Дата сообщения: 18.12.2002 13:49

Цитата:
На самом деле неупакованный файл виндузня не считывает весь сразу в память, а только необходимые части, и потом зачитывает по мере необходимости (файл становится как-бы частью свопа, используется так называемая проэкция файла в виртуальную память)

Вызывает сомнения. Есть такая вещь DelMod от EliCZ которая позволяет удалять exe и dll, когда процесс активен. Спрашивается, как бы она работала, если бы винда действительно подгружала файлы не из свапа, а из образа на диске?
Автор: leputain
Дата сообщения: 18.12.2002 14:30
QuickeneR
действительно...
хотя может эти проги получат какие-нить эксклюзивные права...
Автор: ymy
Дата сообщения: 18.12.2002 20:10
vito333

Цитата:
но чего-то не убедили меня

Да чегу тут убеждать, это не мои личные предположения, это принципы работы виндузни, вполне логичные и правильные.

Felix

Цитата:
интересный вопрос заключается в том, для каких пакеров справедлива цитата?!?

Цитата справедлива для всех пакеров расжимающих в память, коих сейчас подавляющее большинство.

QuickeneR

Цитата:
Вызывает сомнения. Есть такая вещь DelMod от EliCZ которая позволяет удалять exe и dll

Конечно можно поменять уровень защиты страниц памяти заставив тем самым систему отключить файл от свопа и целиком передать его в своп, а потом делай с этим файлом чего хочешь, хошь удаляй,
так что это ничему не противоречит.
Автор: QuickeneR
Дата сообщения: 18.12.2002 20:33
ymy
А это можно как-то проверить?
Вот например, если затереть содержимое экзешника в процессе выполнения, обойдя его блокировку окошками, по твоей теории он должен вывалиться с ошибкой. Надо будет как-нибудь попробовать.
Автор: ymy
Дата сообщения: 18.12.2002 20:43
QuickeneR Я не совсем понял как ты хочешь это проверить, я же говорил что после смены уровня/режима защиты с RO на RW, система отключит эту страничку от свопа и загонит в своп, после этого удаляй, обнуляй всё пофиг, файл уже в свопе. Если конечно написать драйвер или фильтр чтобы на низком уровне патчить чего-то в алгоритме свопа и подкачки страниц, ну если кто собирётся флаг ему в руки Постоянный BlueScreen ему гарантирован. А пока ты не поменял аттрибут зашиты часть диска соответсвующая этой RO секции является частью свопа и писать туда тебе не дадут.

В NT/2k/XP даже RW секции в PE файле не сразу качаются в своп, а являются частью виртуальной памяти (частью свопа) до той поры, пока не будет первой попытки записи. (аттрибут защиты PAGE_WRITECOPY)
Автор: QuickeneR
Дата сообщения: 18.12.2002 22:22
ymy
Проверить просто - сделать драйвер, который будет писать на диск невзирая на атрибуты. После чего скопировать туда-сюда метров 500.
Или еще идея: посмотреть filemon'ом обращения к exe после загрузки.
Автор: ymy
Дата сообщения: 18.12.2002 23:29
QuickeneR
Нет ты так и не понял
На EXE проэцируется виртуальная память, поэтому обрашение к нему идёт через механизм подкачки страниц, а не через какие-нибудь APIшные функции, пускай даже низкоуровненные, поэтому никакой filemon не поможет. Драйверу используя APIшные функции писать тоже не дадут, разве что напрямую с диском работать.

Проверить можно так, создать EXE c большущей RData-ой, какой-нибудь константынй массив метров на 10, главное чтобы прога ничего не делала, никакие dll не импортировала и сама память никакую не выделяла. Сделанный таким макаром EXE запустить и посмотреть что изменилось в соотношении памяти.
Автор: QuickeneR
Дата сообщения: 18.12.2002 23:38
Если ты хочешь сказать, что блокировка намапленных (или открытых иным способом) файлов осуществляется на одном уровне с доступом к винту по секторам, то я не верю.
А лучше скажи, где прочитал или как определил, что на EXE проэцируется виртуальная память, и не будем спорить.

Страницы: 123

Предыдущая тема: Самая лучшая грабалка MP3


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.