Разработка программы защиты графических файлов

Название работы: Разработка программы защиты графических файлов

Скачать демоверсию

Тип работы:

Дипломная

Предмет:

Информационное обеспечение, программирование

Страниц:

90 стр.

Год сдачи:

2009 г.

Содержание:

СОДЕРЖАНИЕ

Особенности архитектуры сетевой защиты. Состав и назначение функциональных блоков. Архитектура сетевой системы защиты.

Распределенная архитектура системы защиты

Централизованная архитектура системы защиты.

Централизованно-распределенная архитектура системы защиты.

Структура сетевой системы защиты в рамках централизованно-распределенной архитектуры.

Формат представления графических изображений версия 87а(89a).

Кодировщик.

Декодировщик.

Таблицы цветов.

Основные и дополнительные блоки, а также границы их действия.

Размер блока.

Использование формата GIF в составе более общего протокола.

Субблоки данных.

Блок-терминатор.

Заголовок.

Дескриптор логического экрана.

Глобальная таблица цветов.

Дескриптор изображения.

Локальная таблица цветов.

Кодирование изображений методом таблиц.

Дополнительный блок управления изображением.

Дополнительный блок комментария.

Дополнительный блок с простым текстом.

Дополнительный блок приложений.

Завершающий блок.

Грамматика формата GIF.

Грамматика.

Передача изображений в режиме on - line.

Запрос ресурсов GIF.

Сообщение о ресурсах GIF.

Запуск графического режима GIF.

Внешние условия взаимодействия программ.

Выдержка:

Диспетчер доступа.

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

Общие положения и принятые обозначения

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

Очевидно, что полнота модели диспетчера доступа определяется тем, для всех ли субъектов и объектов доступа реализованы разграничения. То есть, присутствуют ли в системе явные каналы несанкционированного взаи¬модействия субъектов доступа или нет.

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

Введем следующие обозначения:

1. Множество субъектов доступа.

• Пользователи. Обозначим через Р множество возможных пользовате¬лей в системе. Выделим три класса пользователей — возможных эле¬ментов множества Р:

Ра - администратор;

Рп - пользователь, решающий прикладные задачи, соответ¬ственно,

Рпn — n-й пользователь;

Рс - пользователь «система» — виртуальный пользователь ОС.

• Процессы. Обозначим через Q множество возможных процессов в системе. Выделим четыре класса процессов — возможных элементов множества Q:

Qc - системные (привилегированные) процессы;

Qп - прикладные процессы;

Qск - скрытые или неидентифицируемые (процессы виртуальных машин).

2. Множество объектов доступа.

• Файловые объекты данных. Обозначим через F множество возможных файловых объектов данных в системе. Выделим три класса объек¬тов — возможных элементов множества F:

Fc - системные каталоги и файлы, каталоги и файлы настро¬ек ОС;

Fп - пользовательские каталоги и файлы данных, включая сетевые (в сети Microsoft — разделяемые сетевые ресур¬сы по протоколу Net Bios);

Fo - неразделяемые системой и приложениями для пользо¬вателей каталоги и файлы (TEMP и т.д. для ОС семей¬ства Windows).

• Файловые объекты программ (исполняемые файлы). Обозначим через S множество возможных файловых объектов программ. Выделим два класса объектов — возможных элементов множества S:

Sc системные исполняемые файлы привилегированных про¬цессов — системных процессов ОС и процессов защиты;

В приложении 12-lb на Рабочий стол Windows выводится главное окно приложения со строкой текста. Вывод в окно текста потребовал ввести в оконную функцию обработку сообщения WM_PAINT. Поскольку главное окно сделано светло-серым, перед выводом текста в функции OnPaint() устанавливается режим прозрачного фона.

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

В программе 12-1а, по команде пользователя выполняется запуск дочернего процесса. В целом эта программа тоже имеет стандартный вид.

В ней функция CreateProcessQ является функцией запуска (создания) дочернего процесса.

//Программа 12-1а. Запуск дочернего процесса

//Файл 12-1a.h

#define MI_NEW 100

#define MI_EXIT 101

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);

void OnCommand (HWND, int, HWND, UINT);

void OnDestroy (HWND);

//Файл 12-1a.rc

#include "12-1a.h"

Main MENU{

POPUP "Файл"{

MENUITEM "Запуск процесса", МI_NEW // Пункт меню для запуска процесса

MENUITEM SEPARATOR

MENUITEM "Выход", MI_EXIT

Похожие работы на данную тему