Zend Guard под хакерским прицелом

Paxan [tPORt] (paxan@tport.be)

Хакер, номер #091, стр. 091-090-4

Пакуем, пробуем запускать, и видим:

Script start

11

О, чудо! Скрипт запустился! Как видите, вырезание требования лицензии - задача тривиальная и очень легко поддается автоматизации.

И, наконец, третий тип лицензии — это «Support License». Он служит для ограничения возможностей скрипта при отсутствии лицензии.

Тут совсем все легко. Для примера напишем скрипт:

<?php

$licinfo = zend_loader_file_licensed();

if ($licinfo === FALSE) {

echo "Demo Version";

} else {

echo "Full Version, license data:";

print_r($licinfo);

}

?>

Закодируем c «Support License», запустим и, естественно, получим «Demo Version». Распакуем. Сразу бросается в глаза, что контрольная сумма у нас зависит только от имени, то есть adler32_hash(«Zend Encoder trial»,18) = 1036256941.

Поэтому весь лицензионный «мусор» мы можем смело вырезать. А имя функции изменим на zend_loader_file_licen"z"ed.

Пакуем под названием script.php и пишем небольшой сценарий:

<?

function zend_loader_file_licen"z"ed() {

return array("Product-Name" => "MyProduct"); // ну и остальные лицензионные параметры не забываем вернуть

// подробнее, какие параметры должна возвращать

// zend_loader_file_licensed(), можно посмотреть в документации

}

include("script.php");

?>

Запускаем его и видим:

Full Version, license data:Array

(

[Product-Name] => MyProduct

)

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

Хочу отметить, почему нельзя было менять контрольную сумму. Дело в том, что номеров опкодов PHP в скрипте явно нет, но есть смещения, по которым мы получим оригинальные опкоды. Примерно так:

char opcode = table[offset] - (opcodenum & 7)

В скрипте есть только offset и, естественно, порядковый номер опкода, относительно начала функции opcodenum. Сама же таблица, по которой мы получаем оригинальные номера опкодов, генерируется в зависимости от контрольной суммы. Алгоритм генерации я выкладывать не буду: он достаточно громоздкий. Найти его очень легко — надо просто проследить, куда уходит хэш. Вот почему мы не можем менять контрольную сумму просто так, ведь «сьедут» все смещения опкодов, и интерпретатор начнет выполнять чушь. Поэтому если мы хотим поменять хэш, то нам надо поменять все смещения опкодов во всем скрипте.

Резюмируя данную главу, отмечу: вся лицензионная защита скрипта обходится буквально за 5 минут. Есть и другой вариант обхода — править сам Optimizer, но это не универсальный вариант, так как на чужом хостинге никто не даст этого сделать.

Получение дампа скрипта

Хочу заметить, что у кодировщика существует несколько уровней оптимизации: full, minimal, none. Напоминаю, что мы остановились на последнем параметре «dummy.addr». При оптимизации уровня full кодировщик сразу записывает после «dummy.addr» количество функций, для имен которых предварительно рассчитан хэш.