Я правильно понимаю, что можно защитить приложение и dll-ку вместе, а потом protectstorage.dll поместить в общий каталог типа windows\system32?

Да. Или добавить путь к нужному каталогу в переменную среды path .

Ну и при этом приложение и dll-ка плагин должны быть одной разрядности.

Или Guardant Armor самостоятельно может отследить что dll-ку, например подменили?

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

А если библиотеку и приложение защитить таким образом, что у них будет общее хранилище, то на его уровне и будет контролироваться валидность компонентов приложения (\защ.exe\ —> вызов —> protectstorage.dll <— вызов <— \защ.dll\).

Чтобы подменить библиотеку или исполняемый файл придется пропатчить все вызовы к хранилищу, да еще и так, чтобы все приложение осталось работоспособным. По сути, все сводится к тому, чтобы это было настолько трудоемко делать, что просто бессмысленно. Но в явном виде сообщать что "кто-то подменил библиотеку", Armor не умеет сейчас и не понятно есть ли в этом смысл.

Вообщем то Guardant Armor нужен и для 1-го случая, а если надо, то дополнительно усилить защиту можно реализовав свои уникальные, хитрые проверки ключа.

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

Можно использовать для этого механизм подписи SignTool из WinSDK.
Т. е. подписываем все модули (exe и dll) секретным ключём разработчика, а на старте проверяем что модули не изменены.

Или Guardant Armor самостоятельно может отследить что dll-ку, например подменили?

Вопрос был именно про 1-вый случай. Со вторым, надеемся, Armor разберётся. :)

Вообщем то Guardant Armor нужен и для 1-го случая, а если надо, то дополнительно усилить защиту можно реализовав свои уникальные, хитрые проверки ключа.

2. Во время работы системы изменяется код одного из компонентов, что позволяет обходить защиту.

Вопрос был именно про 1-вый случай. Со вторым, надеемся, Armor разберётся. :)

Хотя, как мне кажется, возможность коммуницировать со связанными приложениями может серьёзно поднять уровень защиты и это было бы не плохо добавить это в штатные режимы автозащиты. :)

На старте приложения идёт запрос-ответ.
Соответственно длл-ка и приложение могут передать друг другу блок данных.

Да и головное приложение и dll-ки.

Как вариант можно при помощи Guardant API организовать перекрестную проверку рандомных блоков данных, точнее проверку подписи (ф-ии GrdSign и GrdVerifySign) таких блоков. Причем генерировать  данные для подписи лучше не только на старте приложения и загрузке библиотеки, но и по другим событиям (например, при некоторых действиях пользователя, по временным меткам, счетчикам и т.п.).

Т.е. приложение генерирует данные, отправляет для подписи в ключ, получает буфер с подписанными данными и отдает его в библиотеку. Библиотека выполняет проверку подписи и, если все в порядке, то продолжает работать и в свою очередь также генерирует данные, подписывает их при помощи аппаратного ключа, а приложению отдает для проверки.

Таким образом библиотека и приложение могут производить некую взаимную аутентификацию и проверку наличия нужного аппаратного ключа. Но это не защита именно кода самого приложения, для этого есть Guardant Armor.

Какие именно механизмы коммуникации у библиотеки и приложения есть?

На старте приложения идёт запрос-ответ.
Соответственно длл-ка и приложение могут передать друг другу блок данных.

Да и головное приложение и dll-ки.

Между основной программой и дллкой есть возможность некоторой коммуникации.
Можно ли как-то проверить из программы что дллка не взломана и наоборот?

Какие именно механизмы коммуникации у библиотеки и приложения есть?
Доступ к исходным кодам приложения тоже имеется?

Ну то есть зашита на основной программе и на дллке, которая является плагином к другой программе.
Между основной программой и дллкой есть возможность некоторой коммуникации.
Можно ли как-то проверить из программы что дллка не взломана и наоборот?

Или это нужно решать исключительно своими силами?

А возможно ли при помощи Armor защитить только одну dll, которая будет подключаться как плагин в другую программу?

Да.

Guardant Armor — это консольная утилита и при защите приложения она использует аппаратный ключ также, как и обычные консольные утилиты автоматической защиты. Т.е. на момент выполнения защиты в ключе уже должны быть запрограммированные заранее алгоритмы и другие данные, сам Armor ничего в ключ не записывает.

Под Armor проверки начинают медленно работать, и запуск становится очень долгим. Защита конечно хорошая, но не всегда требуется такой уровень.

Запускали приложение под профайлером?
Также можно исключить из защиты заведомо тяжеловесные функции перечислив их в специальном *.ini-файле (опция -INI=<ini-файл>).

Здравствуйте.
Вопрос возник от того, что кроме основного приложения в проекте существует ещё несколько нативных dll.
Причём одна из них грузится сторонним приложением.
Вот их целостность и хочется контролировать.

Эти библиотеки также можно защитить и привязать к ключу с помощью Guardant Armor.