Тезисы моего планируемого доклада
ЗАЩИТА ТОРГОВЫХ ПРОГРАММ ПЛАТФОРМЫ МТ4 С ПОМОЩЬЮ ПРОГРАММНЫХ И АППАРАТНЫХ КЛЮЧЕЙ HASP SRM
Программы для торговли на рынке Forex с использованием платформы MT4 разрабатываются на языке программирования MQL и выполняются после компиляции, как программы формата ex4. Так как ex4 содержит только исполняемый код без исходного кода программы, то, по замыслам создателей, этого достаточно для того, чтобы нельзя было вносить изменения в работу скомпилированной программы. В том числе и изменения фрагментов кода отвечающих за защиту программы от несанкционированного использования, например, привязка программы к конкретному номеру счета или к дилинговому центру, предоставляющему услуги, возможность работать только с демосчетами (используется функция проверки IsDemo) и т.д. Практика показала, что создание декомпиляторов выполняющих обратное преобразование файлов из формата ex4 в mq4 возможно. Были созданы, в том числе, и коммерчески распространяемые декомпиляторы (например, EX4-TO-MQ4 decompiler V4.0.427) позволяющие желающим получать функционально идентичные исходному тексту тексты программ на языке MQL. (имена переменных в результате декомпиляции могут не совпадать с оригинальными). Фактически сложилась ситуация позволяющая любому с минимальными усилиями получить исходный текст программы, что совершенно не допустимо для коммерческих программ, стоимость которых в среднем составляет $150-$300. В качестве меры противодействия многие разработчики специализированного программного обеспечения (ПО) применяют решение, основанное на переносе критически важного для реализации успешной торговли функционала в динамически загружаемую dll библиотеку, к функциям которой выполняется обращение из исполняемого файла ex4. Одной из поддерживаемых функций dll библиотеки может быть функция проверки кода регистрации уникального для каждого пользовательского счета. Однако использование декомпиляторов dll библиотек и средств анализа динамически исполняемого программного кода (например, совместное использование IDA v6.1 и HexRays v1.5) позволяет получить исходный программный код dll библиотеки. Восстановленный исходный код более сложен для анализа, но, фактически, это проблему не решает, так как встает вопрос о защите уже dll составляющей ПО от несанкционированного использования. Для защиты dll предлагается использовать аппаратные устройства HASP HL, подключаемые к USB порту компьютера или программный аналог — ключ HASP SL. Созданный dll файл обрабатывается утилитой HASP SRM Envelope шифрующей библиотеку dll с использованием алгоритма AES, после чего зашифрованный код размещается в защищенной оболочке-коконе, которая вызывается при обращении к dll файлу. Оболочка проверяет наличие программного SL или аппаратного ключа HASP HL . Если ключ присутствует, а записанная в ключ лицензия действующая (например, использование ключа HASP HL Time с таймеров реального времени встроенном в ключ, позволяет реализовывать схемы продаж ПО на основе схем лизинга или аренды), то реализуется расшифровка загруженного в оперативную память dll кода и его выполнение. Стоимость аппаратных ключей HASP HL зависит от типа модели и условий закупки устройств (например, 788 руб. HASP HL Pro, HASP HL Time 1182 руб.), но вполне приемлема в общей сумме накладных расходов на производство дорогостоящего ПО для торговли на Forex, особенно для программ стоимостью выше $350. Использование программного ключа HASP SL позволяет минимизировать расходы на защиту для более дешевого ПО ($50-$100), так как стоимость лицензии для работы с ключом порядка 220 руб. Сравнение предлагаемой схемы использования аппаратной защиты показывает, что ключи HASP HL обеспечивают защиту не хуже, чем их аппаратные аналоги от конкурирующих фирм (например, ключи серии GUARDANT), но процесс установки и использования программы с защитой более удобен для конечного пользователя ПО. Защита на основе HASP SL показала хорошие результаты в сравнении с программными средствам защиты от других разработчиков (например, Enigma Protector 3.80). Предлагаемая схема защиты на ключах HASP HL и HASP SL успешно реализована в коммерческих торговых роботах Crisis v 1.2 (forex-crisis.com), Gladiator и др.
Текущие новости и интересную информацию стараюсь оперативно публиковать в своем Блоге. Например, информацию о этой конференции я получил только вчера вечером, а сейчас она доступна тут для всех желающих, кто хочет выступить с докладами. Полагаю, что практически всем, кто серьезно занимается наукой и образованием стоит создать свой собственный хотя бы и небольшой сайт (блог) в сети Интернет. Всем не имеющим сайта, но желающим его создать, предлагаю полезную информацию по теме где заказать сайт
Такой брейкпоинт сработает (обычно не в первый раз, а например во второй) прямо перед переходом на OEP. На установке такого брейкпоинта основана распаковка большинства пакеров и протекторов. Резонный вопрос «А почему именно на esp-6? Откуда это взяли, и почему он сработает перед переходом на OEP?». Будет сложно, но я попытаюсь объяснить. Значит для нахождения OEP используем тот факт, что при старте программы в Windows, указатель на верхушку стека (регистр esp) практически всегда один и тот же (имеет одно и то же значение). Это не обязательно, но это стандарт. мы его и используем для нахождения OEP. При запуске программы в общем случае esp равен этому стандартному значению. Так как упаковщик (envelope) во время своей работы следит за стеком (т.е. сколько поместил в стек, столько потом и достал из стека), то, перед переходом на OEP, esp должен быть опять равен этому «стандартному значению». Практически во всех упаковщиках, когда они восстанавливают стек перед переходом на OEP, считывается значение в стеке по адресу esp-4 (имеется ввиду что esp = «стандартному значению»). (В нашем случае OEP удаётся поймать при esp-6). Следующий элемент стека находится уже по адресу esp, и упаковщик его трогать не должен, т.к. не он ложил этот элемент в стек. Т.е. используя тот факт, что последним будет считываться значение по адресу esp-4, можно поставить брейкпоинт на тот момент, когда это будет происходить (bpm esp-4 в SoftIce), и, в один из моментов срабатывания такого брейкпоинта (он может сработать несколько раз) мы окажемся перед переходом на OEP.
Построить защиту программы с помощью Sentinel HASP Envelope действительно просто. Процесс защиты занимает 2-3 минуты (Sentinel HASP – Быстрый старт).