2.3. Защита, основанная на человеческом факторе злоумышленника

Как было показано выше, одна из целей разработчиков защиты ПО от отладки и дизассемблирования – как можно сильнее затруднить данный процесс, чтобы он отнимал у злоумышленника большое количество времени, либо отбить желание у злоумышленника исследовать программу под отладчиком и анализировать дизассемблированный текст. Одна из методологий осуществления этого – атака на человеческий фактор взломщика (взломщик атакует защиту, а разработчик защиты атакует взломщика). Данная атака заключается в атаке на психику и психологию взломщика, на то, чтобы как можно больше раздражать его исследованием кода программы. Ниже приведено несколько подходов к осуществлению такой атаки.

1. Перемешивание кода программы.

В данном случае пишется специальный модуль, перемешивающий инструкции кода программы. Если первую инструкцию оставить на месте, другие разбросать в разные области, и перед каждой следующей инструкцией вставить команду перехода на нее, то общая последовательность выполнения инструкций программы не изменится и код будет иметь тот же семантический смысл.

Пример 2.5. Пусть оригинальный код выглядит следующим образом:

start:

Инструкция 1

Инструкция 2

Инструкция 3

Инструкция 4

end:

Тогда, данный код может быть, например, перемешан следующим образом:

start:

jmp @@1

@@4:

instruction 4

jmp end

@@2:

instruction 2

jmp @@3

@@1:

instruction 1

jmp @@2

@@3:

instruction 3

jmp @@4

end:

Допустим, что в тексте программы находится типичный кусок какой-либо классической защиты, например,

0000000: 16 push ss

0000001: 17 pop ss

0000002: 9C pushf

0000003: 58 pop ax

0000004: A90001 test ax

0000007: 740C je DebuggerDetected

Суть происходящего в этом примере очевидна: вся последовательность команд у злоумышленника перед глазами и ничто не составляет для него труда проанализировать эту последовательность и обойти ее. Если же перемешать данный участок кода, то провести анализ кода будет уже гораздо сложнее: в отладчике злоумышленник будет наблюдать постоянные прыжки с места на место, причем отследить, откуда была сделана очередная команда перехода, будет весьма проблематично (не все отладчики имеют подобные функции). Если дизассемблировать такой исполняемый файл, то мы получим листинг, который придется постоянно листать взад - вперед, отслеживая выполнение программы. Перемешанный код может в результате выглядеть, например, следующим образом.

00000000: 16 push ss

00000001: EB07 jmps 00000000A

00000003: 58 pop ax

00000004: EB08 jmps 00000000E

00000006: 740B je RealModeDebuggerDetected

00000008: EB09 jmps 000000013

0000000A: 17 pop ss

0000000B: 9C pushf

0000000C: EBF5 jmps 000000003

0000000E: A96400 test ax,00064

00000011: EBF3 jmps 000000006

Если таким образом обработать достаточно большой участок кода, то разобраться в результатах обработки будет в практически невозможно. Данную обработку можно выполнять последовательно несколько раз.

Для восстановления исходной последовательности команд придется писать раскодировщик результата перемешивания путем сохранения реальных инструкций без сохранения прыжков, однако, написание такого раскодировщика сопровождается рядом трудностей (например, собственно трудоемкость написания раскодировщика, трудность восстановления команд с относительной адресацией и т.д.).

2. Задача анализа кода взломщиком намного усложнится, если в некоторых случаях команду безусловного перехода заменить на команду условного (в данном случае, мы должны быть точно уверены в содержимом регистра флагов). Например, в следующем случае, переход будет осуществляться всегда:

Xor ax,ax

Je 000000025