простейший упаковщик можно и в конец секции какой-либо запихать, но насчет нормальных ты прав - все в конце(те, что видел во всяком случае). теоретически можно в любое место, но практически никто не парится...
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Общие вопросы > Проверка упакованности |
| Автор: ASGDeveloper 5.9.2006, 23:13 |
| Все никак не могу доехать, как же проверить факт упакованности exe-шниника. Каких-то универсальных функций (типа как в ольке) не вижу, вижу только решение в лоб - коллекционирование сигнатур упаковщиков. |
| Автор: dumb 5.9.2006, 23:21 |
| самая простая проверка упакованности - попытка упаковать и оценить степень сжатия. |
| Автор: Alexeis 5.9.2006, 23:40 |
| dumb, а может перенесенная в конец файла точка входа? Или не все упаковщики крепятся в конец? |
| Автор: Snowy 5.9.2006, 23:53 |
| Упаковщики как раз никуда не крепятся - они и есть программа. Сама программа - данные. Одной из особенностью упаковщиков можно считать использование первых 100h байт. У обычных программ там DOS секция. Упаковщики обычно на неё плюют и используют под собственные нужды. Также в секции импорта упакованных программ находятся только LoadLibraryA и GetProcAddress. Но это всё признаки. Гарантию даст только знание сигнатур. Которые, впрочем меняются. Но по признакам можно определить с вероятностью 95% и выше. Добавлено @ 23:55 И dumb прав. На худой конец можно попробовать и сжать. Обычные программы (> 4кб) хорошо жмутся. А упакованные процентов на 5 - не больше. |
| Автор: dumb 5.9.2006, 23:56 |
| alexeis1, брр.. причем тут EP? просто оцениваем степень сжатия любым упаковщиком - хоть winrar'ом: упакованные/покриптованные данные практически не жмутся. простейший упаковщик можно и в конец секции какой-либо запихать, но насчет нормальных ты прав - все в конце(те, что видел во всяком случае). теоретически можно в любое место, но практически никто не парится... |
| Автор: ASGDeveloper 6.9.2006, 00:03 | ||||||
Добавлено @ 00:08
Осталось только придумать как их вычислять.
Странно, но сейчас в упакованной проге нашел весьма солидную import table с кучей функций.  |
| Автор: Alexeis 6.9.2006, 00:10 |
| Так я так и понял, что речь идет о программной проверке. Т.е. чтоб это работало быстро. А проверить указатель на точку входа и сравнить ее с размером файла можно быстро. Распаковщики (сори за очипятку) же занимают обычно не более 1кб. Если к EP добавить 1кб то для упакованой программы эта величина должна превышать размер экзешника на диске. |
| Автор: Snowy 6.9.2006, 00:29 | ||
ExitProcess можно не считать. Обычно там больше функций, если упаковщик поддерживает защиту - обычно он для этого импортирует функции advapi. UPX легко определить. У него обязательно в первых 220h байт находятся сигнатуры UPX0 и UPX1. Пожалуё это один из немногих упаковщиков, не использующих первые 100h байт. Можно ygbcfnm небольшую эвристику на анализ первых 100h байт. Если процент нулей меньше 80% - упакован. Если эвристика и наличие UPX не обнаружены - пробовать пожать первые 32 кило. Жать весь файл незачем. Коэффициэнт слабый - пожат. Добавлено @ 00:30 alexeis1, к примеру, UPX так не отличишь - он выглядит вполне честно. Никаких смещений. Добавлено @ 00:31 Опять же повторю - упаковщик не приклеивается к программе - он сам программа. |
| Автор: oleg1973 6.9.2006, 01:14 |
| а что энтропию проверить нельзя? |
| Автор: Alexeis 6.9.2006, 01:17 | ||
Это я знаю, имел ввиду распаковщик. Что у UPX распаковщик не крепится в конец экзешника? |
| Автор: Snowy 6.9.2006, 01:19 | ||
Он в самом начале сидит - там, где и положено находиться нормальной программе - по адресу 100h. |
| Автор: Alexeis 6.9.2006, 01:20 |
| oleg1973, вопрос как найти быстрое решение. |
| Автор: oleg1973 6.9.2006, 01:21 |
| проще пошитать циферки в файлике чем собирать сигнатуры |
| Автор: Snowy 6.9.2006, 01:26 | ||
|
| Автор: Alexeis 6.9.2006, 01:28 | ||
Та же фигня что и упаковка, только в профиль |
| Автор: oleg1973 6.9.2006, 01:37 | ||
как что это даст?
|
| Автор: dumb 6.9.2006, 01:43 | ||
это вы так шутите, да? |
| Автор: ASGDeveloper 6.9.2006, 08:04 | ||
Вопрос только как |
| Автор: Alexeis 6.9.2006, 09:00 |
| Как я понимаю для существования максимальной энтропии в файле не должно быть повторяющихся последовательностей + не должно существовать алгоритма определяющего связь (по значению и взаиморасположению) между любыми двумя байтами в файле. Если первую часть определить трудоемко, то вторую сверхтрудоемко. Так по крайней мере определяется максимум энтропии с физической точки зрения. |
| Автор: BUGOR 6.9.2006, 09:02 |
| у UPX точка входа вообще всегда указывает в последнюю секцию. Энтропия: http://www.wasm.ru/print.php?article=packers2#4 |
| Автор: Alexeis 6.9.2006, 09:44 | ||
| 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 Потому я и добавил!
|
| Автор: BUGOR 6.9.2006, 10:08 |
| alexeis1, мы разве ведём разговор о алгоритмах сжатия или сжатой записи информации? Не понимаю вообще, что ты хотел этим сказать... Человек написавший ту статью имеет гигатский опыт, он стоял у истоков васма, я не думаю, что он в чём-то допустил ошибку, такие люди проверяют то, что пишут. Добавлено @ 10:12 К тому же давай не будем мучать себя теорией. Дай реальный пример упакованного/неупакованного файла чья энтропия расчитанная тем способом при анализе даст результат обратный действительному. |
| Автор: Alexeis 6.9.2006, 10:13 |
| Из всего сказаного мной следует вывод, что термин энтропия к тому, что было вычислено применен не корректно, это скорее максимальная расчетная степень сжатия класическим упаковщиком - т.е. то о чем говорил Snowy |
| Автор: BUGOR 6.9.2006, 10:21 |
| Хороший криптоалгоритм энтропию испортит, я насчёт этого не спорю. Но на практике вероятность попадания такого файла ничтожно мала. |
| Автор: Alexeis 6.9.2006, 10:36 |
| Так я о шифровке совсем не говорил Я хотел показать только несостоятельность расчета энтропии, которая простыми словами определяется как мера беспорядка. Я не шифровал, а наоброт показал, что последовательности неповторяющихся байтов часто могут иметь другие взаимосвязи (это был пример определения взаимосвязей между порядком байтов и их расположением), которые хоть и нельзя расчитать элементарно машинным способом, но и нельзя отрицать их существование, так как они в равной мере наряду с повторяемостью также определяют энтропию. А что касается криптоалгоритма, то он наоборот имеет целью увеличить ее до максимальной, поскольку полный хаос нельзя расшифровать по определению. |
| Автор: BUGOR 6.9.2006, 10:51 |
| alexeis1, кончай кормить меня умными словами и терминами, покажи лучше на практике. В теории у нас все возможно. Возьми любой существующий пакер или архиватор на сегодняшний день, расчитай энтропию по тому алгоритму, проанализируй результат и попробуй найти исключения. Ещё. Если речь идёт о PE файелах, правильней будет считать энтропию не всего файла, а только данных которые находятся в секциях. |
| Автор: ASGDeveloper 6.9.2006, 11:12 | ||
Так, алгоритм для вычисления энтропии я закодировал. Осталось выяснить что и как читать |
| Автор: dumb 6.9.2006, 11:16 |
| ASGDeveloper, не парься - возьми из середины файла кусок кила эдак на 64. |
| Автор: Alexeis 6.9.2006, 11:20 |
| BUGOR, ну если из практики, то нечто подобное уже существует, но пока только для графики 1) Алгоримы перевода из растровой в векторную графику. 2) Распознование символов. 3) Фрактальное сжатие (существует уже зарегистрированый формат) В этом случае также выйдем на минус. |
| Автор: ASGDeveloper 6.9.2006, 11:34 | ||
Вот я и гляжу. Щас проверил, все нормально работает. Всем большое спасибо, тему можно закрывать. Добавлено @ 11:36 Щас плюсы буду раздавать |
