Крис Касперски - Неявный самоконтроль как средство создания не ломаемых защит

одной общей крышей, то размеры массивов gag_1 и gag_2 станут зависеть от
количества и размера используемых нами локальных переменных:
union anti_hack
{
char buf[MAX_CODE_SIZE];
struct code_control
{
int
local_var_1;
int
local_var_2;

Крис Касперски

8

Неявный самоконтроль как средство создания не ломаемых защит
char
int
char
int

gag_1[OFFSET_1
sizeof(int)*2];
x_val_1;
gag_2[OFFSET_2
OFFSET_1
sizeof(int)];
x_val_2;

};
};

Код, выделенный жирным шрифтом, как раз и отвечает за то, чтобы размер
массивапустышки gag_1, компенсировал пространство, занятое локальными пе
ременными. Такая ручная "синхронизация" крайне ненадежна и служит источни
ком потенциальных ошибок. С другой стороны, теперь мы можем не беспокоить
ся, что локальные переменные случайно затрут контрольные точки, т. к. если такое
произойдет, длина массива gag_1 станет отрицательной и компилятор тут же выска
жет нам все, что он о нас думает. Поэтому, окончательный выбор используемой
конструкции остается за вами.
Теперь – пару слов о расшифровке (распаковке) нашей программы. Вопер
вых, нет нужды расшифровывать всю программу целиком, – достаточно расши
фровать лишь сам защитный механизм, а то и его критическую часть. Причем, са
ма процедура расшифровки должна быть написано максимально просто и незамы
словато. Поверьте, лишние уровни защиты здесь совершенно ни к чему. Хакер все
равно их вскроет за очень короткое время, и, самое главное, чем круче окажется за
щита, тем внимательнее будет вести себя хакер. Мы же, напротив, должны убедить
его, что шифровка это – так, защита от детишек, и "настоящая" защита спрятана
гдето совсем в другом месте (пусть ищет то, чего нет!).
Правда, тут есть одна проблема. По умолчанию Windows запрещает модифи
кацию кодовой секции PEфайла и потому непосредственная расшифровка кода
невозможна! Первая же попытка записи ячейки, принадлежащей секции .text, вы
зовет аварийное завершение программы. Можно, конечно, обхитрить Windows,
создав свою собственную секцию, разрешающую операции чтения, исполнения
и записи одновременно, или, как еще более изощренный вариант, исполнять рас
шифрованный код непосредственно в стеке, однако, мы пойдем другим путем
и просто отключим защиту кодового сегмента от его непредумышленной модифи
кации. Достоинство этого приема в том, что он очень просто реализуется, а недо
статок – ослабление контроля за поведением программы. Если в результате тех или
иных ошибок, наша программа пойдет в разнос и начнет затирать свой собствен
ный код, операционная система будет бессильна ее остановить, поскольку мы сами
отключили защиту! С другой стороны, в тщательно протестированной программе
вероятность возникновения подобной ситуации исчезающе мала и в ряде случаев
ею можно смело пренебречь. Во всяком случае, в примере, приведенном ниже, мы
поступим именно так (речь ведь все равно идет не о технике расшифровке, а о не
явном контроле за модификацией кода).
Остается лишь обмолвится парой слов о способах определения диапазона
адресов, принадлежащих защитному коду. Поскольку, большинство компиляторов
размешают функции в памяти в порядке их объявления в программе, адрес начала
защитного кода совпадает с адресом первой, относящейся к нему функции, а адрес
конца равен адресу первой не принадлежащей к нему функции (т. е. первой функ
ции, расположенной на его "хвостом").
Крис Касперски

9

Неявный самоконтроль как средство создания не ломаемых защит
Теперь, разобравшись с расшифровкой, переходим к самому интересному –
неявному контролю за критическими точками нашего защитного механизма. Пусть
у нас имеется контрольная точка x_val_1, содержащая значение x_original_1, тогда
для его неявной проверки можно "обвязать" некоторые вычислительные выраже
ния следующим кодом: some_var = some_var + (x_val_1 – x_original_1). Если кон
трольная ячейка x_val_1 действительно содержит свое эталонное значение x_origi
nal_1, то разность двух этих чисел равна нулю, а добавление нуля к чему бы то ни
было, никак не изменяет его значения. Грубо говоря, x_val_1 уравновешивается
противоположным ему по знаку x_origial_1 и за это данный алгоритм называют "ал
горитмом коромысла" или "алгоритмом весов". Можно ли быстро обнаружить та
кие "весы" беглым просмотром листинга программы? Не спешите отвечать "нет",
поскольку правильный ответ – "да". Давайте рассуждать не --">