Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Что касается ЕХ4, то декомпилировался скорее всего Еditor.
А он похоже голый от защит. Нет там финансовых потоков.
А если ключами будут оперировать обе защищенные компоненты (Client & Editor) - надежды на успех больше.
;)
5 копеек...
1. Пользование тем или иным продуктом в большинстве (если не во всех) требуется при наличии коннекта.
2. Таким образом само собой напрашивается "ключ" в виде размещенного в сети (на сайте автора) некого
сервиса, куда при запуске "обратится" терминал с запущеным на нём индикатором или экспертом...
3. И соответственно проблема декомпиляции уже не проблема.
Вне категории. Продукт должен быть действительно интересен.
Обзор продаваемого на "основе" там супер секретных алгоритмов
показал что ничего интересного и тем более полезного нет... увы...
Впринципе, сам алгоритм расчётов супер-пуперский, если уж афтор так считает, можно разместить тоже на сайте.
Точнее организовать в эксперте лишь обращение и реализацию в торговые процессы, что не является секретом хоть в открытую публикуй.
- зксперт посылает запрос (по подписке)
- принимает значения
- обрабатывает
- торгует
- попутно может отрисовкой занятся
//
тож самое для индикатора, за исключением торговли
Саму подписку организовать по номеру счёта...
В общем, как грил один римский император: разделяй и властвуй!
Дело в том, что проблема декомпиляции все равно - проблема. Если весь необходимый код находится внутри советника, то декомпиляция в совокупности с известным работающим ключем дает исходный код советника со всеми вытекающими последствиями.
Если же часть кода расположена на сайте, то это очень ненадежное решение. Любой сбой в работе сайта может привести к умопомрачительным потерям в деньгах клиентов.
Кроме того, когда-то где-то я видел упоминание о том, что MQL5-код компилируется в нативный код процессора. Я не знаю: на самом деле так или нет, но если так, то это серьезная дыра в защите от декомпиляции.
А как это может снизить безопасность?
Добавление кода предотвращается использованием асимметричной криптографии - при достаточной длине ключа подделать подпись будет невозможно.
Если вы о декомпиляции - её автоматизация для машинного кода весьма затруднительна. Я не имею ввиду дизассемблирование - оно возможно, т.к. процессор сам как-то должен исполнять код. Попытки автоматической декомпиляции предпринимаются (http://www.hex-rays.com/), но в основном они сводятся к анализу всех возможных вариантов порождаемого компилятором кода (что становится вовсе нетривиальной задачей, т.к. как я понял преобразование в машинный код будет осуществляться на стороне metaquotes). Если же привязать работу кодогенератора к фазе луны (т.е. чтобы конструкции компилировались по-разному) - автоматизация декомпиляции станет вообще нереальной!
А как это может снизить безопасность?
Добавление кода предотвращается использованием асимметричной криптографии - при достаточной длине ключа подделать подпись будет невозможно.
Если вы о декомпиляции - её автоматизация для машинного кода весьма затруднительна. Я не имею ввиду дизассемблирование - оно возможно, т.к. процессор сам как-то должен исполнять код. Попытки автоматической декомпиляции предпринимаются (http://www.hex-rays.com/), но в основном они сводятся к анализу всех возможных вариантов порождаемого компилятором кода (что становится вовсе нетривиальной задачей, т.к. как я понял преобразование в машинный код будет осуществляться на стороне metaquotes). Если же привязать работу кодогенератора к фазе луны (т.е. чтобы конструкции компилировались по-разному) - автоматизация декомпиляции станет вообще нереальной!
Действительно, я имел ввиду дизассемблирование. Я, как это часто бывает со всеми, судил по своим возможностям. Для меня - это равносильно декомпиляции поскольку восстановить алгоритм из ассемблерного текста в большинстве случаев для меня раз плюнуть. Конечно, этот процесс можно сильно усложнить, взяв на вооружнение алгоритмы полиморфных вирусов, но в конечном счете, раз существуют антивирусы, значит и этот прием не дает полной гарантии.
Действительно, я имел ввиду дизассемблирование. Я, как это часто бывает со всеми, судил по своим возможностям. Для меня - это равносильно декомпиляции поскольку восстановить алгоритм из ассемблерного текста в большинстве случаев для меня раз плюнуть. Конечно, этот процесс можно сильно усложнить, взяв на вооружнение алгоритмы полиморфных вирусов, но в конечном счете, раз существуют антивирусы, значит и этот прием не дает полной гарантии.
Дизассемблирование больших файлов (пусть даже при помощи ida) и ручная реконструкция алгоритма требуют много времени и сил. Сомнительно, что народ будет часто практиковать такой подход. Но судя по всему - это единственный метод, который будет в дальнейшем возможен для файлов с машинным кодом, если разработчикам удастся каким-либо образом усложнить сгенерированный машинный код.
Антивирусы редко используют какие-то специальные алгоритмы. В основном цепляются за особенности файлов и последовательностей инструкций - сталкивался с тем, что антивирус ругался на вычисление числа пи через сумму ряда (тренировался использовать fpu). Декомпиляция - это принципиально иная задача. Если выполнять труднообратимые мутации кода при кодогенерации - декомпиляция по характерным вариантам кода будет невозможна в принципе (нужно будет эмулировать/трассировать код и смотреть что происходит на "высоком уровне" - откуда прочитали, что и куда записали, что и с какими параметрами вызвали... антивирусы вроде бы используют похожий подход, но следят лишь за последовательностями вызовов различных системных функций).
По поводу труднообратимых мутаций подкину, пожалуй, немножко ссылок на статьи (надеюсь, администрация и читатели не будут против ссылок на такое):
Как раз для замусоривания/обфускации кода в MQL5 можно указывать для каждой функции специальный модификатор:
Пока его назвали trash, но скорее всего изменим на protect.
В результате будет производиться глубокое замусоривание кода и замедление работы указанной функции.
Кроме того, компилятор MQL5 языка использует массу оптимизаций, что кардинально уменьшает возможность обратной декомпиляции.
Как раз для замусоривания/обфускации кода в MQL5 можно указывать для каждой функции специальный модификатор:
Это хорошо :) Можно ли будет настраивать процент мусорного кода? Будет ли выполняться встраивание функций по месту вызова?
Это хорошо :) Можно ли будет настраивать процент мусорного кода? Будет ли выполняться встраивание функций по месту вызова?
Каждый раз мусориться будет по новому. Настравать процент нельзя - все решает сам компилятор.
Автоматический инлайн функций давно уже работает - решения принимает сам компилятор в зависимости от объема и сложности функции. То есть, большие функции не инлайнятся.
Эх... как мне легко живётся...
Ни взламывать желания ну никакого, ни продавать в обозримом будущем ничего не собираюсь.
Вот уж проблемы то у людей...
:)))