znseday пишет:Я хочу "выжать" максимум из автозащиты. На сколько я понял, поля общего назначения можно редактировать. Следовательно, если привязать программу к, например, серийному номеру ключа, то можно изготовить дубликат ключа, а если к ID - то нет.
Изготовить "дубликат" Вашего ключа можно только точно зная коды доступа, которыми прошиты именно Ваши ключи, и ту информацию, которая записана в конкретном ключе. Другими словами, атака именно на аппаратную часть защиты приложения (на ключ), как правило, весьма маловероятна и не оправданна относительно, как минимум, трудозатрат на выполнение таковой.
Отдельно хочу отметить и то, что опции привязки к электронному ключу (/US, /UV и.пр) не являются основным инструментом защиты и в первую очередь нужны именно для реализации гибкого и удобного механизма поиска и идентификации нужного ключа.
Для построения более надежной защиты следует обращать внимание на опции, влияющие на защищенность приложения (/RIP_CODE, /IMPORT_HOOK, /ATR и.др), которые завязаны на работу с аппаратными алгоритмами, записываемыми (автоматически через мастер лицензирования или в ручную, при защите через консоль, например) в ключ. В таком случае можно использовать абсолютно идентичные наборы опций автозащиты для каждой копии приложения, без жесткой привязки к ID ключа, но при этом, разные определители (секретные ключи) аппаратных алгоритмов. Например, для клиента "А" защищено 20 копий приложения с некоторыми параметрами автозащиты и одним (на 5 ключей) определителем аппаратного алгоритма и с такими же опциями автозащиты, но другим определителем, защищено приложение для клиента "Б". В результате приложение клиента "А" не будет работать с ключами клиента "Б", хотя параметры автозащиты для их приложений использовались идентичные.
Для оптимизации работы приложения, защищенного тяжеловесными опциями (/RIP_CODE и /IMPORT_HOOK), следует использовать профайлер (с профалером используются опции /RIP_CODE_LIST и /IMPORT_HOOK_LIST).