Для наглядной демонстрации, как происходит выполнение кода в виртуальной машине при шифровании/расшифровании данных, приведем отрывок из отладочного отчета. Каждое действие в отладочном режиме протоколируется в файле uniprot.log. Благодаря этому, было легко отлаживать механизм генерации полиморфных алгоритмов и саму работу алгоритмов. Дополнительным результатом создания механизма протоколирования стала возможность показать, как происходит выполнение алгоритма шифрования расшифрования. Ниже приведен отрывок из файла uniprot.log, относящийся к процессу шифрования данных. С целью сокращения объема текста, убраны дублирующийся вывод внутри цикла. Также при генерации этого алгоритма были выставлена вложенность шифрования равная единицы и почти убраны холостые блоки.

=== Start TranslateOperations ===

mov RAND ==> REG_2

xchg REG_2 VAR_16 <==> REG_2 VAR_16

mov CONST ==> VAR_11

dec VAR_11 ==> VAR_11

cmp VAR_11 CONST

jnz CONST

mov RAND ==> REG_6

xchg VAR_14 VAR_12 <==> VAR_14 VAR_12

mov CONST ==> VAR_15

add VAR_15 VAR_18 ==> VAR_15

mov RAND ==> REG_4

mov CONST ==> VAR_19

add VAR_19 VAR_9 ==> VAR_19

add REG_8 REG_7 ==> REG_8

xchg REG_2 VAR_13 <==> REG_2 VAR_13

Эта часть повторяется много раз:

mov RAND ==> REG_6

xor REF_VAR_11 VAR_14 ==> REF_VAR_11

mov RAND ==> REG_4

mov RAND ==> REG_9

xor REF_VAR_11 VAR_15 ==> REF_VAR_11

sub VAR_11 CONST ==> VAR_11

mov RAND ==> REG_7

dec VAR_14 ==> VAR_14

cmp VAR_14 CONST

jnz CONST

…………..

mov RAND ==> REG_1

add REG_9 REG_6 ==> REG_9

test_time1 VAR_10

OK TIME (continue)

exit

3.2.3. Генератор полиморфного кода

3.2.3.1. Блочная структура полиморфного кода

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

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

// Блок N5. (x1)

// Служит для организации цикла.

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

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

// ES_ADDRESS_0 - куда осуществить переход для повтора цикла.

BLOCK_START(05_00)

EO_DEC, EOP_VAR, ES_VARIABLE_0,

EO_CMP, EOP_VAR, ES_VARIABLE_0, EOP_CONST, 0,

EO_JNZ, EOP_CONST, ES_ADDRESS_0

BLOCK_END(05_00)

BLOCK_START(05_01)

EO_DEC, EOP_REG, ES_REG_0,

EO_CMP, EOP_REG, ES_REG_0, EOP_CONST, 0,

EO_JNZ, EOP_CONST, ES_ADDRESS_0

BLOCK_END(05_01)

BLOCKS_START(05)

BLOCK(05_00)

BLOCK(05_01)

BLOCKS_END(05)

BLOCKS_SIZE_START(05)

BLOCK_SIZE(05_00)

BLOCK_SIZE(05_01)

BLOCKS_SIZE_END(05)

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

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

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

Вернемся к распределению блоков в памяти. Помимо того, что каждый алгоритм состоит из произвольного набора функциональных блоков, эти блоки не имеют фиксированного места расположения. Скажем, что под весь алгоритм выделено 200 байт, а размер всех блоков в сумме составляет 100 байт. В результате положение этих блоков как бы "плавает" от одного сгенерированного алгоритма к другому. Должно выполняться лишь одно условие: соблюдение четкой последовательности расположения блоков. То есть, адрес расположения блока с большим номером не может быть меньше, чем адрес блока с меньшим номером. Для большей наглядности приведем рисунок 6.

Рисунок 6. Расположение функциональных блоков в памяти.

Белым цветом показаны все функциональные блоки. Серым цветом отмечены пустые места, которые будут заполнены произвольными холостыми блоками.

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

Рисунок 7. Плотное расположение функциональных блоков в памяти.

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

3.2.3.2. Алгоритм генерации полиморфного кода

Опишем теперь пошагово как работает генератор полиморфного кода.

1. На первом этапе выбираются характеристики будущих алгоритмов. К ним относятся:

a) размер памяти, выделенной под код;

б) в каких регистрах или ячейках будут располагаться указатели на модифицируемый код;

г) сколько раз будут повторяться функциональные блоки 3 и 4;

д) в каких регистрах или ячейках будут располагаться счетчики циклов;

При этом количество повторений блоков 3 и 4 должно быть одинаковым и для алгоритма шифрования и для алгоритма расшифрования, так как каждой команде преобразования данных при шифровании должна быть сопоставлена обратная команда в алгоритме расшифрования.

2. Виртуальная память, используемая в алгоритме, заполняется случайными значения.

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,

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,

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. Особенности реализации модуля защиты

Разрабатываемый модуль защиты Uniprot будет представлять собой файл типа dynamic link library (DLL) с именем Uniprot.dll.

Для организации взаимодействия модуль защиты предоставляет набор интерфейсов с использованием технологии COM. Для описания интерфейсов используется специальный язык - IDL, по своей структуре очень похожий на С++. В определении интерфейса описываются заголовки входящих в него функций с указанием их имен, возвращаемых типов, входных и выходных параметров, а также их типов. Подробно с предоставляемыми интерфейсами можно будет ознакомиться в разделе 4.2. Интерфейсы, описанные в IDL файле, преобразуются IDL-компилятором (MIDL.EXE) в двоичный формат и записываются в файл с расширением TLB, который называется библиотекой типов. Этот файл будет необходим, например, для использования модуля Uniprot.dll из среды Visual Basic. С процессом подключения TLB файлов в Visual Basic можно ознакомиться в разделе 4.4.2.

Для регистрации модуля в системе необходимо вызвать в нем функцию DllRegisterServer, которая внесет нужные изменения в реестр. Для этих целей можно воспользоваться утилитой regsvr32.exe. Она поставляется вместе с операционной системой, а потому должна находиться на любой машине. Regsvr32 должна загрузить СОМ-сервер и вызвать в нем функцию DllRegisterServer, которая внесет нужные изменения в реестр.

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

3.4. Защита исполняемых файлов

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

Разработанная программа имеет два возможных режима запуска. Первый - для генерации зашифрованного файла из указанного исполняемого модуля. Второй -для запуска защищенного модуля. Рассмотрим шаги, которые выполняет механизм шифрования исходного файла.

1. Инициализация библиотеки Uniprot.

2. Чтение исполняемого файла в память.

3. Запуск исполняемого файла с флагом остановки. То есть программа загружается, но управления не получает.

4. Чтение частей загруженной программы и поиск ее соответствующих частей в прочитанном файле. Найденные части кода сохраняются отдельно. После чего их места в буфере с прочитанным файлом заменяются случайными значениями.

5. Генерация алгоритма шифрования и расшифрования.

6. Запись в зашифрованный файл буфера с прочитанным, а затем измененным файлом. В этот же файл пишутся выделенные фрагменты кода.

7. Удаление файла шифрования, так как он более не предоставляет интереса.

Теперь рассмотрим шаги, которые выполняет механизм запускающий зашифрованный файл на исполнение.

1. Поиск соответствующего файла с алгоритмом расшифрования.

2. Создание временного исполняемого файла и запись в него "испорченного" файла (см. механизм шифрования, пункт 4).

3. Запуск "испорченного" исполняемого файла с флагом остановки. То есть программа загружается, но управления не получает.

4. Восстановление "испорченных" мест в памяти. Изначальный код для исправления также хранится в зашифрованном файле.

5. Передача управления расшифрованному файлу.

6. Ожидание окончания выполнения запущенной программы.

7. Удаление временного файла.

Как видно из описания, данная программа достаточна проста в своем устройстве и достаточна эффективна.

ГЛАВА 4. ПРИМЕНЕНИЕ СИСТЕМЫ ЗАЩИТЫ

4.1. Состав библиотеки Uniprot

В состав библиотеки входят следующие компоненты:

1. Исходные тексты COM модуля Uniprot.dll.

2. Исходные тексты программы ProtectEXE.exe.

3. Отдельно собранные файлы, необходимые для подключения Uniprot.dll. Этими файлами являются: export.cpp, export.h, Uniprot.tlb.

4. Файл reg_uniprot.bat для регистрации COM модуля Uniprot.dll.

5. Руководство программиста по использованию модуля Uniprot.dll.

6. Руководство программиста по использованию программы ProtectEXE.exe.

7. Набор примеров написанных на Visual Basic, демонстрирующих работу с библиотекой Uniprot.

4.2. Руководство программиста по использованию модуля Uniprot.dll

Вначале опишем вспомогательный тип CreateMode, используемый в методе Create. Он описывает тип создаваемого зашифрованного файла. В данной версии модуля Uniprot он может иметь два значения: DEFAULT и DISABLE_ARC. Первый из них сообщает функции, что будет создан обыкновенный зашифрованный файл. Данные в нем будут вначале упакованы библиотекой zlib, а затем уже зашифрованы. Это может дать существенный выигрыш в плане уменьшения размера выходного файла, например, на картинках в формате BMP или простом тексте. Использование DISABLE_ARC приведет к созданию зашифрованного, но не сжатого файла. Это даст выигрыш по времени при распаковке и упаковке, но не уменьшит размер зашифрованного файла. Это также может быть полезно при шифровании уже сжатых файлов. Примером могут являться картинки в формате JPG.

enum CreateMode

{

DEFAULT = 0,

DISABLE_ARC = 1

} CreateMode;

Теперь опишем функции, предоставляемые интерфейсом IProtect. В этот интерфейс собраны функции общего плана и генерации файлов с полиморфными алгоритмами шифрование и расшифрования.

interface IProtect : IDispatch

{

[id(1), helpstring("method GetInfo")]

HRESULT GetInfo(

[out] short *version, [out] BSTR *info);

[id(2), helpstring("method Generate UPT files")]

HRESULT GenerateUPTfiles(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName);

[id(3), helpstring("method Generate Time Limit UPT files")]

HRESULT GenerateTimeLimitUPTfiles(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName,

[in] long LimitDays);

[id(4), helpstring("method Generate Time Limit UPT files")]

HRESULT GenerateTimeLimitUPTfiles2(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName,

[in] long LimitDaysCrypt,

[in] long LimitDaysDecrypt);

};

Теперь опишем каждую из функций интерфейса IProtect.

HRESULT GetInfo([out] short *version, [out] BSTR *info);

Функция GetInfo возвращает строку с краткой информации о данном модуле и его версии. Может быть использована для получения рядя сведений о модуле. Например, имя автора и год создания. Версия хранится в виде числа следующим образом: 0x0100 - версия 1.00, 0x0101 - версия 1.01, 0x0234 - версия 2.34 и так далее.

Описание используемых параметров:

version - сюда будет занесена версия модуля.

info - сюда будет занесена строка с краткой информацией о модуле.

HRESULT GenerateUPTfiles(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName);

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

Описание используемых параметров:

algorithmCryptFileName - имя выходного файла с алгоритмом шифрования.

algorithmDecryptFileName - имя выходного файла с алгоритмом расшифрования.

HRESULT GenerateTimeLimitUPTfiles(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName,

[in] long LimitDays);

Функция GenerateTimeLimitUPTfiles генерирует два файла-ключа, ограниченных в использовании по времени. В целом функция эквивалентна GenerateUPTfiles, но генерируемые ею алгоритмы имеют дополнительное свойство. Их использование ограничено определенным временем. Количество дней, в течении которых они будут работать, указывается в третьем параметре LimitDays. Отсчет начинается с текущего дня. Это может быть полезно, например, для ограничения срока использования проектов. Естественна защита сама по себе ненадежна, так как невозможно защититься от перевода часов на компьютере или модификации кода модуля защиты с целью удаления соответствующих проверок. Но тем не менее это может дать дополнительные свойства защищенности, по крайней мере от рядовых пользователей.

Описание используемых параметров:

algorithmCryptFileName - имя выходного файла с алгоритмом шифрования.

algorithmDecryptFileName - имя выходного файла с алгоритмом расшифрования.

LimitDays - количество дней, в течении которых будут функционировать сгенерированные алгоритмы.

HRESULT GenerateTimeLimitUPTfiles2(

[in] BSTR algorithmCryptFileName,

[in] BSTR algorithmDecryptFileName,

[in] long LimitDaysCrypt,

[in] long LimitDaysDecrypt);

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

Описание используемых параметров:

algorithmCryptFileName - имя выходного файла с алгоритмом шифрования.

algorithmDecryptFileName - имя выходного файла с алгоритмом расшифрования.

LimitDaysCrypt - количество дней, в течении которых будут функционировать сгенерированный алгоритм шифрования.

LimitDaysDecrypt - количество дней, в течении которых будут функционировать сгенерированный алгоритм расшифрования.

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

interface IProtectFile : IDispatch

{

[id(1), helpstring("method Create New File")]

HRESULT Create(

[in] BSTR name,

[in] CreateMode mode,

[in] BSTR uptFileNameForWrite,

[out, retval] short *handle);

[id(2), helpstring("method Open File")]

HRESULT Open(

[in] BSTR name,

[in] BSTR uptFileNameForRead,

[in] BSTR uptFileNameForWrite,

[out, retval] short *handle);

[id(3), helpstring("method Close File")]

HRESULT Close(

[in] short handle);

[id(4), helpstring("method Write To File")]

HRESULT Write(

[in] short handle,

[in] VARIANT buffer,

[out, retval] long *written);

[id(5), helpstring("method Read From File")]

HRESULT Read(

[in] short handle,

[out] VARIANT *buffer,

[out, retval] long *read);

[id(6), helpstring("method Write String To File")]

HRESULT WriteString(

[in] short handle,

[in] BSTR buffer,

[out, retval] long *written);

[id(7), helpstring("method Read String From File")]

HRESULT ReadString(

[in] short handle,

[out] BSTR *buffer,

[out, retval] long *read);

[id(8), helpstring("method From File")]

HRESULT FromFile(

[in] short handle,

[in] BSTR FileName,

[out, retval] long *read);

[id(9), helpstring("method To File")]

HRESULT ToFile(

[in] short handle,

[in] BSTR FileName,

[out, retval] long *written);

};

Опишем функции в данном интерфейсе.

HRESULT Create(

[in] BSTR name,

[in] CreateMode mode,

[in] BSTR uptFileNameForWrite,

[out, retval] short *handle);

Функция Create служит для создания новых зашифрованных файлов. Поскольку во вновь созданный файл можно только писать, то функции необходим для работы только файл с алгоритмом шифрования. Имя файла с этим алгоритмом передается третьим параметром и является обязательным. Параметр mode имеет тип CreateMode, для чего он служит, было сказано ранее. При успешном создании файл, в handle возвращается его дескриптор. По окончании работы с файлом, его обязательно нужно закрыть, используя функцию Close.

Описание используемых параметров:

name - имя создаваемого файла.

mode - тип создаваемого файла (см. ранее описание типа CreateMode)

uptFileNameForWrite - имя файла с алгоритмом шифрования.

handle - возвращаемый дескриптор созданного файла.

HRESULT Open(

[in] BSTR name,

[in] BSTR uptFileNameForRead,

Страницы: 1, 2, 3, 4, 5