Серийный номер ПЛК (привязка выполнения кода к конкретному ПЛК)

[ongleb]

Простейшая схема для атмеги
8-ка конечно совсем слабенькая
Но по большему счету задержка, если не больше 3-х секунд, для шифрующего устройства только на пользу
Если ее производительности все же будет недостаточно, можно взять атмегу посерьезнее даташит на 90% тот же. Схема сильно не изменится.

Кстати наверняка есть мастера работы с PIC'ами. Очень быстрые микрухи.

Короче было бы желание
Был бы продукт, достойный защиты
Проблема решаема

И поломать таую защиту дольше и дороже чем написать прогу для ПЛК с нуля

[Yegor]

Клёво, но ваша схема привязывает код к этому аппаратному ключу, а не к ПЛК. Если, допустим, топикстартер хочет, чтобы без него не меняли контроллер, то такой ключ не поможет.

SysLibMem'ом на предмет каких-нибудь уникальных для экземпляра констант в памяти пошаритьсяразве что. Только при этом никаких гарантий, что оно однажды не свалится в самый неподходящий момент с ошибкой доступа.

[ongleb]

Клёво, но ваша схема привязывает код к этому аппаратному ключу, а не к ПЛК. Если, допустим, топикстартер хочет, чтобы без него не меняли контроллер, то такой ключ не поможет.
...
...

...привязывает код к этому аппаратному ключу, а не к ПЛК
ИМЕННО
в этом и прелесть
у покупателя в зипе вполне может храниться еще один контроллер с прошитым программным кодом
но при этом он сможет его запустить только с этим "ключем"
по большему счету можно заказчику предоставить в комплекте даже CD с программой тиражирования и файлом дампа
работоспособным будет только количество контроллеров соответствующее количеству ключей
т.е.

СИТУАЦИЯ 1.
топикстартер написал полезный и коммерчески успешный код
заказчик пожлобился и решил что лучше заплатить топикстартеру за единичное исполнение
и даже от исходника отказался (чтобы еще сильнее минимизировать капиталовложения)
сам же начал тиражировать устройство и барыжить направо и налево
топикстартеру ОБЫДНО.

СИТУАЦИЯ 2.
топикстартер на зарплате. и опять же написал полезный и коммерчески успешный код
работодатель производит автоматизированные установки
но покупатели покупают эти установки по одной штуке.
после чего повторяют у себя в механической мастерской, копируют код из купленного ПЛК и имеют 30 экземпляров.
работодателю ОБЫДНО.

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

Я уж не знаю о каком коде идет речь.
Если автор считает, что код достоин защиты, то почему у него не должно быть такой возможности?

А если топикстартер хочет, чтобы без него не меняли контроллер? (ну в смысле один на другой, который пылился 3 года в зипе)
Ну есть более простые варианты
- железный шкаф с замком и пломбой
- злой охранник
и т.д.

[ongleb]

вообще неплохая идея для ОВЕН'а

Я думаю их схемотехники и программеры способны реализовать ее в нескольких вариантах
- версия для RS-485
- версия для RS-232
- версия для RS-232 (прозрачная)

каждый из этих вариантов может быть
- лицензионным ключем
- Trial-ключем на количество запусков
- Trial-ключем на количество дней со дня первого запуска

наверняка их программеры могут реализовать даже некую типизированную библиотеку для codesys
это позволило бы пользоваться ключами не только приверженцам ST или IL, способным
самостоятельно реализовать алгоритм дешифровки, но и рисовальщикам.

на сколько я понимаю нехватает только информации о спросе на подобные средства

Формфактор?.. Да думаю им виднее и без наших хотелок.

[ongleb]

...
...
...
SysLibMem'ом на предмет каких-нибудь уникальных для экземпляра констант в памяти пошаритьсяразве что. Только при этом никаких гарантий, что оно однажды не свалится в самый неподходящий момент с ошибкой доступа.

SysLibMem
· SysMemAlloc
· SysMemFree
· SysMemMove
· SysMemSet
· SysMemCmp
· SysMemCpy
· SysMemSwap

Не вижу средств достижения. Разве что SysMemCpy. Так эта же функция может помочь в изготовлении клона
соответственно не вариант

любая функция записи идентификатора в какую ни будь записываемую энергонезависимую область, допускающую и чтение и запись, работает только до тех пор, пока за клонирование не взялся грамотный человек

для толковой защиты без использования внешних устройств нужен идентификатор из Read-Only области

если такого нету то при построении внешнего модуля нужно использовать несколько более сложные принципы
1 наличие не считываемой извне области памяти для хранения закрытого ключа а при необходимости и trial'ьного счетчика
2 относительно криптостойкий алгоритм шифрования данных перед отправкой из идентифицирующего устройства в защищаемую программу
3 продуманный протокол обмена

[Дмитрий Артюховский]

Кому надо давно уже придумали себе внешние ключи на какой-нить порт. А овеновцы осознанно не делают меток привязки по политическим мотивам ))) Им нужно контроллеры продавать, и не важно кто их купит - вы, или копирующий вашу разработку, потребитель. Кроме того, такой модуль достаточно сложен в использовании, а таргет-группа потребителей не очень R-TRIG использовать умеют. А не до конца продуманная привязка хранит в себе много потенциальных отказов во время эксплуатации.

Вот сдали вы свою работу, а через год привязка глюкнула... вас искать будут, или просто скажут что контроллер ненадежный?

p.s. Есть недокументированные метки, поищите холивары по этому поводу на форуме пару лет назад.

[ongleb]

"а через год привязка глюкнула" это конечно довод. Спору нет.
работая в качестве фрилансера, передавать разработку с НЕисключительными правами конечно геморройно но реально
если же привязку продает контора, там все проще

в любом случае я для себя наверняка десяточек таких ключей сделаю
просто для того чтобы
1 - защитить код предоставляемый заказчику на период опытной эксплуатации
2 - отработать механизм на случай если заказчику потребуется

барыжить их на сторону по почте что то как то не хочется
ответственности много а профит при мелкосерийном производстве копеечный