Защита продукта на PHP

Хотелось бы здесь обсудить возможные защиты движков написанных на PHP. Вся проблема состоит в "пиратах". Они нагло воруют веб-разработки беспрепятственно декодируя Zend и прочие системы защиты. В том числе и обусификаторы. Есть ли какие либо варианты защитить свою разработку не декодируемые на данный момент?

P.S. IonCube предлагать бессмысленно, т.к. он не очень распространен у российских хостеров.

Так не пользуйтесь российскими хостерами

Я изготовитель продукта, а не пользователь
Мне нужно что бы пользователи были довольны, а продукт достоин их внимания.
В тоже время я не хочу что бы в течении недели вышла нулл версия. Что делать?

Цитата ("The_KING"):

беспрепятственно декодируя Zend

Предлагаю вам работу по декодированию скрипта.

ИМХО проблема надуманная.

AlekartRu, тема по кодированию скриптов, а не декодированию. Есть ли алгоритмы позволяющие закодировать скрипт без возможного декодирования? Точнее есть ли методы кодирования не декодируемые на данный момент? Или максимально утяжеляющие работу по декодированию.
raznomir, И что в ней надуманного? Я хочу продавать свою разработку, а не делиться ей с кем попало.

Цитата ("The_KING"):

AlekartRu, тема по кодированию скриптов, а не декодированию. Есть ли алгоритмы позволяющие закодировать скрипт без возможного декодирования? Точнее есть ли методы кодирования не декодируемые на данный момент? Или максимально утяжеляющие работу по декодированию.

Zend. Если вы считаете, что его легко декодировать - см. выше - я предлагаю вам работу по декодированию. Хостеров с зендом - российских - много. Проблема ваша действительно надумана.

Мне не нужна работа по декодированию. У меня в планах реализовывать свой скрипт, а не заниматься декодированием чужих. Ачат тебе в помощь, там тебе бесплатно помогут Эта тема уже заезжена.
Мне нужны варианты защиты. Для защиты ПО.

Цитата ("The_KING"):

Мне нужны варианты защиты. Для защиты ПО.

Вопрос теоретически интересный, но боюсь, ответ на него, в общем случае, отрицательный. Разве что Вы сделаете свой процессор со своим набором команд и никому его не будете давать. Зная систему команд процессора, декодируют и двоичный код и все защиты с него снимают и все лейблы переклеивают. Похоже, что единственный пригодный для Вас вариант защиты - это не продавать Ваш продукт, т.е. не передавать продукт покупателю. Установите Ваш продукт на Вашем же сервере и предоставляйте покупателю услуги по использованию Вашего продукта, так же как, например, Google предоставляет услуги текстового процессора или услуги по использованию средств коллективной разработки. Эта концепция называется SaaS (Software as a Service), словечко нынче модное, всяких статеек по ней более чем достаточно.

Да кстати, интересный метод "защиты" в свое время использовал Oracle для своего продукта под SUN Solaris: CD с продуктом передавался покупателю бесплатно, копирование продукта не возбранялось (во всяком случае наши продавцы поставили его на наших серверах без каких-либо ограничений), но вот комплект документации (на прекрасной мелованной бумаге) уже продавался за деньги и деньги весьма существенные. Из разговора с продавцами я понял так, что без документации работать с ихней системой не получится, а покупая документацию пользователь автоматически покупает и лицензию на продукт, а воровать программы - ну пусть воруют если не лень .

SourceGuardian

Illarion_SA, спасибо большое за ответы. Почерпнул 2 интересных момента:
1. Размещение продуктов на воем хостинге (у меня уже имеется платформа для его создания)
2. Использование документации как лецензии - интересный вариант, но к cms системам он врядли применим. Хотя поизвращаться можно

Lisio, Спасибо за название прожки. Сейчас посмотрю в гугле что к чему.

Судя по всему для работы SourceGuardian необходимо php расширение. Я не думаю что оно установлено на наших хостингах. Хотя я может что-то не до понял. Чуть позже прочту повнимательнее. Хотя характерным плюсом можно выделить стоимость продукта. $200 это вменяемая цена.
Есть еще варианты?

P.S. Да, порывшись поглубже я понял что для него нужны лоадеры. Не факт что хотер будет их устанавливать на свой сервер ради одного клиента. И собственно хостингов я не знаю с уже установленным лоадером для SourceGuardian......

Цитата ("The_KING"):

Хотелось бы здесь обсудить возможные защиты движков написанных на PHP. Вся проблема состоит в "пиратах". Они нагло воруют веб-разработки беспрепятственно декодируя Zend и прочие системы защиты. В том числе и обусификаторы. Есть ли какие либо варианты защитить свою разработку не декодируемые на данный момент?

таких технологий нет и не будет никогда.

IonCube , как говориться, попробуй раскодируй я пробовал последняя тройка вроде уних бесполезняк

Цитата ("The_KING"):

Не факт что хостер будет их устанавливать на свой сервер ради одного клиента.

Тут выбор прост. Если ваш хостер - школота с реселлерским аккаунтом, то да. Если уважаете себя - то проблем с хостингом не будет.

Цитата ("hak2008"):

IonCube , как говориться, попробуй раскодируй я пробовал последняя тройка вроде уних бесполезняк

если бы он не раскодировался - то php бы не смог его выполнять. нужно лезть либо в opcode для восстановления исходника, либо если нужно дописать - задействовать рефлексию + get_defined_*
взломщика ioncube сча нет в паблике только потому что он не массовый продукт как зенд енкодер, да и энкодера нет в паблике...

Извращение высшей степени.
Для чего вообще придумывались все эти скриптовые языки(Perl, php и иже с ними)? Основным плюсом этих языков является то, что программа представляет из себя исходный код, написанный в удобоваримом виде. Это удобно для быстрого внесения различных изменений "на лету", без необходимости перекомпилировать всю программу.
Что пытаетесь сделать вы - по сути единственное солидное преимущество php перед другими языками выкинуть нафик.
Если нужна защита от взломщиков - надо пользоваться компилируемыми языками, в таком случае уже можно продумывать различные системы защиты информации.
К слову, если в вашей cms действительно есть что-то хорошее(удобный интерфейс, удачная архитектура, еще что-нибудь) можем предложить на различных условиях перевести на язык D. И с защитой все будет намного проще, и запускаться будет на всех хостингах - даже апач не обязателен..=)

Цитата ("dervinar"):

Если нужна защита от взломщиков - надо пользоваться компилируемыми языками, в таком случае уже можно продумывать различные системы защиты информации.

Пример номер раз: Взломали ftp, нашли конфиг к мускулю, он под sourceguardian, пароль не получили, базу не сломали. Максимум - угробили скрипты.
Пример номер два: Заказчик не оплатил работу. По таймауту сайт отключается, исходников нет.
Пример номер три: Вы создали свою CMS и хотите ее продавать, закодировав базовую часть движка, оставив открытыми только модули и второстепенные функции. Много вы продадите копий такого двига на языке D?

Извращение высшей степени - создавать сайты на языках, которые не предназначены для создания сайтов. А защита скриптов от дурака никогда не бывает лишней.

Цитата ("dervinar"):

Основным плюсом этих языков является то, что программа представляет из себя исходный код, написанный в удобоваримом виде.

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

Цитата ("e1it3"):

таких технологий нет и не будет никогда.

Может наконец-то будем повнимательнее? Я спрашивал про данный момент. И такие технологии существуют!
Цитата ("hak2008"):

IonCube , как говориться, попробуй раскодируй

Он уже декодируется. Причем в хацкерских кулуарах готовится дешифратор. Об этом даже написано на официальном форуме иона.
Цитата ("Lisio"):

Если ваш хостер

Причем тут мой хостер? У меня свой сервер. Я за пользователей переживаю. Не более.
Цитата ("Lisio"):

Пример номер раз: Взломали ftp, нашли конфиг к мускулю, он под sourceguardian, пароль не получили, базу не сломали. Максимум - угробили скрипты.

И как Вы себе это представляете? Как пользователь будет цеплять бд к движку? Конфигурационный файл создается во время установки. Он не может быть закодирован если продукт будет иметь массовый характер.
Lisio, мне хотелось бы Вас поблагодарить - Вы единственный кто предложил действительно что-то. Но у меня возникает вопрос и соответственно сомнения по поводу декодирования sourceguardian. Сам я его не тестировал на прошибаемость, но все же. Если взломщик вскроет чей нибудь ftp аккаунт или просто купит продукт он ведь сможет его декодировать. По крайней мере я так думаю. Завтра буду тестировать. Выложу сюда результаты тестирования и если получится взломать описание как ломал защиту.