Предыстория
Жил-был один старый-старый сайт. Родители от него отказались, и на втором десятке лет существования он попал к нам. Он представлял из себя джунгли PHP кода, разбросанного по папкам. Все это было написано в разное время, с использованием разных паттернкостылей, в разных кодировках (до 3ёх кодировок в пределах одного файла). MVC тогда, наверное, еще не было известно, да и о шаблонизаторах разработчики не слышали, так что не стоит удивляться внезапному
<? if (cond) { ?>
в HTML разметке. Я провел не один час в увлекательных поисках нужного
<? } ?>
Разработчики не забывали и про бэкапы: в корне можно было найти index.php, index_old.php, index.php.bak. Но несмотря ни на что, это чудо работало. А что работает — не трожь.
Завязка
Эта история началась, когда солнечным декабрьским утром специалист по продвижению с удивлением обнаружил ссылки на чужеродные сайты в футере. Немного покопавшись выяснилось 2 вещи:
- это сапа;
- заказчик недоумевает.
Недоумение заказчика можно понять: у него этих ссылок не видно.
Расследование
Поставили задачу — найти, разобраться и уничтожить. Найдя искомое место в HTML-разметкеподключаемом PHP-файле было получено имя функции, делающей кому-то хорошо. Результат поиска по ~60k файлам кода не принес положительного результата — такой функции нигде не объявлено. Пошел в ход перебор всех файлов, подключаемых в искомой точке входа. В процессе глаз цепляется за файл следующего содержания:
Ничего не понятно, но искреннее спасибо тому человеку, который не убрал аннотацию в шапке. Я начинаю гуглить ''Zend Oрtimizer'', справедливо полагая, что он приведет к расшифровке этого трэша. Поиск рабочего декодера заканчивается тут. Особо порадовала капча:
С некоторым геморром, связанным с запретом копирования результата, я получил следующее:
Я с недоверием отношусь к сложным регулярным выражениям, а тут и вовсе потух. Начинаю вспоминать как работает preg_replace(). И чем больше читаю, тем больше недоумеваю. Само регулярное выражение должно идти первым параметром, а во втором — то, на что заменяют. Посмотрел еще раз на то, что было дано. получается, в строке «x» заменяется "#x#e" на ту длинную штуку. Причем в функции preg_replace() используются модификаторы x и e. Но не дадим себя запутать: все, что помещено между # — экранируется, так что x - это на самом деле то, что следует заменить в строке «x» , т.е. все, а модификатор e позволяет исполнить результирующее выражение как PHP код. При внимательном взгляде на строку замены становится понятно, что большая ее часть — это шум.
Если убрать комментарии, получится
@eval(base64_decode($I0));
На этом месте мне пришлось погуглить значение "@" перед вызовом функции. Далее, спасибо онлайн декодерам, я получил следующую порцию загадок.
Тут я впервые увидел функцию chr(). Позалипал на
$ll = @explode(chr(187) , @implode('', @array_map('trim', @file($ll))));
Загуглил array_map(). В общем тут используется кусок из того самого первоначального файла, зашифрованного Zend Optimizer. Вот уж не знаю какой там алгоритм, но произведя перестановку символов и взяв уже становящийся привычным base64_decode() я получил крипто-функцию:
Дальше ком стал разрастаться экспоненциально, и после нескольких итераций файл достиг 2к строк. Структуру файла после всего этого расследования я оставил на завтра, а пока пара забав:
позволяет остаться незамеченными с терминалов внутренней подсети.
Интересно, они там сразу делают шифровку такую, или это уже кто-то постарался спецом для нас?
Вместо послесловия
Если верить времени создания файлов — на дворе был суровый 2009. Только вот мне даже немного жаль времени тех людей, которые это все зашивали так упорно, потому как я уверен, что этот процесс занял у них времени поболее, чем обратный. И ведь всё это было бы невозможно, если бы только не осталась аннотация о Zend Optimizer.
Автор: sand_alkr
