Предыдущая страница реферата | 10  11  12  13  14  15  16  17  18  19  20 | Следующая страница реферата

б) В код блока подставляется соответствующий номер регистра или адрес виртуальной ячейки памяти.
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. Уникальность генерируемого полиморфного алгоритма и сложность его анализа

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

Вероятность генерации двух одинаковых пар составляет: (2^32*3)^5 (
3.5*10^50. Где 2^32 – случайно используемая константа для шифрования. 3 – количество возможных операций над числом. 5 – максимальное количество проходов для шифрования. Фактически это означает что два одинаковых алгоритма не будут никогда сгенерированы этой системой. Но это не является целью. Ведь то что не генерируются 2 одинаковых алгоритма, не так важно.
Важно что анализ таких разнородных механизмов шифрования/расшифрования будет очень плохо поддаваться анализу.

Покажем на примере, что именно могут дать полиморфные алгоритмы.
Предположим кто-то задумал создать универсальный редактор отчетов о выполненных работах, создаваемых АРМ студента. В этом отчете хранится оценка о тестировании. Ее исправление и является целью. АРМ студента шифрует файл с отчетом уникальным полиморфным алгоритмом, сгенерированным специально для данного студента. Ключ расшифрования у студента не хранится.
Он находится у АРМ преподавателя и служит для идентификации, что студент выполнил работу именно на своем АРМ. В противном случае файл с отчетом просто не расшифруется.

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

В первом случае может понадобиться разрабатывать достаточно сложную систему с целью эмуляции генератора отчета. Это очень труднореализуемо. В каком-то смысле придется повторить большую часть функциональности АРМ студента. Так, если в отчете будут храниться вопросы, которые были заданы студенту, то, фактически, придется работать с этой базой вопросов и случайно выбирать из них. В противном случае, если использовать строго определенный набор, то у всех, кто воспользуется такой системой взлома, будут совпадать отчеты. Это может привести к подозрению со стороны преподавателя. Таким образом, в грамотно и сложно организованной АСДО этот подход практически не применим.

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

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

На мой взгляд, созданная система достаточно сложна в плане анализа и может эффективно помочь защищать АСДО и другие программы от несанкционированных действий.

3.3. Особенности реализации модуля защиты

Рекомендуем скачать другие рефераты по теме: ответы 5 класс, реферат теория.



Предыдущая страница реферата | 10  11  12  13  14  15  16  17  18  19  20 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки