Clear__Energy Интересно, но я никак невозьму в толк насколько ключи могут оставаться неменяемыми после обнавления приложения. А про алгоритмы обращения к ключам я вообще непонял, можно подробнее?
ну, допустим, есть ключ. прога его читает при старте, потом, модифицирует в процессе работы, потом, допустим, перед завершением. я про эту последовательность. идиотское наверное предложение
Обсуждали уже, если приложение (прибиваемый бинарник) обнавилось, его хэш будет другой. А генерить каждый раз новый хеш по названию бинаря, уж увольте, так можно такого наколбасить... Вот в этом загвоздка как раз и есть, как идентифицировать проложение после его обновления, при этом исключить возможность подставления (переименовывания) злобным юзером бинарника.
ну я же тебе написал - используй 10-15 сигнатур коротких. Ну не будет же файл метаморфиться. Уверен, ты пишешь защиту от пасьянсов для секретарш. Вряд ли они умеют метаморфить файлы.
Сигнатура и хеш это разные вещи. Не уверен что старые сигнатуры подойдут к обновленным екзешникам, не проверял. Но помоему легче самому проверять когда появятся обновления, и снимать сигнатуры заново. Хотя в теории какие-то куски кода будут одинаковыми во всех версиях, но их автоматически не найдешь) Можно конечно сверять два файла разных версий и сходства использовать в кач-ве сигнатур... Да много чего можно придумать, но помоему вариант с иконками самый лучший)
Не понимаю, в чем сложность с сигнатурами. Берешь размер сигнатуры к примеру 30 байт. Определяешься, что сделает 30 сигнатур. Наугад в секции кода выбираешь место (можно и в секции данных) и сохраняешь эти 30 байт в специальный буфер. Когда делаешь анализ приложения пишешь так: for (int i = code_sect_start; i < code_sect_end - sizeof(signature); i++) check_signatures(i); И проверяешь. Совпало хотя бы 5-6 из 30 - смело пиши, что это тот же файл
Ну я так понял, что анализироваться будет процесс в памяти, а не файл на диске. И название темы в пользу этого говорит. А если файл упакован, можно смело кричать TR/Crypt.XPACK.Gen
2MSoft А если файл обновляется, и в секцию кода например в 5% от начала попадает новый кусочек., а мы ранее брали хэши кусочков равномерно по всему файлу, в результате в памяти 95% старого кода будет смещено на размер этого кусочка.И совпадет только первые 5%
rdtsc а ты еще раз перечитай 30-й пост, особенно кусочек кода. Я разве предлагал привязываться к смещениям?
Вообще говоря, если у юзера нет прав админа, то модифицировать бинарники установленные в %PROGRAMFILES% и прочие "доверенные" пути у него нет возможности. А запретить запуск из остальных мест вполне можно через политики ограниченного использования программ: http://technet.microsoft.com/en-us/library/cc786941(WS.10).aspx Собственно, это классическое решение. Если же у юзера вдруг есть права админа - скорее всего, что-то не так в этой консерватории. Разумеется, вариант предполагает наличие админа и первоначальную настройку, ибо полный автомат - это уже писать что-то "а ля антивирус" придётся - распознавать "плохой" код и "хороший". А так - правила пути и сертификатов (для подписанного софта которого всё больше и больше) + deny all. http://www.cyberguru.ru/operating-systems/windows-admin/software-restriction-policy-page3.html
Подход с использованием политиков,ограничением прав в системе и прочими админскими штуками в данном решении невозможен. Также "умный" алгоримт DENY ALL категорический негодится. Реальным решением мне представляется только одно, использование сигнатур как предложил MSoft. Едииственное что смущает - вероятность совпадения сигнатур со старой и новой версий приложения. Вероятность модефикации кода юзером исключаем, поскольку ясное дело что данное решение не расчитано на кодеров и ит-профи) Как я вижу можно брать сигнатуры со следующих кусков кода: - Ресурсы (все кроме диалогов) - Секция данных - Секция кода (обрабатываем с наименьшим коэфициентом вероятности) Ну и конечно обрабатывать не файл, а запущенный процесс. Что еще можно добавить в решение для пущей надежности?
Кстати, вполне возможно, что для идентификации изменяющихся файлов подойдёт так называемый fuzzy hash http://www.forensicswiki.org/wiki/Ssdeep
А почему не годится??? 1. Админ запускает этот самый фильтр и получает хеши всего, что запускается в процессе загрузки, при работе, и т.д. Специально запускает все необходимые для работы программы, и с них тоже хеши. 2. Включается защита, разрешающая ТОЛЬКО то, чьи хэши в базе. Все остальное - лесом, полем. 3. Пользователь обычно не может модифицировать что угодно. Если рабочий файл изменен - сам дурак, пусть пишет докладную. 4. Достоинства - вирусы тоже не запустятся. 5. Недостатки - если принесут какую-то необходимую для работы программу, ее придется разрешать админу. - если что-то обновляется, включая экзешник, то после обновления придется разрешать.
