Обоснование выбора языка программирования

Поможем в ✍️ написании учебной работы

Имя

Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

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

Обоснование выбора среды разработки

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

Обоснование выбора платформы

Платформой для разработки программного продукта была выбрана линейка операционных систем Microsoft Windows, начиная с версии Windows2000. Эта операционная система предоставляет свои широкие функциональные возможности через достаточно стандартизованный и логичный интерфейс API. Кроме того, данная операционная система и ее программные интерфейсы достаточно хорошо изучены и понятны.

Основы криптографии

Криптография дает возможность преобразовать информацию таким образом, что ее прочтение (восстановление) возможно только при знании ключа.

Все многообразие существующих криптографических методов можно свести к следующим классам преобразований:

Моно- и многоалфавитные подстановки

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

Перестановки

Также несложный метод криптографического преобразования. Используется как правило в сочетании с другими методами.

Гаммирование

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

Блочные шифры

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

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

Требования к хорошему блочному шифру формулируются следующим образом. Необходимы:

-достаточно большая разрядность блока (N, 64 или более бит) для того, чтобы затруднить составление и поддержание каталога;

-достаточно большое пространство ключей (K) для того, чтобы исключить возможность подбора ключа;

-сложные соотношения между исходным и шифрованным текстами с тем, чтобы аналитические и (или) статистические методы определения исходного текста и (или) ключа на основе соответствия исходного и шифрованного текстов были бы по возможности нереализуемы.

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

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

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

В режиме сцепления блоков шифра (cipher block chaining, CBC) перед шифрованием над открытым текстом и предыдущим блоком шифротекста выполняется операция XOR.

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

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

В режиме СВС одинаковые блоки открытого текста при шифровании переходят в различные блоки шифротекcта только, если отличались какие-то из предшествующих блоков открытого текста. Два идентичных сообщения, однако, будут шифроваться как один и тот же шифротекст. Что еще хуже, два одинаково начинающихся сообщения будут шифроваться одинаково, пока не появится первое различие.

У ряда сообщений может быть одинаковый заголовок - тема письма, строка "From" или еще что-нибудь. Хотя повтор блока будет невозможен, такое одинаковое начало может предоставить криптоаналитику какую-нибудь полезную информацию. (В данном случае известно, что в образе сформирована файловая система, т.е. известен формат некоторых секторов).

Избежать этого можно, шифруя в качестве первого блока какие-то случайные данные. Этот блок случайных данных называется вектором инициализации (initialization vector, IV), инициализирующей переменной или начальным значением сцепления. IV не имеет никакого смыслового значения, он используется только дня того, чтобы сделать каждое сообщение уникальным. Когда получатель дешифрует этот блок, он использует его только для заполнения регистра обратной связи. Хорошим IV служит метка времени. Или использование каких-нибудь случайных бит. (В данной реализации вектор инициализации основан на позиции блока, что лишь незначительно повышает защиту. К сожалению, в данном случае нет возможности использовать более сложные векторы инициализации).

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

IV не должен храниться в секрете, он может передаваться открыто вместе с шифротекстом.

Причины выбора алгоритма

Для выбора конкретного алгоритма шифрования я обратился к результатам конкурса на создание нового общенационального стандарта шифрования, который должен прийти на замену DES, проведенным в конце 1996г. национальным институтом стандартов США (NIST). Разрабатываемому стандарту было присвоено рабочее наименование AES (Advanced Encryption Standard). Отбор проходил в два этапа, после первого среди претендентов осталось 15 кандидатов, после второго – 5 (Crypton, Mars, RC6, Rijndael и Seipent). В конце 2000 года был сделан окончательный выбор. В качестве предлагаемого стандарта был выбран алгоритм Rijndael. Этот алгоритм был разработан Винсентом Райманом (Vincent Rijman) и Иоан Дамен (Joan Daemen) и представляет собой алгоритм, не использующий сети Фейстела.

Также исходя из документа «Performance Analysis of AES candidates on the 6805 CPU core», в котором приводятся результаты сравнения кандидатов по затратам ресурсов и времени работы, я пришел к выводу, что Rijndael лучше всех остальных подходит к моему заданию, т.к. является самым быстрым и требует наименьший объем ресурсов во время работы.

Также немаловажным было при выборе то, чтобы размер сектора диска (512 байт) был кратен размеру блока алгоритма. Из-за этого условия сразу отсеиваются алгоритмы MARS и RC6. Из оставшихся Serpent оказался слишком медленным (примерно на порядок медленнее средней скорости Rijndael). Crypton оказался медленнее примерно в 3 раза из-за медленного вычисления преобразования числа p, используемого в нем, а также сложнее в реализации.

Исходя из этого, было принято решение об использовании криптографического алгоритма Rijndael.

Алгоритм Rijndael

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

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

В качестве стандарта принят вариант шифра только с размером блока 128 бит (16 байт). Число раундов шифрования определяется в зависимости от размера блока и ключа по следующей таблице:

размер ключа	128	192	256
размер блока	128	192	256
128	10	12	14
192	12	12	14
256	14	14	14

Иными словами, из двух размеров выбирается максимальный, и если он равен 128 бит, то используется 10 раундов, если 192 бита, то 12, и если 256 - то 14 раундов шифрования.

В данном продукте решено использовать стандартный размер блока в 128 бит и размер ключа в 256 бит, как наиболее стойкий вариант. Следовательно, будет 14 раундов шифрования.

Шифр Rijndael выполнен в архитектуре "Квадрат" (Square), получившей свое название от первого, построенного в соответствии с ее принципами, криптоалгоритма. В Rijndael блоки открытых и шифрованных данных, соответственно T и T', представляются в виде массивов из 16, 24 или 32 байтов:

T = (t₁, t₂,...,t_N)

T' = (t'₁, t'₂,...,t'_N)

| t | = | t' | = 8, N {16, 24, 32}.

В соответствии с использованными архитектурными принципами в ходе криптографических преобразований исходный и зашифрованный блоки данных, а также все промежуточные результаты процесса шифрования интерпретируются как матрицы байтов размером 4´n, откуда получаем n = N/4, nÎ{4, 6, 8}. Матрицы заполняются байтами входного блока (открытых данных при шифровании и шифрованных данных при дешифрации соответственно) по столбцам сверху вниз и слева направо, и в точно таком же порядке извлекаются байты из матрицы-результата:

Схема преобразования данных при шифровании:

Схема алгоритма шифрования:

На рисунках использованы следующие обозначения:

T, T' - открытый и зашифрованный блоки данных соответственно;

k_i - i-тый ключевой элемент;

F, F' - регулярное нелинейное преобразование и преобразование последнего раунда соответственно;

X_i - промежуточное состояние шифруемого блока после прибавления i-того ключевого элемента.

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

T' = E_K(T) = k_R₊₁ F'(k_R F(k_R_-1 ... F(k₂ F(k₁ T))...)).

Число R раундов шифрования переменное и зависит от размера блока данных и ключа. Прибавление ключевых элементов, которым начинается и заканчивается процесс шифрования, а также некоторые другие операции раундового преобразования выполняется побайтно в конечном поле Галуа GF(2⁸), полевой операцией сложения в нем является побитовое суммирование по модулю 2. Соответственно, каждый ключевой элемент является байтовой матрицей того же самого размера, что и блок данных. За один раунд шифрования преобразуется полный блок данных, а не его часть, как в сетях Файстеля. На последнем раунде функция нелинейного преобразования отличается от аналогичной функции, используемой в остальных раундах - это сделано для обеспечения алгоритмической эквивалентности прямого и обратного преобразований шифрования.

Процесс дешифрации блока данных алгоритмически идентичен процессу его шифрования и, следовательно, рисунки 1 и 2 также справедливы и для него, если через T обозначить блок зашифрованных данных, а через T' - открытых. Однако различия между этими двумя процедурами в архитектуре "Квадрат" несколько более существенны, чем в сетях Файстеля - они различаются не только порядком использования ключевых элементов в раундах шифрования, но и самими этими элементами, и некоторыми другими константами, используемыми в алгоритме.

Нелинейное преобразование F матрицы данных состоит из трех шагов: замены байтов матрицы на новые значения (S[]), циклического сдвига строк матрицы влево (R), умножения матрицы данных слева на постоянную матрицу-циркулянт M:

X' = F(X) = M´ R(S(X)).

Схема преобразования блока данных при нелинейном преобразовании:

Схема алгоритма нелинейного преобразования:

Все входные (X), выходные (X') и промежуточные (Y, Z) значения преобразования являются матрицами байтов одинакового размера 4´n. Функция преобразования последнего раунда F' отличается от регулярной функции преобразования F отсутствием шага умножения матрицы данных слева на постоянную матрицу.

Вся нелинейность преобразования сосредоточена в его первом шаге - замене, второй и третий шаги являются линейными. Первый шаг служит для перемешивания информации внутри байтов, второй обеспечивает "экспорт" изменений в другие столбцы, третий осуществляет диффузию изменений в одном элементе матрицы на весь соответствующий столбец. Таким образом, за два раунда достигается диффузия изменений в одном единственном бите на весь блок данных. Ниже каждый из указанных шагов рассмотрен подробно, при этом некоторые преобразования байтов определены в терминах операций в конечном поле GF(2⁸), порожденном неприводимым полиномом m(x) над полем GF(2): m(x) = x⁸+x⁴+x³+x+1. Операция сложения в этом поле является ни чем иным, как побитовым суммированием по модулю 2, умножение в соответствие с определением поля выполняется как обычное умножение полиномов над GF(2) по модулю полинома m(x). При манипулировании с байтами данных как с элементами поля GF(2⁸) каждый бит соответствует слагаемому вида xⁱ в соответствии со старшинством бита в байте. Можно сказать, что если байт с целочисленным значением b представлен в виде полинома B(x), то справедливо b = B(2).

Побайтовая замена

В ходе побайтовой замены каждый байт матрицы данных заменяется на новое значение того же размера, индексируя общий для всех байтов вектор замен S 8-в-8 бит:

y_ij = S[x_ij], 1£i£4, 1£j£n,

где n - число столбцов матрицы данных - 4,6 или 8. Единственный узел замен в шифре Rijndael конструируется с помощью следующего алгебраического соотношения:

S[y] = (x⁴+x³+x²+x+1) + y^-1 (x⁷+x⁶+x⁵+x⁴+1) mod (x⁸+1).

При этом обращение ненулевых байтов осуществляется в описанном выше конечном поле GF(2⁸), для нулевого байта полагают 0^-1 = 0. Таким образом, байтовая замена определяется как обращение элемента-байта в конечном поле GF(2⁸), доопределенное для нулевого элемента поля, с последующим аффинным преобразованием результата. Коэффициенты этого преобразования выбраны таким образом, чтоб у полученного узла замен отсутствовали точки неподвижности (S[y] = y), и "антинеподвижности" (S[y] = ~y). Тильдой (знаком "~") обозначена операция побитового дополнения своего аргумента.

Естественно, указанная выше формула для построения узла замен не предназначена для использования непосредственно во время шифрования - гораздо эффективнее использовать уже готовый узел замен:

Заменяющее значение выбирается на пересечении строки, определяемой старшей 16-ричной цифрой заменяемого значения, и столбца, определяемого его младшей цифрой.

Построчное вращение матрицы

В ходе данной операции каждая строка матрицы данных, кроме первой, вращается (циклически сдвигается) влево на определенное число позиций, зависящее от номера строки и от размера блока данных:

, 1£i£4, 1£j£n.

Первая строка всегда остается на месте: С₁ = 0, для нее приведенная выше формула существенно упрощается: z_1j = y_1j. Ниже в таблице приведены величины сдвига для строк матрицы со второй по четвертую в зависимости от числа столбцов n в матрице:

n	4	6	8
C₂	1	1	1
C₃	2	2	3
C₄	3	3	4

Умножение на постоянную матрицу

На этом шаге матрица данных слева умножается на постоянную матрицу-циркулянт M:

X = M´X,

При выполнении матричного умножения операции сложения и умножения элементов обеих матриц выполняются в конечном поле GF(2⁸). Матрица M является циркулянтом: каждая ее строка получается циклическим сдвигом предыдущей строки вправо на один элемент. Элементы матрицы выбраны таким образом, чтобы свести к минимуму трудоемкость операции умножения: в ней присутствуют лишь небольшие по значению числа 01, 02 и 03, половина элементов - единичные, т.е. реального умножения выполнять для них не требуется. Этим самым обеспечивается высокая эффективность возможных реализаций этой операции.

Следует добавить, что операция умножения в конечном поле GF(2⁸) является достаточно трудоемкой в программной реализации и никаким образом не сводится к обычному арифметическому умножению. Если умножение двоичных чисел реализуется сдвигами и обычным арифметическим суммированием, то умножение полиномов над полем GF(2) - теми же сдвигами и побитовым суммированием по модулю 2. Однако в шифре Rijndael одним из множителей всегда является константа и размер операндов невелик - один байт. Это позволяет реализовать умножение на константу в поле GF(2⁸) как замену, что существенно повышает эффективность программной реализации. Для каждого множителя-константы при этом требуется свой отдельный узел замен. Напротив, наиболее эффективной аппаратной реализацией этой операции является реализация в виде серии сдвигов и побитовых сложений по модулю два в соответствие с ее непосредственным определением.

Дешифрация

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

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

k₁, k₂, k₃, ... , k_R, k_R₊₁,

то при дешифрации должна быть использована следующая последовательность элементов:

k_R₊₁, M ^-1 k_R, ... , M ^-1 k₃, M ^-1 k₂, k₁.

2. На шаге побайтовой замены используется узел замен S^-1 обратный тому, что применяется в процедуре шифрования S. Это означает, что каково бы ни было байтовое значение b, всегда справедливо следующее соотношение:

S ^-1[S[b]] = b.

Указанный узел замен S^-1 представлен в следующей таблице:

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

Сi' = n - Ci, 2£i£4.

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

n	4	6	8
C₂’	3	5	7
C₃’	2	4	5
C₄’	1	3	4

На шаге умножения слева на постоянную матрицу используется матрица M ^-1, обратная используемой при шифровании матрице M:

Следует отметить, что умножение в конечном поле GF(2⁸) на элементы матрицы M ^-1 с точки зрения вычислительных затрат является более трудоемкой операцией, чем умножение на элементы матрицы M. Кроме того, в обратной матрице присутствуют четыре различных элемента, тогда как в исходной - только три, что позволяло "сэкономить" одно умножение из четырех. Все сказанное приводит к тому, что при непосредственной реализации умножения в поле GF(2⁸) модули дешифрования получаются заметно менее быстродействующими, чем модули шифрования. Однако, эта особенность не является настолько существенной, как может показаться на первый взгляд. Во-первых, в большинстве практических режимов использования шифра применяется только прямое преобразование (шифрование) - подобная ситуация имеет место при шифровании с использованием потоковых режимов (в том числе и при дешифрации), при выработке имитовставки (кода аутентификации), при выработке хэш-функции и при выработке массивов псевдослучайных данных. Во вторых, если умножение на константу в поле GF(2⁸) реализовать как замену, различия в трудоемкости нивелируются.

Конструкторская часть

Функциональное назначение

Данный программный продукт представляет собой приложение, написанное на языке программирования Assembler в среде программирования RadAsm, а также применением следующих вспомогательных программ: OllyDbg, DebugView, VMware Workstation и Restorator.

Руководство программиста

3.2.1. Структура программы

Программный продукт состоит из следующих частей:

- \Driver\*.* – файлы исходных кодов драйвера;

- \Driver\ACVHDD.asm – главный модуль драйвера;

- \Driver\dispatch.asm – модуль обработки IRP-запросов к драйверу;

- \Driver\consts.inc – объявление типов и констант;

- \Driver\proto.inc – прототипы реализованных функций;

- \Driver\seh0.inc – макросы для SEH (модуль написан Four-F);

- \Driver\ACVHDD.rap – файл проекта RadASM;

- \Driver\acvhdd.sys – сам драйвер;

- \Driver\AES\ – файлы части драйвера, реализующие шифрование;

- \Driver\AES\AESCrypt.inc – функции шифрования верхнего уровня (инициализация, шифрование и дешифрация целого буфера);

- \Driver\AES\boxes-fst.inc – таблицы перестановок;

- \Driver\AES\consts.inc – объявление констант и структур;

- \Driver\AES\EncodeDecode.inc – функции шифрования и дешифрации блоков по 16 байт, а также вспомогательные по отношению к ним функции;

- \Driver\AES\usefull_functions.inc – вспомогательные функции и макросы;

- \Loader\*.* – файлы исходных кодов загрузчика и оболочки;

- \Loader\Loader.asm – основной модуль загрузчика;

- \Loader\DelImageDlg.inc – диалог удаления файла образа;

- \Loader\DriverService.inc – функции взаимодействия с драйвером;

- \Loader\MainWndProc.inc – главная оконная функция;

- \Loader\NewImageDlg.inc – диалог создания нового образа диска;

- \Loader\PasswordDlg.inc – диалоговое окно ввода пароля при монтировании файла образа новым виртуальным логическим диском в систему;

- \Loader\TrayIcon.inc – модуль реализации иконки в трее;

- \Loader\Loader.rc – список подключаемых ресурсов;

- \Loader\Loader.rap – файл проекта RadASM;

- \Loader\Loader.exe – сам загрузчик;

- \Loader\Icons\*.ico – иконки, используемые в загрузчике;

- \Loader\Res\*.* – файлы ресурсов используемых в загрузчике;

- \Loader\Res\XPMan.manifest – манифест для программы;

- \Loader\Res\DialogForms.rc – ресурсы диалоговых окон;

- \Loader\Res\LoaderRes.rc – иконки, добавляемые в ресурсы;

- \Loader\Res\XPMan.rc – подключение к проекту манифеста.

3.2.2. Структура данных

Для реализации программного продукта кроме стандартных заголовочных файлов необходимы файлы из KmdKit (Kernel Mode Driver Development Kit for MASM32 programmers) от Four-F, являющийся переработкой заголовочный файлов из DDK. Без них совершенно невозможна компиляция драйвера, а также компиляция нескольких модулей загрузчика.

3.2.3. Средства обмена данными

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

Система взаимодействует с драйвером через диспетчер ввода-вывода (Input/Output Manager), а загрузчик – через функции диспетчера управления службами (Service Control Manager, SCM).

3.2.4. Алгоритм работы программы

Общий принцип работы программного приложения следующий:

После запуска приложения-загрузчика Loader.exe сначала проверяется, а не запущена ли уже эта программа на данной машине. Для этого с помощью функции CreateFileMapping в виртуальной памяти создается блок, имеющий уникальное имя. В случае ошибки, т.е. наличия другой запущенной копии, выводится сообщение об ошибке и работа приложения завершается. Первая копия в конце своей работы освобождает выделенный блок памяти вызовом CloseHandle.

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

При создании окна функцией AC_TrayIconCreate создается иконка в трее, затем с помощью функции AC_FindDriverInMem осуществляется поиск драйвера в памяти. Если драйвер загружен, то вызов AC_GetUsedDriveLetter возвращает букву диска, с которой связан драйвер. Затем в зависимости от состояния драйвера функция AC_TrayIconMenuItemsCheckState меняет иконку в трее и доступность пунктов контекстного меню, информируя пользователя о состоянии драйвера.

При закрытии окна функцией AC_TrayIconDelete иконка в трее удаляется.

Сообщения, приходящие от иконки в трее, обрабатываются вызовами функций AC_TrayIconWndProc_WM_COMMAND и AC_TrayIconWndProc_WM_TRAY, где первая обрабатывает выбор пунктов меню пользователем, а вторая вызывает, при необходимости, контекстное меню.

При выборе пункта «Загрузить образ диска» вызывается функция AC_Cmd_LoadDriver, производящая загрузку драйвера и монтирование образа на создаваемый файл. После того, как функция отработает, вызывается AC_TrayIconMenuItemsCheckState.

При выборе пункта «Выгрузить диск» сначала вызывается AC_Cmd_UnloadDriver, выгружающая образ, драйвер и удаляющая диск, затем вызывается AC_TrayIconMenuItemsCheckState.

При выборе пункта «Создать образ диска» вызывается единственная функция NewImageDlgShow, описанная в модуле NewImageDlg.inc и реализующая весь процесс создания нового файла образа диска.

При выборе пункта «Удалить образ диска» также вызывается единственная функция DelImageDlgShow, внутри которой происходит весь процесс удаления существующего файла образа диска.

Алгоритм загрузки образа реализован внутри функции AC_Cmd_LoadDriver, и состоит из следующего: первоначально с помощью функции AC_FindDriverInMem осуществляется поиск драйвера в памяти и, если он работает, выводится сообщение о невозможности загрузки нового образа без предварительной выгрузки старого, после чего происходит прерывание функции загрузки образа. Иначе вызов AC_RegisterService загружает драйвер в память, а функция AC_StartService монтирует диск из файла, путь к которому передан ей в качестве параметра.

Выгрузка образа реализована в функции AC_Cmd_UnloadDriver следующим образом: сначала драйвер ищется вызовом AC_FindDriverInMem. Если он не найден, то выводится соответствующее сообщение и выгрузка на этом завершается. Иначе в функции AC_StopService производится выгрузка образа и удаление диска, затем вызов AC_DeleteService удаляет из памяти сам драйвер.

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

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

3.2.5. Описание основных функций программы

Описание функций дано в порядке вхождения модулей, в которых те описаны, в список файлов проектов.

Программа загрузчик (Loader.exe):

ProcessMessages proc hWnd:DWORD

Обработка всех сообщений из очереди для данного окна;

DelImageDlgWndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Диалоговая оконная функция диалога удаления файла;

DelImageDlgShow proc

Вызов диалогового окна удаления файла;

AC_ErrorMessage proc error:DWORD

Вывод системной информации о произошедшей ошибке;

AC_FindDriverInMem proc

Поиск драйвера в памяти и получение его состояния;

AC_RegisterService proc

Загрузка драйвера в память;

AC_StartService proc lpFileName:DWORD

Загрузка образа из указанного файла и создание диска;

AC_StopService proc

Выгрузка образа и удаление диска;

AC_DeleteService proc

Выгрузка драйвера из памяти;

AC_CreateNewImage proc imgsize:DWORD, imgpath:DWORD

Процесс создания нового файла образа диска;

AC_Cmd_LoadDriver proc lpFileName:DWORD

Интерфейс загрузки существующего файла образа диска;

AC_Cmd_UnloadDriver proc

Интерфейс выгрузки драйвера из памяти;

AC_GetUsedDriveLetter proc

Поиск логического диска, с которым связан загруженный драйвер;

WinMain proc hInst:HINSTANCE, hPrevInst:HINSTANCE, CmdLine:LPSTR, CmdShow:DWORD

Создание и поддержка главного окна приложения;

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Оконная функция главного окна приложения;

_SaveFileDialog_ proc lpTitle:DWORD, lpFilter:DWORD, lpDefExt:DWORD

Вызов системного диалога выбора файла;

SwapButtonsEnabling proc hOwnerDlgWnd:DWORD

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

NewImageDlgWndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Оконная функция диалогового окна, в котором создается новый файл образа диска;

NewImageDlgShow proc

Создание диалогового окна, в котором создается новый файл образа диска;

FillDriveLetters proc hWndComboBox:DWORD

Заполнение всплывающего списка выбора (ComboBox) буквами дисков, не зарегистрированных в системе;

PasswordDlgWndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Оконная функция ввода пароля;

PasswordDlgShow proc

Создание диалогового окна ввода пароля;

AC_TrayIconCreate proc

Создание иконки в трее и контекстного меню для нее;

AC_TrayIconDelete proc

Удаление иконки приложения из трея;

AC_TrayIconChange proc hNewIcon:DWORD

Изменение изображения у иконки приложения в трее;

AC_TrayIconWndProc_WM_TRAY proc wParam:DWORD, lParam:DWORD

Функция обработки сообщений от иконки в трее, которые система посылает главной оконной функции приложения;

AC_TrayIconWndProc_WM_COMMAND proc wParam:DWORD, lParam:DWORD

Функция обработки сообщений от пунктов контекстного меню;

AC_TrayIconMenuItemsCheckState proc

Функция меняет доступность пунктов меню и изображения иконки в трее в зависимости от текущего состояния драйвера.

Драйвер устройства (ACVHDD.SYS):

AC_OpenFileDrive proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

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

AC_CloseFileDrive proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

Освобождение выделенных ресурсов, закрытие файла образа, завершение работы системы шифрования;

AC_DriverUnload proc pDriverObject : PDRIVER_OBJECT

Функция вызывается при выгрузке драйвера и освобождает все выделенные ресурсы;

AC_DriverEntry proc pDriverObject : PDRIVER_OBJECT, pusRegistryPath : PUNICODE_STRING

Точка входа при первоначальной загрузке драйвера. Создает само устройство, инициализирует мютекс, а также устанавливает обработчики в DRIVER_OBJECT на системные запросы IRP_MJ_ xxx;

InitAES proc passwrd:DWORD

Инициализация системы шифрования по заданному паролю;

DoneAES proc

Завершение работы системы шифрования;

EncodeBuffer proc src:DWORD, dst:DWORD, block_count:DWORD

Шифрование буфера src длиной block_count 16 байтных блоков с записью результатат в dst;

DecodeBuffer proc src:DWORD, dst:DWORD, block_count:DWORD

Дешифровка буфера src длиной block_count 16 байтных блоков с записью результате в dst;

b_SetUp_Encode proc

Внутренняя функция, используемая при шифровании;

b_SetUp_Decode proc

Внутренняя функция, используемая при десшифрации;

rijndaelEncrypt proc a:DWORD, b:DWORD, rk:DWORD

Шифрование 16 байтного блока a с записью результата в b на основе ключей раундов rk;

rijndaelDecrypt proc a:DWORD, b:DWORD, rk:DWORD

Дешифровка 16 байтного блока a с записью результата в b на основе ключей раундов rk;

my_strncpy proc dst:DWORD, src:DWORD, maxlen:DWORD

Функция копирования нультерминальной строки. Аналог C/C++ функции strncpy;

copy_block proc dst:DWORD, src:DWORD

Функция копирования 16 байтного блока src в dst;

StrLen proc item:DWORD

Функция быстрого вычисления длины строки. Аналог C/C++ функции strlen;

populateKeyMaterial proc text:DWORD, key:DWORD

Расширение пароля text до заполнения длины ключа key;

InvMixColumn proc a:DWORD

Специальное перемешивание байт массива a;

rijndaelKeySched proc k:DWORD, W:DWORD

Формирование ключа шифрования по расширенному паролю;

rijndaelKeyEnctoDec proc keyBits:DWORD, W:DWORD

Формирования ключа дешифрации из ключа шифрования;

makeKey proc key:DWORD, direction:DWORD, keyLen:DWORD, keyMaterial:DWORD

Формирование ключа шифрования/дешифрования на основе пароля key, требуемому направлению шифрования direction, длины ключа keyLen и начального материала для формирования ключа keyMaterial;

MmGetSystemAddressForMdlSafe proc pMdl:PMDL, Priority:DWORD

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

AC_DispatchReadWrite proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

Функция – обработчик запросов системы на чтение/запись с устройства – диска; производит чтение / запись с соответствующим шифрованием / дешифрованием;

AC_DispatchCreate proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

Обработка инициализации драйвера в системе;

AC_DispatchClose proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

Обработка выгрузки драйвера;

AC_LoadKeyAndInitAES proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

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

AC_DispatchControl proc pDeviceObject : PDEVICE_OBJECT, pIrp : PIRP

Функция обработки всех приходящих драйверу сообщений от системы;

Технологическая часть

Дата: 2019-05-28, просмотров: 201.

⇐ Предыдущая 1 234 Следующая ⇒