Как нас сломали
Xakep, номер #036, стр. 036-046-1
Точнее, как сломали электрохакер
Buggzy (www.nerf.ru)
Программист, не знакомый с хакерством, уверен, что никто не догадается, как работает его программа, если она превращена в «сердечки и непонятные символы», то есть откомпилирована в бинарный код в виде exe-файла. Типичная ошибка такого малограмотного программиста - основывать защиту именно на предположении, что алгоритм работы его программы неизвестен хакеру.
В чем ошибка кодера
Защита в этом случае выглядит так: берутся исходные данные, извращаются в меру фантазии разработчика, и из них получается пароль (он же «ключ активации»). Дальше пароль сравнивается с введенным пользователем, и если он совпадает, программа работает, иначе - отказывается. Чем извращеннее способ формирования пароля, тем надежнее - так считает горе-защитник. По моим оценкам, треть защит построена подобным образом. И именно так была сделана защита электронной версии журнала.
Как это использовать
Надо бы заметить, что такие защиты ломаются менее чем за 15 минут. Как правило, нет даже необходимости узнавать алгоритм, по которому формируется пароль, достаточно просто поймать место, где происходит сравнение введенной строки с чем-то еще, и именно это «что-то еще» и будет правильным паролем.
Но в нашем случае полученный таким образом пароль будет различаться на разных машинах, и особого толку от этого взлома нет. Задача хакера - заставить программу работать на любой машине, а пути ее решения - крэк (crack) или кейген (keygen).
Создание кряка и особенно кейгена - гораздо более сложный процесс. От кряка программы защищаются упаковщиками - прогами, которые с помощью шифрования обеспечивают невозможность изменения кода в exe-файле программы. А от создания генераторов ключей призвана защитить сложность алгоритма генерации.
Создатели защиты электронного журнала использовали довольно сложный алгоритм, с которым я так и не разобрался до конца. Но кейген сделать хотелось. Выходом было - поручить генерацию правильного пароля самой программе, а после того, как она сгенерирует его, - прочитать и вывести пользователю.
Подробности взлома
Известно, что Delphi хранит строки в отдельно выделенном куске памяти, а работа происходит со ссылками на них. После того как процедура сравнения пароля отработала, ссылка на строку теряется, но сама строка так и остается лежать в памяти. Если хочется, чтобы строка на самом деле пропадала, надо вручную затирать ее, например, забивать пробелами.
Мне очень помогло, что разработчики присобачили в начало пароля независящий от компьютера кусок текста: "XA0034..." (зачем они это сделали - не пойму, хоть убей :), так что для поиска правильного пароля достаточно было найти в памяти этот кусок текста.
Возможно, разработчики следующей версии исправят перечисленные ляпы, и... защиту опять взломают. Главная проблема защиты - в самой ее концепции, и исправлено это может быть лишь после того, как в числе разработчиков появится грамотный специалист (или два специалиста, крякер и криптоаналитик, не всегда попадется «два специалиста в одном флаконе»). Должны быть исправлены две концептуальных проблемы:
