Приветствую всех!
Задача в следующем - необходимо привязать выполнение кода к конкретному ПЛК. Отсюда вопрос - есть ли в CoDeSys функция считывания серийного номера ПЛК, и есть ли вообще у ПЛК этот номер? Может быть функция считывания MAC-адреса (насколько известно он уникален для каждого ПЛК).
Есть ли какие альтернативные варианты? Может кто уже решал такую задачу?
Здравствуйте, Alex_Kos.
Мак-адрес легко меняется на ПЛК1хх, серийного номера получить в кодесис на сколько я знаю не возможно :-( хотя давно уже всем форумом ждем, верим и надеемся, увидеть его в модуле "статистика" :-)
Из альтернативных вариантов - если на ПЛКхх есть аналоговые входа, то представители ОВЕН при желании могут помочь с этим вопросом.
P. S. Самый лучший вариант - делать дешево и хорошо, что бы обращаться на сторону было дороже ;)
Вопрос, а зачем ? Нормальный адекватный заказчик потребует по ТЗ исходники кода или пойдет к другому. А считать программу из ПЛК нельзя. К тому же можно запаролить.
Считать нельзя исходный код. А вот программу - проблем нет. Для ПЛК63/73 есть программа тиражирования. Для ПЛК1хх вроде тоже есть средства.Цитата:
Сообщение от melky
Я бы чуть перефразировал:
Исходную программу скачать нельзя.
А вот скомпилированный код - можно. Но толку от него - ноль. Он НЕ ДЕКОМПИЛИРУЕТСЯ.
Это ж какую такую "нетленку" надо сваять на Овене, чтобы озадачиться подобным вопросом?
Паранойя осложнённая манией величия?
не обязательно ))) например, можно разрабатывать изделие на соглашении о разделе прибылей... писать программу и обеспечивать поддержку изделия получая деньги от количества отгруженных установок.... удаленному разработчику не всегда очевидно количество отгружаемой с завода продукции!Цитата:
Сообщение от Ryzhij
кроме того удобно делать удаленную диспетчерезацию опираясь на уникальный код установки... вот модем за 500 рублей имеет IMEI, а ПЛК за 5000 нет....
далее, современная технологическая установка имеет набор стандартных приводов и интеллектуальный алгоритм ими управляющий.... стоимость установки скажем миллион, а привода в закупке "тянут" на 100 тыс.... вполне ожидаемо и понятно желание покупателя данной установки расширить свое производство по более приемлемой цене ))
Если изготовитель хочет кинуть разработчика, он всегда это легко сделает, даже если защитить нетленку! :p
В крайнем случае наймет другого, более покладистого разработчика! Это реалии, а любая защита такого рода приносит только головную боль всем! Если алгоритм сложный, то никто кроме разработчика в нем не разберется!:cool:
Спасибо за комментарии к вопросу )) особенно за "нетленку" и про манию величия )) Вопрос я так понимаю остался открытым
Если вас наняли для разработки и заплатили деньги, то кодом вашим, заказчик может распоряжаться по собственному усмотрению.
Я бы к примеру договор на др. условиях с разработчиком не заключал.
попробуй прочитать файл local_addres.dat в нем храницо мак адрес
прям в первой строке в формате EMAC=XX:XX:XX:XX:XX:XX[Пробел]
Здравствуйте, Лэзи.
Так значение МАК-адреса легко меняется :-( единственное, что этим добъётесь то, что в одной сети контроллеры работать не будут. Вот пожалуй и все, что может предоставить такая защита.Цитата:
Сообщение от lazy
защита и ее взлом это же как борьба снаряда и брони. я и промышленные протекторы взламывал. )
если на руках будут исходники которые вдруг не заработают на втором ПЛК то возможно и МАК адрес менять не придецо.
где то же в коде сравнение будет? проще там поправить раз и навсегда )
если глубоко теоретически пофантазировать... возможно запрашивать мак адрес у покупателей проги. генерить на его основе (хеши там всякие). лицензионный ключ который писать в файл. (этот файлик отдавать) покупателю. Плк при загрузке читает мак вычисляет хеш сверяецо с ключом в файле. но опять же. где то в коде будет ВООL который раз и насвегда можно поставить в TRUE и не платить лишнего )
Совершенно верно. Для разработчика такая схема тоже наиболее приемлема. Особенно если заказчик -Газпром с мешком денег. Работа принята - деньги получены - исходники переданы.Цитата:
Сообщение от lara197a
Но не всем так везет, есть достаточно много мелких работ, на которые у заказчика нету (жалко!) денег. Но есть его честное слово расплатиться как только, так сразу! ))) И наличие технической возможности оживить желание расплатиться спустя, скажем, полгода успешной работы установки весьма пользительно!
Кроме того, есть варианты когда заказчику нужна не разработка, а единичная работающая установка.... ну покупают же люди телевизор, не особо парясь вопросом как создать его клон. Ведь стоимость ПК с программой ворд намнооооого меньше чем стоимость разработки этой самой программы! ))))
То есть вы согласны работать за еду в надежде, что когда нибудь с вами, может быть расплатятся? Но при этом подложить гаду заказчику подлянку? Это, батенька, шантажом называется! По моему надо договариваться об условиях заранее, а то как-то некрасиво. Но я бы с таким заказчиком работать не стал.Цитата:
Сообщение от Дмитрий Артюховский
Иногда знание о том, что он "такой" приходит после.Цитата:
Сообщение от Алексей Дмитриев
Согласен, но с приобретением опыта в этих делах уже обещаниям не веришь.Цитата:
Сообщение от Валенок
хз конечно где такие заказчики, может быть имелась ввиду работа на себя и написание софта для автоматизаторных контор, однако если брать работу в конторе по автоматизации, то единственное что волнует заказчика касательно системы управления - это её корректная работа. Про исходный код никто никогда даже не задумывался, потому что для заказчика он бесполезен. Другой вопрос, если производится продукт серийный то это проблема, ибо считать скомпилированный проект и просто перенести в другой ПЛК особых проблем нет.Цитата:
Сообщение от melky
оплата с разбивкой платежей, это не совсем "работа за еду", а назовем так - долговременные инвестиции! Подлянкой можно считать недокументированные возможности (а зачастую и просто ошибки!), а если они прямо указаны в описании, то о чем речь? Вот например, спутниковые ресиверы имеют ID, и оператор может отключать не понравившегося абонента.... это подлянка, или функционал значительно расширяющий гибкость способов продажи услуг???Цитата:
Сообщение от Алексей Дмитриев
как часто случается
на вопрос "как сделать?"
получаем типовой ответ для форумов "на фига оно тебе?"
могу предложить выход (точнее идею)
геморойный конечно но все таки
1 построить внешний "hasp" к примеру на базе atmega + max232 (atmega позволяет защитить свою прошивку в т.ч. и закрытый ключ)
3 передавать в него текущие энергонезависимые параметры + TimeStamp
4 проверять в atmega чтобы пришедший TimeStamp был больше предыдущего
5 в atmega шифровать входное значение NTRUEncrypt'ом (http://en.wikipedia.org/wiki/NTRU или http://www.wikisec.ru/index.php?titl...ткрытым_ключом)
6 полученную строку расшифровывать на стороне ОВЕН'а и ни с чем не сравнивая укладывать обратно в энергонезависимые параметры
положительные результаты
- В процессе выполнения вполне можно понять что "HASP" отсутствует или левый а дальше, если хочется, можно на это реагировать злобными сообщениями "DEMO MODE" а можно не реагировать а продолжать работать с некорректными настройками.
- копирование с помощью программы тиражирования становится бессмысленным без копии "HASP'a"
- снифферить rs-232 становится бесполезно
отрицательные результаты
- придется в каждую копию вписывать открытый ключ (хотя бы как серийник от вашей прошивки)
- такому "HASP'у" скорее всего придется подавать внешнее питание
можно критиковать
Простейшая схема для атмеги
8-ка конечно совсем слабенькая
Но по большему счету задержка, если не больше 3-х секунд, для шифрующего устройства только на пользу
Если ее производительности все же будет недостаточно, можно взять атмегу посерьезнее даташит на 90% тот же. Схема сильно не изменится.
Кстати наверняка есть мастера работы с PIC'ами. Очень быстрые микрухи.
Короче было бы желание
Был бы продукт, достойный защиты
Проблема решаема
И поломать таую защиту дольше и дороже чем написать прогу для ПЛК с нуля
Клёво, но ваша схема привязывает код к этому аппаратному ключу, а не к ПЛК. Если, допустим, топикстартер хочет, чтобы без него не меняли контроллер, то такой ключ не поможет.
SysLibMem'ом на предмет каких-нибудь уникальных для экземпляра констант в памяти пошаритьсяразве что. Только при этом никаких гарантий, что оно однажды не свалится в самый неподходящий момент с ошибкой доступа.
...привязывает код к этому аппаратному ключу, а не к ПЛКЦитата:
Сообщение от Yegor
ИМЕННО
в этом и прелесть
у покупателя в зипе вполне может храниться еще один контроллер с прошитым программным кодом
но при этом он сможет его запустить только с этим "ключем"
по большему счету можно заказчику предоставить в комплекте даже CD с программой тиражирования и файлом дампа
работоспособным будет только количество контроллеров соответствующее количеству ключей
т.е.
СИТУАЦИЯ 1.
топикстартер написал полезный и коммерчески успешный код
заказчик пожлобился и решил что лучше заплатить топикстартеру за единичное исполнение
и даже от исходника отказался (чтобы еще сильнее минимизировать капиталовложения)
сам же начал тиражировать устройство и барыжить направо и налево
топикстартеру ОБЫДНО.
СИТУАЦИЯ 2.
топикстартер на зарплате. и опять же написал полезный и коммерчески успешный код
работодатель производит автоматизированные установки
но покупатели покупают эти установки по одной штуке.
после чего повторяют у себя в механической мастерской, копируют код из купленного ПЛК и имеют 30 экземпляров.
работодателю ОБЫДНО.
ключики же позволяют продавцу, будь то топикстартер или его работодатель, продавать свой товар с НЕисключительными правами
если я не ошибаюсь, практически весь платный софт в мире продается с НЕисключительными правами.
и разница между исключительными и НЕисключительными обычно очень существенная.
Я уж не знаю о каком коде идет речь.
Если автор считает, что код достоин защиты, то почему у него не должно быть такой возможности?
А если топикстартер хочет, чтобы без него не меняли контроллер? (ну в смысле один на другой, который пылился 3 года в зипе)
Ну есть более простые варианты
- железный шкаф с замком и пломбой
- злой охранник
и т.д.
вообще неплохая идея для ОВЕН'а
Я думаю их схемотехники и программеры способны реализовать ее в нескольких вариантах
- версия для RS-485
- версия для RS-232
- версия для RS-232 (прозрачная)
каждый из этих вариантов может быть
- лицензионным ключем
- Trial-ключем на количество запусков
- Trial-ключем на количество дней со дня первого запуска
наверняка их программеры могут реализовать даже некую типизированную библиотеку для codesys
это позволило бы пользоваться ключами не только приверженцам ST или IL, способным
самостоятельно реализовать алгоритм дешифровки, но и рисовальщикам.
на сколько я понимаю нехватает только информации о спросе на подобные средства
Формфактор?.. Да думаю им виднее и без наших хотелок.
SysLibMemЦитата:
Сообщение от Yegor
· SysMemAlloc
· SysMemFree
· SysMemMove
· SysMemSet
· SysMemCmp
· SysMemCpy
· SysMemSwap
Не вижу средств достижения. Разве что SysMemCpy. Так эта же функция может помочь в изготовлении клона
соответственно не вариант
любая функция записи идентификатора в какую ни будь записываемую энергонезависимую область, допускающую и чтение и запись, работает только до тех пор, пока за клонирование не взялся грамотный человек
для толковой защиты без использования внешних устройств нужен идентификатор из Read-Only области
если такого нету то при построении внешнего модуля нужно использовать несколько более сложные принципы
1 наличие не считываемой извне области памяти для хранения закрытого ключа а при необходимости и trial'ьного счетчика
2 относительно криптостойкий алгоритм шифрования данных перед отправкой из идентифицирующего устройства в защищаемую программу
3 продуманный протокол обмена
Кому надо давно уже придумали себе внешние ключи на какой-нить порт. А овеновцы осознанно не делают меток привязки по политическим мотивам ))) Им нужно контроллеры продавать, и не важно кто их купит - вы, или копирующий вашу разработку, потребитель. Кроме того, такой модуль достаточно сложен в использовании, а таргет-группа потребителей не очень R-TRIG использовать умеют. А не до конца продуманная привязка хранит в себе много потенциальных отказов во время эксплуатации.
Вот сдали вы свою работу, а через год привязка глюкнула... вас искать будут, или просто скажут что контроллер ненадежный?
p.s. Есть недокументированные метки, поищите холивары по этому поводу на форуме пару лет назад.
"а через год привязка глюкнула" это конечно довод. Спору нет.
работая в качестве фрилансера, передавать разработку с НЕисключительными правами конечно геморройно но реально
если же привязку продает контора, там все проще
в любом случае я для себя наверняка десяточек таких ключей сделаю
просто для того чтобы
1 - защитить код предоставляемый заказчику на период опытной эксплуатации
2 - отработать механизм на случай если заказчику потребуется
барыжить их на сторону по почте что то как то не хочется
ответственности много а профит при мелкосерийном производстве копеечный