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

4. Создается 2-ой функциональный блок и помещается в промежуточное хранилище. Алгоритм создания подобен алгоритму, описанному в шаге 3. Но только теперь подставляется не только номер регистра или ячейки памяти, куда помещается значение, но и адрес памяти с источником. В эту ячейку памяти в дальнейшем виртуальная машина будет помещать размер шифруемой/расшифруемой области.

5. Необходимое количество раз создаются и помещаются в промежуточное хранилище функциональные блоки под номером 3. Механизм их генерации также схож с шагами 3 и 4. Отличием является то, что некоторые константы в коде блока заменяются случайными числами. Например, эти значения при шифровании или расшифровании будут складываться с преобразуемыми ячейками памяти, вычитаться и так далее.

6. Подсчитывается размер уже сгенерированных блоков. Это число затем будет использоваться для случайной генерации адреса начала блоков в цикле.

7. Рассчитывается размер памяти, который будет выделен под уже сгенерированные блоки (расположенные до цикла) с резервированием места под холостые блоки. Также подсчитывается адрес первого блока в цикле.

8. Необходимое количество раз создаются и помещается в промежуточное хранилище функциональные блоки под номером 3. Это шаг несколько сложнее, чем все другие. Здесь весьма сильная зависимость между сгенерированным кодом шифрования и расшифрования. В коде расшифрования используются обратные по действию операции относительно операций шифрования. При этом они располагаются в обратной последовательности.

9. Создается 5-ый функциональный блок и помещается в промежуточное хранилище.

10. Создается 6-ой функциональный блок и помещается в промежуточное хранилище. Это блок, организующий цикл, поэтому он использует адреса, рассчитанные на шаге 7.

11. Создается 7-ой функциональный блок и помещается в промежуточное хранилище.

12. Создается 8-ой функциональный блок и помещается в промежуточное хранилище.

13. Созданные функциональные блоки размещаются в одной области памяти с промежутками случайного размера. После чего получается картина подобная тем, что приведены на рисунках 6 и 7.

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

15. Происходит запись в файл необходимых идентификаторов, структур, различных данных и самого полиморфного кода. В результате мы получаем то, что называется файлом с полиморфный алгоритмом.

3.2.3.3. Таблицы блоков для генерации полиморфного кода

Выше неоднократно упоминались таблицы блоков, среди которых происходит выбор. Приведем для примера часть таблицы с блоками N 1 и опишем ее устройство.

//--------------------------------------------------------------

// Блок N0. (x1)

// Служит для инициализации указателя нулем.

// ES_VARIABLE_0 - ячейка которая может быть занята под указатель.

// ES_REG_0 - регистр который может быть занят под указатель.

BLOCK_START(00_00)

EO_MOV, EOP_VAR, ES_VARIABLE_0, EOP_CONST, 0

BLOCK_END(00_00)

BLOCK_START(00_01)

EO_MOV, EOP_REG, ES_REG_0, EOP_CONST, 0

BLOCK_END(00_01)

BLOCK_START(00_02)

EO_PUSH, EOP_CONST, 0,

ES_RANDOM_NOP,

ES_RANDOM_NOP,

EO_POP, EOP_REG, ES_REG_0

BLOCK_END(00_02)

. . . . . . .

BLOCKS_START(00)

BLOCK(00_00)

BLOCK(00_01)

BLOCK(00_02)

BLOCK(00_03)

. . . . .

BLOCKS_END(00)

BLOCKS_SIZE_START(00)

BLOCK_SIZE(00_00)

BLOCK_SIZE(00_01)

BLOCK_SIZE(00_02)

BLOCK_SIZE(00_03)

. . . . .

BLOCKS_SIZE_END(00)

//--------------------------------------------------------------

Рассмотрим строку "BLOCK_START(00_00)". BLOCK_START представляет собой макрос который делает код более понятным и раскрывается так:

#define BLOCK_START(num) const static int block_##num [] = {

BLOCKS_END раскрывается в:

#define BLOCK_END(num) }; const size_t sizeBlock_##num =\

CALC_ARRAY_SIZE(block_##num);

Таким образом, BLOCK_START и BLOCK_END позволяет получить именованный массив и его длину. Это удобно для автоматического построения массива указателей на блоки и их длину. Нам более интересны не эти вспомогательные макросы, а следующая строка.

EO_MOV, EOP_VAR, ES_VARIABLE_0, EOP_CONST, 0

Она представляет собой один из вариантов реализации первого блока. EO_MOV означает, что будет выполнена команда пересылки данных. EOP_VAR означает, что запись будет производиться в ячейку памяти. Этот блок никогда не станет выбранным, если при выборе характеристик алгоритма будет решено, что под указатель необходимо использовать регистр. Если же будет принято решение использовать ячейку памяти, то этот блок попадет в список из которого затем случайным образом будет произведен выбор. ES_VARIABLE_0 это идентификатор на место которого будет подставлен номер переменной, используемой для хранения указателя. Этот номер также генерируется на этапе выбора характеристик. EOP_CONST означает, что переменной будет присвоено значение константы. Этим значением является 0.

Аналогичным образом интерпретируется строка: EO_MOV, EOP_REG, ES_REG_0, EOP_CONST, 0. Но теперь вместо виртуальной ячейки памяти выступает виртуальный регистр. Более интересным является следующий блок:

EO_PUSH, EOP_CONST, 0,

ES_RANDOM_NOP,

ES_RANDOM_NOP,

EO_POP, EOP_REG, ES_REG_0

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

Макросы BLOCKS_START и BLOCKS_SIZE_START носят вспомогательный характер и не представляют большого интереса. Они просто строят таблицы адресов различных блоков и их размеров.

3.2.4. Уникальность генерируемого полиморфного алгоритма и сложность его анализа

Важная идея в разрабатываемом модуле защиты заключена в построении сложного для анализа полиморфного кода, что должно препятствовать построению обратного алгоритма, так как в защищаемых системах часто просто невозможно хранить ключи отдельно от данных. Если есть доступ к ключам, то и увеличивается вероятность каким-либо образом произвести несанкционированные действия. Из этого следует необходимость создания сложных для анализа алгоритмов шифрования/расшифрования. Одним из этих средств является виртуальная машина. Другим – использование полиморфных алгоритмов. Это затрудняет возможности по анализу механизмов шифрования данных, так как полный анализ одного алгоритма очень мало помогает в анализе другого. Чем больше возможно вариантов построения полиморфного кода, тем более трудоемкой становится процедура анализа. Следовательно, можно сказать, что критерий надежности повышается с ростом количества возможных вариантов полиморфного кода. Подсчитаем количество возможных вариантов, который может сгенерировать разработанный генератор полиморфного кода.