Меню
Что нового?

Кодирование скриптов ala Zend-Encoder

Crazy

Crazy

Developer
IMHO, пользование этой штукой -- тот еще геморрой с настройкой "а вот эти переменные портить нельзя".

Добавляется еще один полный цикл тестирования. :(
 

Doomer

Guest
Автор оригинала: Crazy

Если имена изменить, то приведенный код сразу изменит свое поведение. Этого не происходит. Следовательно -- имена не изменяются.

Простая логика.

Плюс к тому можешь проверить функции для работы с метаданными -- все они сохраняют свою функциональность.

Но, как я уже говорил, тулза для расшифровки по рукам не ходит даже если и существует в природе...
Нажмите для раскрытия...
В Delphi существует механизм RTTI, когда к некоторым переменным можно обратиться по имени вроде
Сlass.GetVar('HelloWorld') := 1, но это не означает что прогу на Delphi можно дизкомпилить, просто в специальный массив сохраняются имена переменных и их адреса.
 
Crazy

Crazy

Developer
"Прогу на Delphi" нереально перевести в исходный код исключительно по причине оптимизации.

К примеру, для TP3, в котором оптимизации не было в принципе, существовал декомпилятор, формировавший на выходе полноценный паскалевский исходник. С "дурными" именами, увы -- RTTI тогда не было. :)

К чему я это говорю? К тому, что у меня нет никаких данных о наличии оптимизатора в обсуждаемом энкодере. Если он там есть -- декомпиляция становится малореальным делом. Если его там нет -- это просто проблема "Неуловимого Джо".

Опять же, когда я говорю о малореальности декомпиляции оптимизированного кода, то имею в виду не невозможность этого, а лишь крайне высокую стоимость. Если ты готов потратить $200,000 на разработку декомпилятора, то я даже могу тебе команду подогнать. За полгода напишут. :)
 

telepuzik

тинки-винки
Автор оригинала: Crazy
IMHO, пользование этой штукой -- тот еще геморрой с настройкой "а вот эти переменные портить нельзя".

Добавляется еще один полный цикл тестирования. :(
Нажмите для раскрытия...
если ты прогу написал грамотно не полагаясь на session_register и register globals - работает на ура. вчерась потестил - без изменения проги - два раза пришлось добавлять переменные в список некодируемых. после этого все работало на ура. самое приятное - что "кодирует" все скрипты в проекте.
 

telepuzik

тинки-винки
а при кодировании энкодером тебе тестирования не надо будет?

в любом случае при изменении любой части проекта тебе все равно придется тестить... :)
 
Crazy

Crazy

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

Возможно, такое бывает. Но мне не попалось.
 
Crazy

Crazy

Developer
Сравнил. В закодированном файле возвращает имя файла без пути.

Соответственно, везде, где мы используем __FILE__, достаточноп обавить отсчечение пути и поведение будет полностью эквивалентным.

Это не потребует повторного тестирования при каждой правке кода.
 
Crazy

Crazy

Developer
Сохранения пути тоже можно добиться, но принципиально более извратным способом. :)

Но, как ни странно, мне вариант без пути -- или, точнее, без полного пути, нравится больше. Более секьюрно. :)
 

si

Administrator
дело тут не в секурити, они об этом не думали, __FILE__ - это константа времени компиляции.
 
Crazy

Crazy

Developer
Дело в скьюрити в том смысле, что негоже юзеру при срабатывании, к примеру, assert'а видеть полный путь. Т.е. не страшно, но все же не хотелось бы. Но авторы исходили конечно же не из этого.

То, что __FILE__ есть константа времени компиляции, вполне понятно. Но вот вопрос: если вызывать с указанием не просто имени файла, а с путем, то что сохранится в этой константе?
 

si

Administrator
это константя определяется при компиляции, в нашем случае при кодировании, т.е в закидированном скрипте там будет то имя файла что было при кодировании даже если потом файл изменит свое имя
 
Crazy

Crazy

Developer
Эт' я еще утром проверил. :)

Я про другое. Если при обращении к энкодеру указать имя файла не "foobar.php", а "buzz/quixx/foobar.php", то созранится ли имя с указанным путем в константе __FILE__?
 
Crazy

Crazy

Developer
Прекрасный эффект получается. Кодируем все файлы из корня сайта с указанием относительных путей и получает удобны в относительные пути в качестве значений __FILE__.

Если бы я использовал __FILE__, то мне бы этого хватило бы.
 

SeregaP

Guest
какая замечательная подборка ссылок. Мне б ее месяц назад :)

отвечу на некоторые неотвеченные вопросы
1) как кодирует Zend Encoder
в ZE включен Zend Optimizer, при кодировании скрипта сначала он обрабатывается ZO, приводится к более оптимизированному виду, потом он компилируется в байт-код для выполнения движком zend(php) (то же самое делает APC Cache, чья выдержка тут ранее приводилась). В этом байт-коде уже не видно исходников, но сделать обратное преобразование в принципе можно.
После этого байт-код уже шифруется каким то алгоритмом и записывается в файл.
Процесс расшифровки - обратный. Файл расшифровывается, получается байт-код, который уже пригоден для выполнения движком, он и выполняется :)
Отсюда плюсы и минусы:
плюсы: скорость выполнения у нас в общем случае возрастает, поскольку не надо компилировать файл, мы уже получаем готовый байт-код. Тратится, конечно, время на расшифровку, но для больших и средних файлов время компиляции гораздо больше чем расшифровки.
минусы: о взломе - теоретически такая возможность есть, поскольку у взломщика на руках есть и код расшифровщика, и зашифрованный файл, и сам ключ сокрыт где то в недрах зашифрованного файла. Однако поскольку исходных кодов, а след. подробнойстей алгоритма шифрования и хранения ZE ни у кого нет, то для выяснения метода шифрования и ключа потребуется декомпилировать выполняемый файл расшфровщика, написанного на СИ. Что, наверное, не проще, чем декомпилировать байт-код php в исходный php код.
То есть для большинства приложения такая схема может считаться достаточно надежной.
 
Войдите или зарегистрируйтесь для ответа.
Сверху