Вопрос тем кто юзаtn encorer-Ы. =)

[Buger]

Вопрос тем кто юзает encoder-Ы. =)

Подскажите плиз - какой лучше юзать?
Чем плохи бесплатные енкодеры (а ля http://www.rssoftlab.com/phpenc.php)
Что делает фри версия зендосвкого енкодера (всмысле вставляет ли копирайты или еще чего-нить)?

 

[su1d]

Чем плохи бесплатные енкодеры

тем, что они енкодят, но не защищают.

нужно устанавливать их модуль, который декриптует скрипт, и только потом уже направит его движку Зенд.

РНР -- продукт с открытым исходным кодом.
так что мне мешает вставить лишнюю строчку с zend_printf() в исходники, пересобрать мою версию РНР и вытащить полностью весь закриптованный исходник в тот момент, когда экстеншн будет передавать его движку в чистом виде?

Что делает фри версия зендосвкого енкодера

закриптованные скрипты работают только три дня с момента криптования.

 

[Buger]

А что тогда мешает так же перехватить код зендовского энкодера?
Каким образом он защищает? И делают ли это други платные енкодеры?

 

[si]

он компилить в байт-код, который тоже можно раскодировать, но сложнее.

 

[su1d]

...а помимо простой компиляции, Зенд-Енкодер проводит ещё кучу оптимизаций, практически необратимо изменяя исходник.
поэтому в чистом виде выдрать оттуда исходник практически невозможно.

 

[Sirius]

Я так и не понял вопроса, тебе для чего? Для того чтобы не перехватили, или для того, чтобы хостинг поддерживал?

По первому - я ещё пока не видал, чтобы хоть какой то из энкодеров "имели" Ну я использую Zend и Ioncube

Популярнее Zend, но Ioncube иногда легче без вмешательства хостинга установить (при safe_mode=off)

По моим клиентам знаю, что если кто когда и глючил, то это Zend loader (входящий в состав Zend Optimizer и отвечающий за загрузку закодированных файлов) то есть файлы закодированные zend encoder. Точно проблемы не знаю - хостинг ведь не мой был...

Ioncube ещё ни разу не подвёл!

 

[Buger]

Ага! =)
Псиб, Sirius.

Еще вопрос - я, как русский человек - истинный любитель халявы, хотел бы уточнить пару моментов по поводу ionCube.

Там lifetime лицензия стоит - 199 уёв, так?
Эта лицензия на руки идёт в каком виде? Ключ-файл? Другая (полная) версия продукта? Серил намбер? Или еще как?
Есть ли воможность как-нить заиметь оною лицензию не за 199 брать а поменьше? (не в смысле еще одну купить за 99, а так - у кого-нить, у кого есть уже приобресть)

-~{}~ 02.12.04 18:30:

Да, еще... =)

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

<?
info();
?>

Стало:

<?php
gzinflate(base64_decode(
's7ezseflysxLy9fQtOblsgdyAQ=='
));
?>

 

[SiMM]

Автор оригинала: Buger
Если уж не сильно заморачиваться впринципе можно и так сделать.
Было:
<? info(); ?>
Стало:
<?php gzinflate(base64_decode('s7ezseflysxLy9fQtOblsgdyAQ=='));?>

Ну и что же мне помешает сделать

<?php echo htmlspecialchars(gzinflate(base64_decode('s7ezseflysxLy9fQtOblsgdyAQ==')));?>

?

 

[Buger]

Всю малину обосрал! =)

Да понятно, что можно позыреть всё шо хошь - что-то легче, что-то сложнее...

PS: Вопрос про ionCube остаётся открытым! =)

 

[valyala]

А вы знаете, что даже самый навороченный PHP-энкодер, в т.ч. и ZendEncoder, вынужден сохранять начальные имена переменных, классов, констант, функций и т.п. вещей благодаря такой "фиче" ПХП, как eval и ее "коллегам" - variable variables, variable functions, preg_replace() с модификатором e, call_user_*(), require*, include* и т.п.? Например, значение переменной - строка с именем функции или переменной. Тогда мы можем обратиться к ним вот так: ${$var_name} или, если имеем дело с функцией, ${$func_name}();

Поэтому, теоретически, можно восстановить любой "заэнкодженный" исходник с точностью до имен переменных, функций, констант и классов. Единственное, что безвозвратно теряется - это комментарии и форматирование.
Другой вопрос: кто возьмется или согласится потратить время и деньги на создание удобного инструмента, восстанавливающего исходники из "заэнкодженных" файлов? Тут необходимо вспомнить одно из правил криптграфии: защита чего-либо считается надежной, если средства, затраченные на взлом этой защиты, превышают стоимость этого "чего-либо". Так что если вам необходимо "заэнкодить" что-нибудь наподобие hello world application, то даже предложенную Buger'ом "защиту" можно считать надежной

Можно, конечно, игнорировать eval и ее "родственников". Тогда исходные имена переменных, констант, функций и классов сохранять не нужно. Но в этом случае теряется "100% PHP-compatibility".

...а помимо простой компиляции, Зенд-Енкодер проводит ещё кучу оптимизаций, практически необратимо изменяя исходник.

Я склоняюсь ко мнению, что эта "оптимизация" в большинстве случаев ничего толком не меняет. Вообще, оптимизация высокоуровневых языков программирования - чрезвычайно сложная задача, имеющая кучу подводных камней. В основном, оптимизации поддаются наиболее низкоуровневые конструкции языка. Например, арифметические, битовые и логические опрерации.
ПХП редко используется для решения сложных математических задач. Среднестатистическая программа на ПХП представляет из себя последовательность вызовов встроенных в пхп высокоуровневых функций, которая (последовательность вызовов, а не сами функции) совершенно не поддается оптимизации.
Отсюда я делаю вывод, что оптимизация с точки зрения "энкодинга" будет целесообразна только в редких случаях, когда "энкодится" какой-нибудь проект, тесно связанный с математикой.

 

[neko]

А вы знаете, что даже самый навороченный PHP-энкодер, в т.ч. и ZendEncoder, вынужден сохранять начальные имена переменных, классов, констант, функций и т.п.

насчет *должен* это заблуждение
как правило в таких случаях используются хеш-таблицы
и соответственно чтобы найти переменную по имени (ключу) не обязательно в таблице сам ключ хранить
впрочем это зависит от реализации, он может хранится как "данные-сателлиты" для структуры или может не хранится вовсе
факт в том, что какой-то неизбежной необходимости их хранить -- нет

как конкретно реализована данная вещь в php мне неизвестно, но что-то подсказывает, что велосипеда они не изобретали

-~{}~ 04.12.04 00:19:

ага я 5 минут еще подумал и понял что таки да, хранит
иначе бы не работали всякие get_defined_functions

а мог бы этого и не делать

 

[valyala]

насчет *должен* это заблуждение
как правило в таких случаях используются хеш-таблицы
и соответственно чтобы найти переменную по имени (ключу) не обязательно в таблице сам ключ хранить

Да, можно использовать хеш-таблицы. Но с одной оговоркой - должны быть исключены коллизии, т.е. преобразование, используемое в хэш-функции, должно быть взаимно-однозначным (хэш(А) == хэш(Б) только, если А == Б). Отсюда следует, что энтропия генерируемого хэша должна быть по крайней мере не меньше энтропии имен функций, констант, классов и переменных. В случае с ПХП, где длина этих имен не ограничена, длина генерируемого хэша должна быть тоже неограниченной, что технически невыполнимо.

как конкретно реализована данная вещь в php мне неизвестно, но что-то подсказывает, что велосипеда они не изобретали

Давай посмотрим в исходники ПХП. Заглянем в файл /Zend/zend_language_scanner.l - спецификацию лексики PHP. Очевидно, что при нахождении очередного токена T_STRING или T_VARIABLE, которые соответствуют именам переменных, функций, констант и классов, его лексема (строковое значение токена) копируется в структуру типа zval (zval.value.str), определение которой можно найти в файле /Zend/zend.h.
Эта структура, в свою очередь, помещается в структуру типа znode (znode.u.constant) при вызове функции zendlex (файл /Zend/zend_compile.c), осуществляемом во время синтаксического анализа входного потока. Определение структуры znode находится в файле /Zend/zend_compile.h.
Затем структура znode попадает в структуру zend_op в качестве одного из операндов op1 или op2. Объект типа zend_op представляет из себя элементарную операцию, которую может выполнить интерпретатор PHP.
Массив из zend_op'ов, в свою очередь, помещается в структуру zend_op_array (zend_op_array.opcodes), которая является "скомпилированным" представлением исходника (функции).
Отсюда следует, что PHP не изменяет имена, встретившиеся в исходном коде.

p.s. При анализе исходников я обнаружил интересную вещь: оказывается, ПХП5 сохраняет даже некоторые комментарии. А именно, T_DOC_COMMENT, имеющие вид #/\*\*[ \n\r\t]+*+?*/#, и идущие непосредственно перед определением функций и классов. Например,

/**
Этот комментарий можно восстановить из "скомпилированного" массива opcode'ов.
*/
function f() {}

// а все это для того, чтобы работала вот такая "фича" ПХП5:
$a = new ReflectionFunction('f');
echo $a->getDocComment();

Также обнаружил еще одну интересную "фичу" в PHP5, про которую я раньше не знал. В документации на php.net вроде тоже ничего про нее не написано:

class Class1
{
    public $s = 'hello';
}

/**
    обратите внимание на список параметров, передавемых в функцию
*/
function f(Class1 $a)
{
    echo $a->s;
}

f(new Class1); // нормально
f('test'); // ошибка

-~{}~ 09.12.04 01:40:

В документации на php.net вроде тоже ничего про нее не написано

Хотя нет, написано. Просто не там искал. http://www.php.net/manual/en/language.oop5.typehinting.php - вот тут все подробно описано

 

[neko]

valyala

В случае с ПХП, где длина этих имен не ограничена, длина генерируемого хэша должна быть тоже неограниченной, что технически невыполнимо.

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

однако это теория которая к php отношения не имеет

Отсюда следует, что PHP не изменяет имена, встретившиеся в исходном коде.

да именно

собственно возвращаясь к вопросу с энкодером: он этого тоже не делает
вместо этого он шифрует сами опкоды, сохраняя в неизменном виде все имена и константы

кстати он и правда слегка пытается соптимизировать код

 

[Sirius]

Buger

Ioncube продаёт энкодер по лицензиям на сетевуху!!!

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

Вообщем генеришь ихней прогой инфу для них и высылаешь им (туда записыватся сетевуха, и ещё ОС и даже SP номер - а может и ещё что-то ). Они тебе на основе этой инфы и высылают ключевой файл.

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

Вообщем немного сложно. Но есть и преимущества. Лицензия временем не ограничена, в отличие от зенда - который в малом бизнес пакете энкодер покупается лишь на 1 год!!! Через год нужно обновлять лицензию - а безлимитная лицензия на энкодер у зенда стоит под 3 куска.

 

[neko]

кстати подумалось еще

тем, что они енкодят, но не защищают.

нужно устанавливать их модуль, который декриптует скрипт, и только потом уже направит его движку Зенд.

для оптимайзера надо тоже устанавливать модуль
нет вообще никаких препятствий для написания аналогичного

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

 

[valyala]

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

Мы отклоняемся от цели Таблицы с подтаблицами тут совершенно ни при чем. Задача - не хранить имена переменных, функций, констант, классов (далее просто имена) в "скомпилированном" коде. Если бы не eval-подобные "фичи", задача была бы просто решаема. Например, можно заменять каждое вновь встретившееся имя на что-нибудь вроде "var_n", где n - порядковый номер этого имени. После окончания компиляции таблица соответствия "начальное имя" => "var_n" больше не нужна. Но в случае с eval эта таблица может понадобиться во время исполнения кода, чтобы корректно преобразовать встретившиеся имена в "var_n". Вот тут-то и нужны односторонние функции без коллизий, которые не используются в PHP и его "энкодерах".

И существуют соответственно хеш-функции которые могут произвести хеш произвольной длинны/точности

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

собственно возвращаясь к вопросу с энкодером: он этого тоже не делает
вместо этого он шифрует сами опкоды, сохраняя в неизменном виде все имена и константы

Ок. Значит, шифрует. Я не вижу никакой разницы между таким "шифрованием" и "защитой", предложенной Buger'ом. Ведь перед исполнением код все равно расшифровывается. Что нам мешает перехватить его на этом этапе?

кстати он и правда слегка пытается соптимизировать код

Может быть. Но, т.к. исходники zend encoder'а не распространяются, ничего конкретного насчет его "оптимизации" сказать нельзя.

А теперь - просто мысли насчет того, почему программисты не распространяют свои разработки в исходных кодах, а пользуются всякими "энкодерами" и компиляторами. Я вижу несколько причин, перечисленных ниже в порядке убывания распространенности:

1) Если защищаемый продукт платный, то "энкодер" используется в основном для того, чтобы покупатель не смог обойти платную регистрацию/активацию.
Если бы продукт распространялся в исходных кодах, то любой специалист средней квалификации смог бы найти код, отвечающий за регистрацию, и отключить его. А так у покупателя есть три пути:
- заплатить продавцу за регистрацию,
- заплатить профессиональному специалисту, который способен взломать даже "закодированный" продукт,
- подождать, пока кто-нибудь не создаст "крэк" для данного продукта, чтобы затем воспользоваться им.
По стоимости обычно самый выгодный - третий путь. Но он возможен только в том случае, если продукт является mainstream, т.е. пользуется популярностью в широких кругах. Если это не так (например, продукт создается по заказу), то обычно покупатель выбирает первый путь, т.к. он легален и менее затратен по сравнению со вторым.
Второй путь обычно выбирается в том случае, если стоимость лицензии превышает стоимость услуг профессионального "крэкера".

2) Если в продукт встроены spyware, backdoor, трояны и прочие "полезные" вещи. Зачем лишний раз тревожить покупателей? Встречается довольно часто.

3) Если в исходниках незаконно используются сторонние (патентованные) разработки, про которые не должны знать владельцы патентов и разработок. Это банальное воровство интеллектуальной собственности, которое тоже встречается довольно часто.

4) Если в исходниках встречаются "ноу-хау" разработчика, открытая публикация которых нежелательна. Встречается весьма редко.

5) И, наконец, если разработчик отказывается публиковать исходные коды по различным причинам, не упомянутым выше. Например, из религиозных соображений. Или стесняется публичного обсуждения его программистских способностей и "правильности" его кода.