Какая логика обфускации php кода под доменное имя?

Question

[Гура]

Интересует логика обфускации php кода под доменное имя.
Описываю ситуацию, есть некие php файлы имеющие сложные логические функции, которые писались на протяжении нескольких месяцев и нуждаются в качественной обфускации для избежания массового бесплатного распространения. Файлов достаточно много, все они имеют свои ключи лицензии, что то примерно такого $key = md5(md5($domain) . md5($hash)).

Где:
$domain = $_SERVER['HTTP_HOST'];
$hash = Абсолютно рандомный ключ, который будет отвечать за версию основной кодировки; (хардкод)

Собственно сам $_SERVER['HTTP_HOST'] можно подменить вначале кода. То есть все бы ничего, но это все равно можно обойти.

Подскажите, к чему можно привязаться, чтобы исключить подмену доменного имени? Также не понятна логика работы с субдоменами. Хватит ссылок на источники. Спасибо!

Comments

[Максим Федоров]

которые писались на протяжении нескольких месяцев

Самый красивый код — опен-сорс код, когда десятки и сотни людей оттачивают каждый класс/функцию кода... Ваш код насколько хорош и нужен другим? Честно! Как много программистов прочесывают чужой код и разбирают чего и как в нем? (ни одного)

[Владислав Лысков]

Не нужно хэшировать доменное имя, нужно хранить его у себя в базе, и проверять, если для этого домена куплено, то юзать можно, а если нет, отдавать что-то типа 'купи', а эту часть кода уже и абфусцировать

[Гура]

Максим Федоров, при чем тут хороший код?) Я задал вопрос не для того чтобы обсуждать код, в этот код вложено не только время, но и логика нанятых за деньги разрабов, тоже самое и касается безопасности. Уважение всем опен-сорс, к сожалению я из тех людей которые покупают чужое ПО и продают свое. Сторонников этой идеи не ищу и не собираюсь ничего доказывать.

Мне нужно понимать логику кодирования взятую из голов умных и опытных в этом деле людей.

[Гура]

Владислав Лысков, таким же образом разве нельзя подменить адрес запроса :) Та и не скажется ли это на скорости работы? Или сделать отложенную проверку?

[Владислав Лысков]

Гура, на скорости работы скажется, но тебе по факту нужно проверять 1 раз, подменить можно
ВАЖНО! На 100% ты никогда не защитишь, ты просто отсеешь тех, кто работает по принципу - накатил cms, поставил плагины, на, клиент, магазин
Остальные либо напишут сами (не знаю, что там у тебя), либо купят за большие деньги и не вздумают это распространять

Answer 1

[DevMan]

обфускация никак не спасет от попадания на варезники, любой опытный дев без особых проблем "полечит".
помочь могут энкодеры вроде ioncube. но ровно пока ваш продукт не станет популярным и востребованным.

единственный действенный способ оградить код – не отдавать его, а запилить saas.

Comments

[Гура]

Вообще я и думаю использовать ionCube, возможно неправильно выразился. Тут больше нужно понять логику привязки ключей лицензии, чтобы в тупую не потерять производительность постоянными запросами на свой сервер.

Что касается декода, продукт сам по себе кусок стареющего объекта, важны обновы. Кодировка позволит выдерживать время между обновами. Романтика, надо короче просто логику.

[DevMan]

Гура, ioncube умеет это делать сам.

Answer 2

[FanatPHP]

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

Comments

[Гура]

Выше нос, все будет хорошо ;)

Answer 3

[Александр Аксентьев]

1. Если у вас действительно супер-пупер секретный алгоритмы которые никто не знает или может повторить.
Использовать исключительно модель SaaS или производить вычисления через ваш сервер(но продукт всё равно будет стоять на сервере клиентов).

2. Если никаких алгоритмов взлома гугла/пентагона/игил/телеграма там нет.
Просто отдавать открытые исходники для работы.

3. Если вы пишите очень плохой код и вам стыдно или хороший код, но вы жадный.
Используйте SaaS.
Технологии позволяют привязать домен клиента к вам, создать ему отдельное рабочее пространство(виртуалку/сервер) и всё что только придумать можно.

http://sanasol.ws/2017/06/22/%d0%ba%d0%be%d0%b3%d0...

Comments

[Гура]

При чем тут секретные алгоритмы?) Как минимум по безопасности кода и защиты от конкурентов.

Saas - это не клиентоориентированно.

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

[Александр Аксентьев]

Гура,

Ваше решение, небезопасное и не гибкое как минимум потому, что придется кодировать каждый раз файл, жестко задавая домен.

Какое моё решение?
saas или открытые исходники, в каком из этих вариантов вы хотите что-то "жёстко" задавать?

Answer 4

[xmoonlight]

https://github.com/pk-fr/yakpro-po
(или ionCube, но там проблема в просадке производительности кода и не всегда всё гладко... у меня - куплен он)

Параметры на DNS-сервере, для каждой площадки: IP, hash-подпись, домен (или regex-маска).
На PHP - просто их читаете с DNS через обфусцированный PHP-код и если хеш для текущего сервера отличается (от того, что на DNS), то пишите, что "низя так!".

Answer 5

[GR21]

В ключе можно использовать данные: имя домена, document_root, server_ip. И не проверять его вообще на своем сервере. Как WHMCS к примеру.

Конечно, если все прикрыто ionCube.