Все никак не могу доехать, как же проверить факт упакованности exe-шниника. Каких-то универсальных функций (типа как в ольке) не вижу, вижу только решение в лоб - коллекционирование сигнатур упаковщиков.

самая простая проверка упакованности - попытка упаковать и оценить степень сжатия.

dumb, а может перенесенная в конец файла точка входа? Или не все упаковщики крепятся в конец?

Упаковщики как раз никуда не крепятся - они и есть программа.
Сама программа - данные.
Одной из особенностью упаковщиков можно считать использование первых 100h байт. У обычных программ там DOS секция. Упаковщики обычно на неё плюют и используют под собственные нужды.
Также в секции импорта упакованных программ находятся только LoadLibraryA и GetProcAddress.
Но это всё признаки. Гарантию даст только знание сигнатур. Которые, впрочем меняются.
Но по признакам можно определить с вероятностью 95% и выше.

Добавлено @ 23:55 
И dumb прав. На худой конец можно попробовать и сжать. Обычные программы (> 4кб) хорошо жмутся. А упакованные процентов на 5 - не больше.

alexeis1, брр.. причем тут EP? просто оцениваем степень сжатия любым упаковщиком - хоть winrar'ом: упакованные/покриптованные данные практически не жмутся.

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

А если файл большой? Ведь паковка в тот же зип займет несколько секунд времени.

Добавлено @ 00:08 

Осталось только придумать как их вычислять.   


Странно, но сейчас в упакованной проге нашел весьма солидную import table с кучей функций.   

Так я так и понял, что речь идет о программной проверке. Т.е. чтоб это работало быстро. А проверить указатель на точку входа и сравнить ее с размером файла можно быстро. Распаковщики (сори за очипятку) же занимают обычно не более 1кб. Если к EP добавить 1кб то для упакованой программы эта величина должна превышать размер экзешника на диске.

Это сообщение отредактировал(а) alexeis1 - 6.9.2006, 00:13

Я написал только? Я имел ввиду обычно только.
ExitProcess можно не считать.
Обычно там больше функций, если упаковщик поддерживает защиту - обычно он для этого импортирует функции advapi.
UPX легко определить. У него обязательно в первых 220h байт находятся сигнатуры UPX0 и UPX1.
Пожалуё это один из немногих упаковщиков, не использующих первые 100h байт.
Можно ygbcfnm небольшую эвристику на анализ первых 100h байт. Если процент нулей меньше 80% - упакован.
Если эвристика и наличие UPX не обнаружены - пробовать пожать первые 32 кило. Жать весь файл незачем.
Коэффициэнт слабый - пожат.

Добавлено @ 00:30 
alexeis1, к примеру, UPX так не отличишь - он выглядит вполне честно. Никаких смещений.

Добавлено @ 00:31 
Опять же повторю - упаковщик не приклеивается к программе - он сам программа.

а что энтропию проверить нельзя?

Это я знаю, имел ввиду распаковщик. Что у UPX распаковщик не крепится в конец экзешника?

Нет конечно.
Он в самом начале сидит - там, где и положено находиться нормальной программе - по адресу 100h.

oleg1973, вопрос как найти быстрое решение.

проще пошитать циферки в файлике чем собирать сигнатуры

А что это даст?

Та же фигня что и упаковка, только в профиль  

как что это даст?

это вы так шутите, да? 

Вопрос только как   

Как я понимаю для существования максимальной энтропии в файле не должно быть повторяющихся последовательностей + не должно существовать алгоритма определяющего связь (по значению и взаиморасположению) между любыми двумя байтами в файле. 

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

Это сообщение отредактировал(а) alexeis1 - 6.9.2006, 09:03

у UPX точка входа вообще всегда указывает в последнюю секцию. 

Энтропия: http://www.wasm.ru/print.php?article=packers2#4

Это сообщение отредактировал(а) BUGOR - 6.9.2006, 09:03

BUGOR, а теперь я докажу что способ расчета энтрапии указаный в Wasm.ru не верный
Рассмотрим последовательность
0 2 4 6 8... 254 1 3 5 7 9...255 - всего 256 неповторяющихся символов.

вероятность появления расчитаная указаным в статье образом равна
1/256
энтропия одного символа |log2 1/256| = 8
сумма всех таких энтропий = 8 * 256 = 256 байт
А я возьму и закодирую такую последовательность так 
{2n;2n+1}0%127 - итого 12 байт
Ой что-то у меня меньше 256-ти байт вышло  

Вот такой вышел расчет меры эффективности хранения информации

Добавлено @ 09:56 
Еще пример
0 1 2 3 
4 5 6 7
8 9 A B 
C D E F 

развернем по спирали 
5 9 A 6 2 1 0 4 8 C D E F B 7 3 - ну просто никак не сожмешь, казалось бы энтропия максимальна. Ничего подобного закодируем 
sp0%F - что будет значить спираль против часовой стрелки от 0 до F
пожалуйста без ухищрений такая хаотичная на первый взгляд строка пожалась! 
Очевидно для исходной нам нужно было не мнее 8 байт, а я уложился в 5
Значит не все определяют одни лишь повторения символов.

Добавлено @ 09:57 
Потому я и добавил!



Это сообщение отредактировал(а) alexeis1 - 6.9.2006, 10:08

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

Добавлено @ 10:12 
К тому же давай не будем мучать себя теорией. Дай реальный пример упакованного/неупакованного файла чья энтропия расчитанная тем способом при анализе даст результат обратный действительному.

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

Хороший криптоалгоритм энтропию испортит, я насчёт этого не спорю. Но на практике вероятность попадания такого файла ничтожно мала. 

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

Это сообщение отредактировал(а) alexeis1 - 6.9.2006, 10:37

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

Так, алгоритм для вычисления энтропии я закодировал. Осталось выяснить что и как читать   

ASGDeveloper, не парься - возьми из середины файла кусок кила эдак на 64. 

BUGOR, ну если из практики, то нечто подобное уже существует, но пока только для графики
1) Алгоримы перевода из растровой в векторную графику.
2) Распознование символов.
3) Фрактальное сжатие (существует уже зарегистрированый формат)

В этом случае также выйдем на минус.

Вот я и гляжу. Щас проверил, все нормально работает. Всем большое спасибо, тему можно закрывать.

Добавлено @ 11:36 
Щас плюсы буду раздавать