Эта тема на forum.dklab.ru


Advanced Guest: Какой Encoder выбрать или метод
Собственно вот такая проблема появилась, хочется мне защитить свой код немного, по крайней мере не отдавать его в открытом виде до выполнения второй стороной договора.
Zend раскодировали раньше на раз-два, да? Или последние версии уже нет?
Обфускация не катит, т.к. достаточно много кода суть есть "внешнее" api.
Какие ещё альтернативы есть? Из надежных?

И параллельный вопрос. Если я показываю все на своем сервере, то есть какой-то способ спрятать подключаемый php файл?
Т.е. с одной стороны он должен быть доступен для инклудинга (основное что хочу заныкать это ядро), поэтому по идее и для чтения будет открыт? Можно ли хотя бы путь качесственно спрятать? Или в общем что можно сделать:)
Iced:
Про вторую часть вопроса...
Не берусь утверждать, что это самый надёжный способ "спрятать" инклюженые файлы, но я всегда в <DOCUMENT_ROOT> храню только index.php, а все другие php'шки на уровень/два/три выше <DOCUMENT_ROOT>, чтобы не было возможности к ним добраться по http.
НО:
Не все хостинги позволяют создавать директории выше public_html/http(s)docs
Advanced Guest:
ну хттп-то тут не при чем.
речь о том, как спрятать файл который надо инклудить (так или иначе) при условии что доступы по фтп все есть, а у меня есть как бы рут доступ
это по второму пункту если
dimagolov:
речь о том, как спрятать файл который надо инклудить (так или иначе) от кого его прятать?
Advanced Guest:
> от кого его прятать?
Есть ядро скрипта. Есть сам скрипт. Скрипту надо подключить ядро, и отработать.
Заказчик принимающий работу, до полной её приемки, должен иметь 100% доступ к сайту, к скрипту, к возможности работать с базой, к возможности работать по фтп и т.д. - в общем все то, что можно делать на обычном хостинг аккаунте. Тем более ему нужно там еще vbulletin запускать и т.д.
Ядро скрипта до момента полной приемки хотелось бы максимально спрятать.
Сдаю все на своём сервере, но админы затрудняются тут чем-то помочь, бормоча "ну если может проинклудить, то может и прочитать". Мне кажется что должны быть какие-то полуобходные пути, что бы все-таки ядро как-то подпрятать.
Думал подключать автоматом (auto_prepend) положив куда-нибудь в etc/garbage/yadro, но боюсь что пути где-нибудь спаляться, хотя бы в get_included_files или просто по конфигу. В общем не знаю.

Опять же - вопрос об энкодере по любому актуален. zend вроде даже последний легко расковыривают, а обфускация не катит.
Николай Павлюк:
Если у заказчика простой фтп-аккаунт, то может просто запретить ему подниматься выше DOCUMENT_ROOT, а само ядро положить на уровень выше?
Advanced Guest:
ну во первых не простой фтп аккаунт, а полноценный хостинг аккаунт
а во вторых что толку класть ядро на уровень выше - варианта-то два получится по правам доступа
1) он не сможет его проинклудить
2) он сможет его файл_гет_контентзнуть
оба не катят
Iced:
а полноценный хостинг аккаунт
Можно поподробнее про это? Это значит, что у него вообще полный доступ к серверу или что?
Advanced Gues:
Есть сервер, у меня к нему рут, на сервере поставлен директадмин, в нем можно создавать пользовательские аккаунты, у клиента именно такой - пользовательский хостинг-аккаунт.
Iced:
echo get_include_path();
Выполни на сервере от имени своего пользователя и покажи результат...
Advanced Guest:
.:/usr/local/lib/php
Iced:
И поместить ваше ядро в /usr/local/lib/php вы не хотите?
Advanced Guest:
Iced, при всем уважении, может не надо говорить загадками?
Ну помещю я его туда, напишу в скрипте include('vasya.php');
А потом заказчик напишет readfile('/usr/local/lib/php/vasya.php'); и привет всей секретности.
Я это уже несколько постов объясняю...
Iced:
Я знаю, что можно readfile(...), потому и спросил, устраивает вас вариант /usr/local/lib/php или нет... Только и всего. И никаких загадок.
1. Всё, что может проинклюдится, доступно и на чтение;
2. Все encoder'ы построены на принципе двустороннего кодирования, а значит декодирование всегда возможно - это лишь вопрос времени;
3. Если при кодировании ещё подмешать методы замены различных названий функций, переменных и т.п., то encoder превращается в обфускатор (obfuscate - затемнять, сбивать с толку), который в свою очередь накладывает отпечаток на выдаваемые сообщения об ошибках в строке с номером и символе с номером таким, что вам самим придётся долго тупить и соображать где же эта самая ошибка всё-таки произошла. Как выход - не применять вывод ошибок, но тогда вы о них и не узнаете...

Так что вы смотрите и делайте вывод сами. Всё, что я знал, я вам рассказал. PHP - построчно исполняемый язык, в нём нету средств для "прятания" исходного кода, ибо кроме него (исходного кода) ничего не существует. И вам самим решать как вы будете водить за нос своего заказчика чтобы у него хватило или не хватило терпения докопаться до сути...
Advanced Guest:
Iced, в общем посоветовать Вы ничего не можете:(

Кстати, спасибо за подсказку по поводу вывода ошибок. Если придумаю как спрятать файл, ошибки могут его спалить. Не думал об этом.
Iced:
Могу посоветовать сменить подход к жизни и к программированию в частности :)

Может следует перестать боятся, что в ваши коды попадут в чужие руки? :) Я тоже когда-то занимался этим вопросом и пришёл к выводу, что программист программисту рознь. Есть, конечно, такие, которые выстраивают своё приложение по струнке чтобы всё было прозрачно, в методах было не больше 10-и строк... Но в основной же массе программисты на всё забивают и идут по пути наименьшего сопротивления, из чего может следовать, что разобраться в концепции и базовых принципах построения аппликации по моему методу или по чьему-то ещё может быть достаточно сложно. Особенно, если у меня целое множество различных подключаемых файлов...

Подумайте, тот, кто действительно соображает, тот разберётся и в закоженой программе. Конечно же, наиболее важные и ответственные узлы вашей программы стоило бы защитить более тщательно поэтому оберните их Zend Guard'ом, если то позволяет сервер. Ведь нам заведомо известно, что 100% защитить свои исходники нельзя, но и в открытом виде выкладывать тоже нельзя из соображений здравого смысла... Таким образом нам нужно варьировать этот самый порог разбираемости в ваших кодах настолько гибко, чтобы устремить количество случаев непонимания и отторжения вашего кода к 100%, но не навредить при этом пользователю вашего сервиса. И как крайность, когда проект очень большой, то можно почти не кодировать - разобраться постороннему очень сложно.
Advanced Guest:
> Может следует перестать боятся, что в ваши коды попадут в чужие руки? :)
Я не этого боюсь:) Исходные коды после сдачи проекта полностью отдаю вместе с документацией.
Я боюсь что заказчик "забудет" оплатить работу, к сожалению пара тревожных звоночков от коллег уже идет.

> Подумайте, тот, кто действительно соображает, тот разберётся и в закоженой программе.
Поэтому я и хочу найти вариант при котором сам инклуженный файл будет достать трудно, а не просто он будет закодирован.
dimagolov:
> Я боюсь что заказчик "забудет" оплатить работу, к сожалению пара тревожных звоночков от коллег уже идет.
тут аж 3 варианта:
1. верить заказчику и не парить себе мозги
2. деньги вперед (можно частями если все таки верим)
3. не работать со стремными заказчиками.
Advanced Guest:
dimagolov,
1) Ну есть разница между доверием и глупостью
2,3) Поздно пить боржоми:)
dimagolov:
демонстрируй не давая ftp доступа до сервака, показывай только что сайт живет и работает по спецификации.
Iced:
демонстрируй не давая ftp доступа...
Я так понял, что ftp уже есть у заказчика...
Юра Скляр:
для защиты кода от посторонних глаз мы используем eAccelerator: http://eaccelerator.net/,
который подключается как php extension.

И если у вас root аккаутнт - скомпилировать труда не составит.

Эта тема на forum.dklab.ru