Примеры: Защищайтесь, господа разработчики!
Очень занятно, Сергей, спасибо. Сам давно, но крайне нерегулярно размышляю над проблемой эффективной обфускации и понимаю, что все самое лучшее ты сюда выкладывать не стал бы.
P.S. Название темы неоднозначно: вначале подумал, что ты обращаешься к разработчикам терминала и бросаешь им вызов.
Делаем Dll. Защита- привязка к hardware + использование ключей RSA для создания текста авторизации. Mql дает данные, Dll делает все расчеты. Копаться в ассемблере Си++ программы, скомпилированной с оптимизацией- это, ИМХО, совсем не то.
Кстати, вот Вам еще шикарная идея: сделайте полный инлайн всех функций :-).
Тема задана нужная и озвучены решения, которые и не так уж очевидны. За это большое человеческое СПАСИБО.
А вот по поводу защиты есть все же более универсальный способ. Зачем пользователю сообщать, что программа несанкционировано скопирована? Пусть в нескольких функциях, производящих расчет сигнала будет использован предложенный в статье ключ (номер счета). И пусть программа использует этот неправильный пароль или номер счета. В результате, алгоритм будет заведомо нарушен, что приведет к выдаче неправильных сигналов или вообще к краху программы. Ну и, конечно, при продаже или другом распространении сообщать клиенту, что программа только для него и ее использование в других условиях невозможно.
Думаю, многие сталкивались даже с исходниками (имеются в виду не декомпилированные файлы, а именно исходники, авторов которых найти трудно или они себя не указали), где производился какой-нибудь сложный, на первый взгляд, математический расчет. По виду этих расчетов практически невозможно понять, что именно рассчитывается и с какой целью. Поэтому подобное запутывание следов без указания конечного результата, к которому должен прийти взломщик, даст практически 100%-ую гарантию "правильного" распространения софта.
И, конечно же, не стоит забывать о выпуске новых релизов программы, что просто сделает труд шаек взломщиков нерентабельным.
И, конечно же, не стоит забывать о выпуске новых релизов программы, что просто сделает труд шаек взломщиков нерентабельным.
А вот по поводу защиты есть все же более универсальный способ. Зачем пользователю сообщать, что программа несанкционировано скопирована? Пусть в нескольких функциях, производящих расчет сигнала будет использован предложенный в статье ключ (номер счета). И пусть программа использует этот неправильный пароль или номер счета.
Позабавили пассажи про "отойти от компа в дилинговом зале" и "требуют за свои деньги код, а вы им -- хер вместо кода". Жлобство, обычное совковое жлобство неконкурентоспособных товарищей.
Каждый видит то, что ожидает увидеть :)
Статья - это не документация по использованию. Это кроме всего прочего работа писателя-журналиста. Вам было бы приятнее читать
Сильные осадки с мокрым снегом и ураганными порывами ветра
вместо
Буря мглою небо кроет,
Вихри снежные крутя,
То как зверь она завоет,
То заплачет как дитя...
???
Слишком сложный вопрос раскрыт весьма слабо.
По опыту - ручная деобфускация 200 кб кода на паскале занимает пару дней, естественно при желании (все идентификаторы имели вид "буква-цифра", строковые константы (подсказки/сообщения) отсутствовали вообще, сама программа являлась нетривиальным парсером).
Сравнивать критичные для работы переменные с какими-либо значениями напрямую (пусть даже они генерируются алгоритмически - "char[50]+char[48]+...") - это тихий ужас. Если советник декомпилирован - можно вставить вызов Print() и посмотреть значение константы и при необходимости его поменять. Странно, что вы применяете и рассматриваете этот способ, ведь вопрос решаем.
Кроме того, можно написать несколько версий разных функций и для каждого покупателя генерировать свой вариант кода (свой набор функций).
Можно реализовать стековую виртуальную машину с простейшей системой команд:
- арифметические
- передачи управления
- торговые функции
- прочие внешние функции
- мусорные (их исполнение для каждой сборки может быть различным)
В принципе это не трудно (хотя времени убить прийдется немало), но на восстановление алгоритма уйдет немало времени (ведь для начала нужно разобраться с кодом на mql, а лишь потом переходить к уровню абстракции виртуальной машины - а тут всё может быть куда веселее). Такая программа на mql может состоять из открытого (но обфусцированного) кода виртуальной машины и файла данных с кодом советника/индикатора, записанным в системе команд виртуальной машины.
*added* "Делиться всеми секретами открыто - нельзя, потому, что тем самым вы объясняете потенциальным взломщикам как можно с вами бороться." Защищать нужно исходя из того, что взломщику известен алгоритм работы защиты. Иначе это то же самое, что и пытаться изобретать собственный алгоритм шифрования, стойкость которого заключается лишь в том, что этот алгоритм известен лишь вам (что поправимо).
jartmailru писал(а):
Да-да!!! Чтобы собственный же заказчик, "попробовав" программу на другом счете, получил большой сюрприз.
Мы здесь говорим не об отношениях Исполнитель-Заказчик, а об отношениях Продавец-Покупатель.
Если программист имеет дело с заказчиком, когда заказчик предоставляет ТЗ, по которому пишется прорамма, нет нужды защищать код. Я в таких случаях именно этот самый код заказчику и отправляю, да еще и с подробными комментариями. Здесь никакой проблемы защиты кода нет, так как он не является собственностью программиста.
Здесь же говорится о том, что сам программист выступает в роли творца и, как любой другой человек, хочет защитить реализованную ИДЕЮ (а не код) от несанкционированного распространения. То есть в случае продажи софта программист должен быть более-менее уверен, что его разработка не "пойдет по рукам" в неограниченных количествах.
Если же покупателю нужно использовать программу на другом счете, то он может просто обратиться к продавцу с просьбой о покупке новой версии. Обычно при покупке софта одним покупателем на n-ое количество компьютеров (в нашем случае счетов) делаются неплохие скидки в пересчете на одну копию.
а я ведь нигде и не обещал, что предложу абсолютно универсальную непробиваемую защиту ;)
способы описанные в статье - это необходимый и достаточный минимум защитных функций. он позволяет защититься используя только средства MQL, собственно поэтому только они и были описаны.
про DLL, онлайн защиту, железные ключи я только упомянул, потому что в подавляющем большинстве случаев написание такой защиты будет гораздо более трудоемкой операцией чем сам защищаемый объект (ну например, индикатор МА, с каким то очень хитрым алгоритмом сглаживания). Ко всему нужно подходить с умом и понимать, когда будет достаточно зашифрованного (или захешированного) номера счета, а когда без железного ключика не обойтись.
По поводу "подстав" с неправильной работой эксперта если счет неправильный - не рекомендовал бы баловаться с такими фокусами. Вспомните Мэрфи ;) вы всегда можете гарантировать что ваша защита работает абсолютно правильно абсолютно во всех мыслимых исключительных ситуациях?! Ну например, вы разнесли по коду и значит по времени проверку номера счета и имени сервера. Первая сработала правильно, а через несколько милисекунд, чтото случилось с инетом у заказчика и вторая проверка не прошла потому что имя сервера пришло (например) в китайской кодировке. На 100% уверен что вы не будете вставлять обработки таких извратных ситуаций. И вот честно купленный эксперт злостно сливает депо у честного клиента как у какого то ворюги. Оно вам надо?....
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
New article Защищайтесь, господа разработчики! has been published:
Author: Sergey Kravchuk