PHP UnReader - Обфускатор PHP-кода

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

Наконец то в теме появились реально мыслящие люди.

Unlock и kostich ++

Вот!

А то дайте мне, я счас скриптов кучу напишу за 10 мин. итд.

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

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

Я бы заострил внимание ТС нка ускоряющей (оптимизирующей) стороне своего продукта.

Удаление комментариев и проч. конечно ускоряет работу скрипта и пи этом ещё снижает трафик (и нагрузку на сервер). Это я считаю весьма положительным моментом. Конкуренция с Зендом (даже непрямая), только на пользу - есть на кого равняться - и планка высока.

Мне нравится идея ОПТИМИЗАЦИИ. Например, при программировании я нашлёпал кучу переменных, и к каждой из них я обращаюсь только один раз. Значит на уровне обфускатора возможно провести некоторую оптимизацию. Это довольно просто - если в коде ниже - к этой переменной никто не обращается, её можно подставить вместо вводимой заново (вновь). Также некоторые конструкции вида foreach желательно заменять на for. Удобно было бы использовать первый, а при перекомпиляции программой ТС получать второе. Т.е. удобное превращать в быстрое.

Думаю нет смысла обсуждать Zend и хостинг, если закодированные Zend Guard (влючая последнюю 5ую версию c обфускатором) скрипты спокойно декодируются и выкладываются в инете. Кто из нас будет им пользоваться для защиты своих продуктов? Cоздателю PHP UnReader лучше делать упор на безопасности - это самый главный плюс. Из минусов бы отметил увеличение размера файлов и потерю скорости обработки, если уж на чтение каждой кавычки вызывается функция.

Да дезендят, но не надо писать "спокойно декодируются" если в этом вопросе не разбираетесь, а то могу подкинуть работёнку на Zend с которой спокойно не получиться.

Кроме Zend есть и другие способы, которые либо вообще не реверсят либо гораздо меньше.

Большинство комерческого ПО кодируется и продаётся. Просто надо делать такой продукт у которого нет аналогов по функциональности. Делать так, чтоб люди хотели купить именно твой продукт, а не конкурентов. И поверьте, они сразу же научаться заливать файлы по FTP в режиме BINARY и т.п.

Одним словом, не пишите говноскрипты, а достойные продукты и люди-покупатели к вам потянутся.

Да, это пример неудачный - на этом тарифном плане и PHP нет. Но, тут же на форуме нашёл пример "сложностей" распространения продукта, работающего только под Zend: /ru/forum/143915, самый последний ответ на странице.

Вот в этом и есть основная задача. Вообще, задача любого кодирования информации - сделать время взлома больше времени актуальности этой информации.

Я думаю таких примеров много. У каждого метода защиты есть свои плюсы и минусы - нужно правильно их использовать. Если скрипт имеет множество конкурентов, то ужесточение "системных требований" может напрочь лешить его пользователей.

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

К примеру, есть некоторый скрипт, необходимо сделать так, чтобы он был работоспособен только на одной машине. Для этого скрипт должен включать в себя с помощью include(...) некий код с сервера автора скрипта. В этом коде можно собрать данные о выполняющей скрипт машине и разрешить/запретить дальнейшее выполнение. Задача: сделать так, чтобы обращение к серверу автора нельзя было обойти подсунув другой сервер или статический файл.

Можно вынести часть алгоритма, но это увеличит нагрузку на сервер автора.

С помощью обфускатора можно сделать следующее: для каждой переменной создаётся некоторое количество синонимов, карта которых хранится в этом вынесеном коде. Эта карта будет уникальна для каждой обфускации т.е. "ломать" придётся отдельно каждый билд, что повышает защищённость. Таким образом, включение кода будет просто обязательно для работы скрипта.

Размер файлов особо не важен - он увеличивается не на столько, чтобы создать проблемы при закачке или хранении файлов. Скорость действительно несколько падает, но ТОЛЬКО при замене кавычек .chr(...)., и это падение также не критично - около 10%. В собо критичных участках можно отказаться от этой замены.

Тут не всё так просто. Скрипт может быть очень хорошим, но его конкурент с более мягкими "системными требованиями" получит больше шансов привлечь внимание пользователя.

значит так ему нужен был этот скрипт.

именно тут, всё просто - если человек хочет именно ваш продукт, он найдёт как и где его использовать. на принципе "а для запуска нашего скрипта не нужен Zend и всё-такое" продажи не построишь.

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

Со слов того, кто этим занимается (админ nulled.ws) - скрипты спокойно декодируются. На том сайте есть и специальный раздел заказов, где смогут бесплатно выполнить вашу работёнку, если у вас не получается.

Например? Что вообще не декодируют?