Защита авторства MQL кода в МТ5. security certificates - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
к примеру
покупатель: находит в интернете информацию , пишет хочу купить
продавец: описывается механизм оплаты - если нет желания публиковать реквизиты - просит данные для персонализации
покупатель: оплачивает и высылает данные для персонализации , номер счета или фио которые и являются ключиком
продавец: отправляет товар привязанный по персональным данным.
в идеале это все!
у меня такие случаи есть, и не так мало
К сожалению это не делает жизнь сложней для некоторых любителей халявы (людей находящихся в теме). Привязка к счету тоже не решение всех проблем, любой грамотно составленный "копировальщик сделок" перенесет все данные на любой другой счет (особенно если данные копируются с МТ5 на МТ5).
На мой взгляд необходима защита не только экспертов, но и скриптов, индикаторов, библиотек и другого кода. И вот это уже более интересная и важная тема на мой взгляд.
Почему она более важная
Как известно все инструменты которые можно реализовать при помощи MQL делятся на: автоматические системы, полуавтоматы и инструменты для ручной торговли.
Также происходит деление на системы: "черные ящики", "серые ящики" и "белые" системы (системы с открытыми исходниками и явно описанной логикой).
Так вот, почти все МТС представленные в коммерческом секторе будут представлять из себя черные или серые ящики. При этом их удельный вес будет не так велик (мне представляется он не превысит 30-40%). При этом такие решения будут достаточно не гибкими (поскольку они реализуют по сути только одну стратегию).
Другое дело отдельные скрипты, библиотеки и индикаторы. Эти программные решения будут представлены во всех областях ручной и механической торговли. При этом их можно будет использовать как базовые элементы конструктора.
PS
Тут на мой взгляд стоит максимально полно обеспечить защиту, причем так чтобы не ущемлять прав разработчиков и пользователей. Единственный оптимальный путь защиты при этом? как я понимаю, тут только один - Привязка к железу.
Что бы вы там ни думали себе, привязка к железу уже давно не является эффективным способом защиты. Кстати, для человека маломальски знакомого с асмом(а таких отнюдь не единицы) снятие такой защиты дело нескольких минут. И совершенно не важно к чему вы привяжетесь. Почитайте программерские(читай хакерские) форумы и вам все станет ясно. :) А что касается "хорошей организации", попробуйте ради эксперимента привязать какую нибудь свою массовую поделку к железу и я уверен, что через некоторое время(примерно месяц или два) вы поймете, что я хотел вам сказать.
Как будто есть другие варианты защиты?
Удивлен, что вы об этом спрашиваете. Конечно есть. И очень много. Начиная от простых перекодировщиков, генераторов лицензий и заканчивая программно-аппаратными методами защиты, такими как HASP и т.п. Но практически все они, независимо от стоимости и заявленой надежности уже давно взломаны и по инету в открытом доступе гуляют кряки, кейгены и прочий софт. И смею заметить эти способы защиты на несколько порядков надежнее простой привязки к железу.
В контексте MT4/MT5 MQL4/MQL5 + DLL привязку можно делать не к железу а к номеру счета (номерам) , для реалов и/или фамилия имя , по варианту отчество
этот путь самый простой в плане защиты (именно для данной специфики) - мобилен не требует привязки к железу.
Начиная этот топик мы имели ("каждый"!) свой сертификат выданный Метаквотсами. Понятно, что это не очень пока признаный центр сертификации. Но тема эта (выдачи и поддержки сертификатов) заглохла, хотя и в 4-ке якобы такая возможность проверки подлинности есть.
Потому привязку к железу для защиты авторства - считаю "глубоким" регрессом.
Идея ( о ней в первых страничках) сводилась к реализации "штатного" алгоритма компиляции ех5 файла.
Мечталось приблизительно следующее.
Программист имеет возможность откомпилировать свою программку так, что она смогла быть корректно воспринята терминалом только при наличии слепка субключа - сложной конкатенации ключа разработчика и пользователя.
Необходимые сигнатюры ключа разработчика сидели бы в программе, как и пользовательские - в программе и в ключе на конкретном терминале.
Тогда наличие этой "лицензии-субключа" открывал бы возможность ее юзать.
Генерацию должен делать Мета-эдитор, т.е. сам разработчик - получив часть ключа от заказчика.
Так фантазировалось...
Но что-то не то выплывает из тумана.
Мне кажется, что возможность генерить ключи разработчика от центра сертификации "МТ5" и наличие в терминале процедур дешифровки ех5 с использованием этого ключа и части ключа пользователя решило бы больше проблем, чем тот "нативный сервис" - механизмы и адекватность которого вообще не могут здесь обсуждаться.
;)
Если речь идет о защите ключом, то весь инет будет завален этими самыми ключами. То есть, вместо защиты будет фикция, да еще и со сложной реализацией, заставляющей покупателя управлять ключами.
Лучше всего посмотреть на работающую схему продажи через AppStore/iTunes от Apple. Покупатель просто кликает и приобретает программы, не мучаясь необходимостью что-то передавать или использовать ключи. Покупателю достаточно иметь аккаунт на MQL5.com, на котором сохраняется история покупок и есть возможность переактивировать ранее купленные программы.
При покупке программы пользователь получает специально перекомпилированную/перезащищенную под него копию, что гораздо лучше ключей защищает продавца. Весь процесс персональной защиты будет происходить автоматически во время покупки.
Наша задача состоит в максимальном упрощении процесс покупки/продажи.
По моему в ветке пропущено обсуждение еще одной важной функции - триального периода или демоограничений. Потенциальному покупателю обоснованно хочется сначала посмотреть что он покупает. Для этого гдето нужно спрятать (зашифровать) информацию о датах и/или времени в течении которых приобретаемый продукт будет работать без ограничений. Мне кажется что встраивание в сам язык механизма шифрования с парой ключей (аля pgp) может решить не только эту но и многие другие проблемы.
Продавать имеет смысл только покупателю работающему на реальном счете (ну вроде как у него есть/должны быть средства для покупки). а раз так - привязка должна осуществляться к номеру его счета. причем номер этот должна получать/отдавать непосредственно сама платформа, чтобы просто не было места где можно найти записанный номер счета и подставить вместо него другой. Этот номер (возможно + еще какаято информация вроде имени сервера, ключевой фразы или еще чего) используется как ключ для дешифровки. У продавца должен быть встроенный в платформу механизм генерации пары ключей и шифрования ими файлов.
Что мы при этом получим? Разработчик создает файл с исходными данными: например содержащий номер счета на который дается демка и две даты с и по которую она на этом счете работает. этот файл шифруется. и отдается вместе с экспертом/скриптом/индикатором покупателю. у него (и только у него на счете) платформа сама получает по номеру счета второй полный ключ, считывает и расшифровывает закодированный файл (можно проверить контрольную сумму и ничего не возвращать если ключ оказался чужим) и отдает его в виде строки в эксперт/скрипт/индикатор. там уже сам код получив эти данные определяет как ему работать в демо или обычном режиме.
Вплоть до того, что в нем можно будет хранить параметры работы эксперта: ну например пересечение МАшек - алгоритм даже после декомпиляции будет очевиден, но вот с какими именно параметрами работают в прибыль эти МАшки может остаться "тайной", а без знания этих параметров смысла в декомпилированном эксперте нету. Конечно, здесь тоже свои дырки и можно будет чтотокакто поломать, но не зная данных лежащих в зашифрованном файле (который асмом не возьмеш) все становится намного сложнее чем просто купить у автора и продукт и его поддержку.
Итого: нужно обеспечить работу с зашифрованным контейнером и тогда каждый, запихнув туда необходимые ему данные сможет организовать самую изощренную защиту.
Господа, не забывайте, что это масс-маркет.
Вы думаете категориями работы 1:1, что покупатель и продавец будут совместно договариваться, обмениваться заявками и пересылать друг другу ключи. Конечно же, этот путь не даст возможность продавать много. Мы же предлагаем магазин быстрых продаж, где продавцу даже пальцем шевелить не придется ради продаж. И покупателю достаточно нажать кнопку "купить" и не мучаться никакими номерами счетов или генерацией ключей.
Все уже продумано. Если хотите узнать как это будет работать - попользуйтесь iPhone/iPad, покупая программы для них в AppStore.
По моему скромному мнению вариант защиты с привязкой к железу идеален, как в плане реализации, так и в плане удобства использования . Есть ещё пожелание на счет этого варианта, но о нём ниже скажу.
Варианты с привязками к номерам счетов/имени владельца и другие - не удобны, хотя это и не очевидно с первого взгляда. Вот покупатель любитель через каждую неделю менять брокера и заводить новые счета, и как быть тогда с ним - каждый раз компилировать для него продукт, а если пользователей продукта десятки и сотни? Ключи можно сплавить в сеть - тоже не вариант.
На счет привязки к железу. Пользователь может захотеть работать с продуктом на нескольких машинах, тогда нужно предусмотреть возможность привязки к нескольким вариантам железа. И если пользователь захочет проапгрейдить имеющееся в наличии железо, то тогда может быть в таких случаях нужно давать скажем 1 час, в течении которого осуществляется переход на новое железо. Как то так. Нужно продумать эти моменты. А привязывать продукт к одной/двум/трём машинам навечно как то неправильно и несправедливо по отношению к покупателю.
На счет привязки к железу. Пользователь может захотеть работать с продуктом на нескольких машинах, тогда нужно предусмотреть возможность привязки к нескольким вариантам железа. И если пользователь захочет проапгрейдить имеющееся в наличии железо, то тогда может быть в таких случаях нужно давать скажем 1 час, в течении которого осуществляется переход на новое железо. Как то так. Нужно продумать эти моменты. А привязывать продукт к одной/двум/трём машинам навечно как то неправильно и несправедливо по отношению к покупателю.
Но при этом мы разрешим запускать в тестере (тестер агенте) защищенных экспертов, чтобы пользователи могли самостоятельно проверить работоспособность эксперта в тестере и не покупать кота в мешке.
Есть эксперты, в которые вшита история. Или которые умеют считывать историю из исторический базы. Такие эксперты-пустышки показывают замечательные результаты в тестере. Будет ли какая-нибудь защита от такого рода мошенничества? Особенно, если эксперт поставляется вместе с DLL...
Как сервис будет бороться за свою репутацию на случай MQL5-кода + вредоносный DLL (от шпионов до вирусов)?