Евгений писал(а):По поводу обработчиков прерываний, могу сказать, что наличие таких обработчиков серьезно затормозило бы работу ключа
Если интервал между вызовами обработчиков сделать большим (минуты или десятки минут), сами обработчики делать в формате XA и нетребовательными к ресурсам, то не сильно затормозило бы (ИМХО).
Евгений писал(а):а также потенциально привело бы к зависаниям электроники в случае ошибок при программировании
При отсутствии watch-dog таймера от ошибок программирования и зависания ключи, насколько я понимаю, не застрахованы и без обработчиков прерывания.
Евгений писал(а):другими словами, оно не стоит того, чтобы это реализовывать.
Не уверен, что имею право с вами спорить. Всё-таки опыта на этом поприще у меня пока нет. Однако ниже постараюсь, всёже, показать, почему придерживаюсь другого мнения относительно прерываний и ценности их реализации в ключах.
Евгений писал(а):Следуя вашей логике можно сделать отличную защиту без всяких прерываний таймеров реального времени.
[..]
Если нужно ограничить программу не на дату, а по количеству рабочих часов - тут вообще все тривиально.
Не так уж и тривиально. Период переполнения таймера четыре с половиной часа, а при длительных перерывах между вызовами функций ключа (например, приложение висит в трее или просто имет длительные периоды ожидания в запущенном состоянии) девайс просто мертв. То есть не может в принципе считать сколько прошло периодов.
Даже одно единственное прерывание на переполнение счетчика (раз в 4.5 часа) уже делает ключ гораздо более гибким в использовании. Без этого прерывания однозначно сказать сколько прошло времени с момента запуска программы нельзя.
Регулярная посылка нефункциональных пакетов с текущим временем во многих случаях бесполезна, так как её, зачастую, можно безболезненно блокировать.
Евгений писал(а):Думаю, конроль замедления работы может быть использован только для борьбы с отладчиками, так как подобные механизмы потенциально опасны для честных пользователей.
"Для борьбы с отладчиками" -- да, бесспорно. "Только" -- не соглашусь.
Одно дело, если у пользователя села батарейка в биосе или он обходит лицензию какого-то другого (не нашего) софта. Тут можно просто вежливо спросить у пользователя который час, если наш ключик заподозрил неладное. Другое дело, если пользователь злонамеренно тормозит часы в два-три раза. Это надо отслеживать и адекватно учитывать. Выходит ключик должен оценивать ход времени с некоторым компромиссным допуском, который нас (поставщиков ПО) не разорит и "честного" пользователя лишний раз не обидит.
Потенциально опасны для честных пользователей любые механизмы лицензирования, особенно не вполне продуманные. Здесь важно найти разумный компромисс.
Senselock, как неоднократно акцентировалось, представляет нам не готовое решение по защите и лицензированию ПО, а инструмент, позволяющий строить свои индивидуальные механизмы защиты. Любой хороший инструмент, конечно же должен быть лаконичным и максимально простым, даже если это немного снижает его функциональную гибкость. Однако, если есть возможность без больших усложнений добавить достаточно "вкусный" функционал, зачем же её упускать?
---------------
Прощу прощения за оффтоп.