Как защитить продукт PHP с помощью btcompiler и лицензионных ключей?

Question

Я занимаюсь разработкой приложения на PHP, которое планирую продавать и распространять. Я хочу контролировать, кто имеет доступ к основным функциям и установке приложений через какой-то звонок на мой сервер, который проверял бы, находится ли место установки скрипта (example.com) в базе данных, может даже проверять лицензионный ключ какой-то.

1. У кого-нибудь есть общие рекомендации по защите распределенной PHP-программы? Я не ожидаю полной безопасности, но я хотел бы выпустить сценарий с пробной версией и хотел бы отговорить обычного человека от изменения кода, чтобы попытаться обойти покупку сценария.

2. Я имел в виду две идеи - иметь скрипт «phone home» с адресом сервера скриптов и проверять этот адрес по базе данных (достаточно просто), или делать это в дополнение к генерации лицензионного ключа. и жесткое кодирование этого ключа в сценарии, либо в файле, либо в запросах на установку базы данных.

У меня вопрос: если я выберу последний путь (жесткое программирование), какой самый эффективный способ жестко закодировать ключ в сценарий во время выполнения и упаковать его в уникальный zip-файл?

3. Я бы использовал bcompiler , чтобы попытаться запутать функции аутентификации, использованные выше. Я знаю, что вам нужна поддержка bcompiler, скомпилированного в PHP, для записи байт-кода, но есть ли какие-то особые требования для запуска скомпилированного байт-кода? Мое приложение будет работать на разных компьютерах, но с общим условием, что все они будут работать под управлением PHP5, поэтому код должен быть в состоянии работать в условиях ограниченного хостинга (где, например, они не могут загружать внешние третичные библиотеки PHP). ).

Answer 1

Просмотр этих вопросов / ответов может помочь вам, по крайней мере, немного:

• Как предотвратить перепродажу исходного кода PHP?
• Лучшее решение для защиты кода PHP без шифрования
• Как можно защитить веб-приложение, продаваемое на основе лицензии, от пиратства?
• Кодовый обфускатор для php?

Он не будет полностью отвечать на ваши вопросы, но все же может оказаться полезным: -)

Тем не менее, моя главная мысль будет заключаться в том, что ваша проблема - это больше правовая проблема, чем что-либо еще: если ваши клиенты хотят вас ограбить, они, вероятно, не являются клиентами, которых вы должны пытаться удержать ... Вероятно, самое важное, что вы должны сделать иметь надежный контракт со своими клиентами, который определяет, что они могут, а что не могут делать; всегда будут люди, пытающиеся обойти любую «защиту», которую вы можете установить - и они, скорее всего, все равно добьются успеха ...

Если вы хотите заняться таким бизнесом, вам нужно получить отличное лицензионное соглашение; это скорее юридический, чем технический бизнес, и вам наверняка понадобится помощь кого-то, чья работа связана с юридическими вопросами.
Тем не менее, прохождение лицензионного соглашения с приложениями / веб-сайтами, которые вы используете, может дать вам несколько советов.

Как примечание: об идее «позвони домой»: убедитесь, что, если ваш «домашний» веб-сайт / приложение не работает (это произойдет, однажды или другой) , оно не обрушит все сайты, на которых было развернуто ваше приложение - я уверен, что вашим клиентам это не понравится ^^

Кроме того: убедитесь, что то, что ваше программное обеспечение время от времени «звонит домой», четко указано в EULA / документации: если ваши клиенты сами узнают, что ваше приложение выполняет сетевые запросы, на которые они не согласились, оно будет плохо для вашего пиара.

И еще: я видел (несколько раз) приложений, развернутых на серверах, настроенных таким образом, что они не могли выполнять запросы к внешней сети компании (они говорят «причины безопасности» или что-то в этом роде) вот так) - я полагаю, что в такой ситуации мало что можно сделать ...
Другой подход заключается в том, чтобы не распространять приложение, а предоставлять услугу: не продавать само приложение, а размещать его и продавать услуги - это то, что многие компании делают (например: google, gmail или google docs; но есть много других примеров) , и, если сервис отличный, он может хорошо сработать.

Я должен добавить, что это дает вам больше возможностей для обновлений, более быстрого решения проблем, для бездействия или просто для добавления новых функций ... И вы можете контролировать, кто может использовать приложение; -)

Самая большая проблема этой идеи заключается в том, что ваше приложение не должно знать (почти) простоев: вам нужно найти отличный хостинг, создавать резервные копии, реагировать, быстро решать проблемы, ... Это тоже нелегкая работа на самом деле!

Answer 2

Почему вы не предлагаете хостинговое решение? это то, что сейчас предлагают большинство стартапов. Это также означает, что вы можете избавиться от апгрейдов и т. Д.