Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Guardant → Технологии защиты → Электронная цифровая подпись
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Добрый день.
Скажите пожалуйста можно ли защитить от модификации exe-к и dll-ки программы?
В документации нашел такое про проверку целостности приложения:
https://dev.guardant.ru/pages/viewpage. … Id=1279064
Но здесь на форуме пишут, что она проверяет только целостность защищающего кода.
А можно ли весь файл целиком проверить, что бы в него не добавляли или не убавляли лишнего?
Здравствуйте.
Контроль за целостностью приложения эффективнее реализован в новой автоматической утилите защиты Native-приложений — Guardant Armor.
Guardant Armor шифрует все секции и экземпляры псевдокода у защищенного приложения. Перед тем как выполняется что-либо, происходит расшифровка. Если контрольная сумма не совпадает, будет ошибка.
Здравствуйте.
Вопрос возник от того, что кроме основного приложения в проекте существует ещё несколько нативных dll.
Причём одна из них грузится сторонним приложением.
Вот их целостность и хочется контролировать.
Здравствуйте.
Вопрос возник от того, что кроме основного приложения в проекте существует ещё несколько нативных dll.
Причём одна из них грузится сторонним приложением.
Вот их целостность и хочется контролировать.
Эти библиотеки также можно защитить и привязать к ключу с помощью Guardant Armor.
Под Armor проверки начинают медленно работать, и запуск становится очень долгим. Защита конечно хорошая, но не всегда требуется такой уровень.
Под Armor проверки начинают медленно работать, и запуск становится очень долгим. Защита конечно хорошая, но не всегда требуется такой уровень.
Запускали приложение под профайлером?
Также можно исключить из защиты заведомо тяжеловесные функции перечислив их в специальном *.ini-файле (опция -INI=<ini-файл>).
А возможно ли при помощи Armor защитить только одну dll, которая будет подключаться как плагин в другую программу?
И возможно ли Armor использовать вместе с API? Я в ключ загружаю свои алгоритмы, аппаратные алгоритмы, резервирую память под разные данные. Если я подключу Armor, я так понимаю у меня же нарушиться все содержимое ключа?
А возможно ли при помощи Armor защитить только одну dll, которая будет подключаться как плагин в другую программу?
Да.
И возможно ли Armor использовать вместе с API? Я в ключ загружаю свои алгоритмы, аппаратные алгоритмы, резервирую память под разные данные. Если я подключу Armor, я так понимаю у меня же нарушиться все содержимое ключа?
Guardant Armor — это консольная утилита и при защите приложения она использует аппаратный ключ также, как и обычные консольные утилиты автоматической защиты. Т.е. на момент выполнения защиты в ключе уже должны быть запрограммированные заранее алгоритмы и другие данные, сам Armor ничего в ключ не записывает.
И ещё вопрос: возможно ли из организовать перекрёстную проверку?
Ну то есть зашита на основной программе и на дллке, которая является плагином к другой программе.
Между основной программой и дллкой есть возможность некоторой коммуникации.
Можно ли как-то проверить из программы что дллка не взломана и наоборот?
Или это нужно решать исключительно своими силами?
Между основной программой и дллкой есть возможность некоторой коммуникации.
Можно ли как-то проверить из программы что дллка не взломана и наоборот?
Какие именно механизмы коммуникации у библиотеки и приложения есть?
Доступ к исходным кодам приложения тоже имеется?
Какие именно механизмы коммуникации у библиотеки и приложения есть?
На старте приложения идёт запрос-ответ.
Соответственно длл-ка и приложение могут передать друг другу блок данных.
Доступ к исходным кодам приложения тоже имеется?
Да и головное приложение и dll-ки.
На старте приложения идёт запрос-ответ.
Соответственно длл-ка и приложение могут передать друг другу блок данных.Да и головное приложение и dll-ки.
Как вариант можно при помощи Guardant API организовать перекрестную проверку рандомных блоков данных, точнее проверку подписи (ф-ии GrdSign и GrdVerifySign) таких блоков. Причем генерировать данные для подписи лучше не только на старте приложения и загрузке библиотеки, но и по другим событиям (например, при некоторых действиях пользователя, по временным меткам, счетчикам и т.п.).
Т.е. приложение генерирует данные, отправляет для подписи в ключ, получает буфер с подписанными данными и отдает его в библиотеку. Библиотека выполняет проверку подписи и, если все в порядке, то продолжает работать и в свою очередь также генерирует данные, подписывает их при помощи аппаратного ключа, а приложению отдает для проверки.
Таким образом библиотека и приложение могут производить некую взаимную аутентификацию и проверку наличия нужного аппаратного ключа. Но это не защита именно кода самого приложения, для этого есть Guardant Armor.
Ну, можно рассматривать 2 ситуации:
1. С программы и/или с длл-ки удалось "снять" защиту и система работает либо полностью без защиты, либо частично, позволяя перехватить данные на "взломанном" компоненте.
2. Во время работы системы изменяется код одного из компонентов, что позволяет обходить защиту.
Вопрос был именно про 1-вый случай. Со вторым, надеемся, Armor разберётся. :)
Хотя, как мне кажется, возможность коммуницировать со связанными приложениями может серьёзно поднять уровень защиты и это было бы не плохо добавить это в штатные режимы автозащиты. :)
Вопрос был именно про 1-вый случай. Со вторым, надеемся, Armor разберётся. :)
Вообщем то Guardant Armor нужен и для 1-го случая, а если надо, то дополнительно усилить защиту можно реализовав свои уникальные, хитрые проверки ключа.
Вообщем то Guardant Armor нужен и для 1-го случая, а если надо, то дополнительно усилить защиту можно реализовав свои уникальные, хитрые проверки ключа.
Под 1-ым случаем я имел в виду, что приложение при старте должно как-то проверить что dll-ка под защитой.
Причём длл-ка подгружаемая сторонним процессом.
И наоборот, dll-ка должна убедится, что приложение не изменено. Причём приложение не которое его грузит, а то, которое инициирует его загрузку.
Можно использовать для этого механизм подписи SignTool из WinSDK.
Т. е. подписываем все модули (exe и dll) секретным ключём разработчика, а на старте проверяем что модули не изменены.
Или Guardant Armor самостоятельно может отследить что dll-ку, например подменили?
Или Guardant Armor самостоятельно может отследить что dll-ку, например подменили?
В определенном смысле да, т.е. сам принцип работы защищенного приложения такой, что виртуализированные и зашифрованные ф-ии выносятся в специальное хранилище ("по умолчанию" protectstorage.dll) куда и передается управление после вызова защищенных ф-ий.
А если библиотеку и приложение защитить таким образом, что у них будет общее хранилище, то на его уровне и будет контролироваться валидность компонентов приложения (\защ.exe\ —> вызов —> protectstorage.dll <— вызов <— \защ.dll\).
Чтобы подменить библиотеку или исполняемый файл придется пропатчить все вызовы к хранилищу, да еще и так, чтобы все приложение осталось работоспособным. По сути, все сводится к тому, чтобы это было настолько трудоемко делать, что просто бессмысленно. Но в явном виде сообщать что "кто-то подменил библиотеку", Armor не умеет сейчас и не понятно есть ли в этом смысл.
У нас приложение и dll-ка плагин в разных каталогах.
Я правильно понимаю, что можно защитить приложение и dll-ку вместе, а потом protectstorage.dll поместить в общий каталог типа windows\system32?
Ну и при этом приложение и dll-ка плагин должны быть одной разрядности.
Я правильно понимаю, что можно защитить приложение и dll-ку вместе, а потом protectstorage.dll поместить в общий каталог типа windows\system32?
Да. Или добавить путь к нужному каталогу в переменную среды path .
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Guardant → Технологии защиты → Электронная цифровая подпись
