|
Dr. Web
|
AVG
|
Avast!
|
Kaspersky
|
NOD32
|
|
Вредоносные
сайты %
|
100
|
99
|
100
|
100
|
99
|
|
Вредоносные
ссылки %
|
98
|
100
|
97
|
99
|
100
|
|
Вредоносные
файлы %
|
100
|
100
|
100
|
100
|
99
|
|
Подозрительные
действия %
|
98
|
99
|
97
|
97
|
99
|
|
Попытка спама %
|
99
|
98
|
100
|
97
|
100
|
|
Попытка фишинга
%
|
100
|
100
|
100
|
100
|
100
|
|
Ложная тревога
|
1 раз
|
1 раз
|
2 раза
|
0 раз
|
0 раз
|
Как видно, не было показано практически ни
одного неудовлетворительного результата. Эти антивирусы действительно стоят
своих денег. Однако стоит отметить несколько фактов:
ü Dr. Web требует
некоторого количества времени для проверки сайта, т.к. он обращается к своим
«облачным» базам данных.
ü Kaspersky поглощает очень
много ресурсов при проверке.
ü AVG тщательно проверяет
ссылки, на которые вы хотите попасть, но нужно дать ему времени для того, чтобы
он просканировал ссылку и выдал результат.
ü Avast! и NOD32 показали
во всем средние показатели по скорости и их особо нельзя отметить ни в чем, но
и упрекнуть не в чем.
По результатам теста можно сказать, что
явных «фаворитов» нет. Все антивирусы достаточно хорошо справляются с
поставленными перед ними задачами. Каждому пользователю больше импонирует тот
из антивирусов, который больше всего подходил по характеристикам, интерфейсу и
принципам работы именно для этого человека. Определить какой-то один было
невозможно.
Если сравнивать данные продукты с
разрабатываемой в дипломном проекте программой, можно сказать что у антивирусов
функциональный набор гораздо шире. Однако мало какие антивирусы умеют выделять
новые, не имеющиеся в базе данных сигнатуры.
2. Проектирование системы
2.1 Выбор ОС
Без операционной системы невозможно
запустить какую-либо прикладную программу, например текстовый редактор. Поэтому
ОС - это база, под которую разрабатываются различные приложения.
Другими словами ОС - программа,
управляющая компьютером, запускающая все другие программы и выполняющая для них
различные сервисные функции.
Операционная система (оболочка) Windows -
это разработанная фирмой Microsoft надстройка над операционной системой DOS,
обеспечивающая большое количество возможностей и удобств для пользователей и
программистов. Широчайшее распространение Windows сделало ее фактическим
стандартом для IBM PC - совместимых компьютеров. Подавляющее большинство
пользователей таких компьютеров работают в Windows, поэтому практически все
новые программы стали разрабатываться именно для эксплуатации в среде Windows.
Из-за такой большой популярности данной
операционной системы помимо огранного количества программ написанных для неё,
также существует огромное количество вирусов. Поэтому можно сказать, что
изучение вирусов на данной операционной системе является делом наиболее
полезным а также эффективным.
.2 Выбор среды и языка
разработки
В качестве языка разработки был выбран C#. C# является языком
программирования, который разработан для создания множества приложений,
работающих в среде.NET Framework. Язык C# прост, типобезопасен и
объектно-ориентирован. Благодаря множеству нововведений C# обеспечивает
возможность быстрой разработки приложений, но при этом сохраняет
выразительность и элегантность, присущую С-подобным языкам.
В качестве среды разработки была выбрана
среда Microsoft Visual Studio. Visual Studio - это полный набор инструментов и
служб для создания различных приложений как для платформы Microsoft, так и для
других платформ. Visual Studio также позволяет связать все ваши проекты, группы
и всех заинтересованных лиц. Теперь ваша группа сможет работать более гибко
практически где угодно независимо от используемого средства разработки (в том
числе Eclipse и Xcode). Вы сможете разрабатывать важные приложения.NET, писать
невероятно быстрый код с помощью C++ AMP или тестировать и отлаживать облачное
приложение на HTML или JavaScript, которое работает на множестве устройств -
присоединитесь к миллионам разработчиков во всем мире, которые выбрали Visual
Studio как основную среду разработки.C# является реализацией языка C#
корпорации Microsoft. Поддержка Visual C# в Visual Studio реализована в виде
полнофункционального редактора кода, компилятора, шаблонов проектов,
конструкторов, мастеров кода, мощного и удобного отладчика и многих других
средств. Библиотека классов.NET Framework предоставляет доступ ко многим
службам операционной системы и к другим полезным, хорошо спроектированным
классам, что существенно ускоряет цикл разработки.
2.3 Структура PE файла
Общее описание PE файла
Для решения широкого круга программистских
задач требуется знание внутренней структуры исполняемых файлов и представление
о том, как они загружаются в память.
Во всех 32-разрядных ветках ОС Windows
объектные (.OBJ), библиотечные (.LIB) и исполняемые (.EXE и.DLL) файлы хранятся
в едином формате COFF (Common Object File Format), который используется
некоторыми системами семейства Unix и ОС VMS.
Формат PE (Portable Executable) является
специализацией COFF для хранения исполняемых модулей. Он был стандартизован
Tool Interface Standard Committee (Microsoft, Intel, IBM, Borland, Watcom и
др.) в 1993 г., а затем понемногу обновлялся (последнее известное мне
обновление было проведено в феврале 1999 г., но оно не учитывает поддержки
метаданных для.NET, добавленной в 2000 г.). Название Portable Executable
связано с тем, что данный формат не зависит от архитектуры процессора, для
которого построен исполняемый файл.
На сегодняшний день существует два формата
PE-файлов: PE32 и PE32+. Оба они ограничивают адресное пространство программы
размеров в 4 Гб (0xFFFFFFFF), но PE32 использует 32-битовые адреса (архитектура
Win32), а PE32+ - 64-битовые адреса (архитектура Win64).
Большинство описанных ниже структур и
констант содержатся в стандартном заголовочном файле Windows WINNT.H.
Любой PE-файл состоит из нескольких
заголовков и нескольких (от 1 до 96) секций. Заголовки содержат служебную
информацию, описывающую различные свойства исполняемого файла и его структуру.
Секции содержат данные, которые размещаются в адресном пространстве процесса во
время загрузки исполняемого файла в память.файлы являются файлами с
относительной загрузкой, т.е. теоретически могут размещаться в пространстве
адресов 0x00000000 - 0xFFFFFFFF с любого адреса, называемого базовым адресом.
Поскольку базовый адрес заранее неизвестен, структура PE-файлов основана на
понятия RVA (relative virtual address, относительный виртуальный адрес). RVA представляет
собой смещение от базового адреса исполняемого файла до данного адреса. Иными
словами, для получения линейного адреса в виртуальной памяти процесса нужно
сложить RVA с базовым адресом.
Следует особо подчеркуть, что RVA не имеют
ничего общего общего со смещениями относительно начала файла. В процессе
загрузки файла каждая его секция размещается в памяти со своего RVA и при
необходимости дополняется нулями до заданного размера. При этом RVA секции и ее
размер в памяти, вообще говоря, никак не связаны с ее местоположением и
размером в исходном файле.
Общая структура PE-файла представлена в
таблице 2.1:
Таблица 2.1 - Структура ре файла
|
Заголвок DOS
|
|
Заглушка DOS
|
|
Заголовок PE
|
|
Заголовки
секций
|
|
Секции
|
Подробно каждая из этих структур описана
ниже.
Общее описание заголовка
и заглушки DOS
Поскольку и приложения DOS, и приложения
Windows имеют расширение.EXE, все исполняемые файлы Windows используют схему
двойной загрузки. Она состоит в том, что файл начинается с заголовка DOS, за
которым следует заглушка (stub), т.е. небольшой EXE-файл формата DOS. При
попытке загрузить файл из DOS'а исполняется заглушка, а при загрузке файла из
Windows загрузчик анализирует заголовок DOS и извлекает из него смещение до
настоящего заголовка исполняемого файла.
ü Структура заголовка DOS
называется IMAGE_DOS_HEADER. Я не буду полностью описывать заголовок DOS, т.к.
нас интересуют в нем только два поля, а именно:
ü 2-байтовая (WORD)
сигнатура, находящаяся по смещению 0 (e_magic) и равная «MZ» (IMAGE_DOS_SIGNATURE);
При загрузке PE-файла сначала нужно
проверить сигнатуру DOS, затем найти смещение до заголовка PE, а затем
проверить сигнатуру PE, расположенную в начале его заголовка. Эта сигнатура
состоит из 4 байтов и равна «PE\0\0» (обозначение IMAGE_NT_SIGNATURE).
Такую же схему двойной загрузки используют
и другие файлы (исполняемые файлы Win16 и OS/2 и VxD-драйверы Windows 9x),
поэтому проверка правильности сигнатуры PE обязательна.
Обычно заглушка DOS выводит на экран
сообщение типа «Эта программа требует Microsoft Windows» и заканчивает работу.
Однако при сборке программы мы можем указать в командной строке сборщика любой
EXE-файл DOS в качестве заглушки. Это позволяет создавать «дуальные» программы,
работающие и в DOS, и в Windows.
Сруктура DOS заголовка
typedef struct _IMAGE_DOS_HEADER { // DOS.EXE заголовокe_magic; //
Магическое числоe_cblp; // Количество байт на последней странице файлаe_cp; //
Количество страниц в файлеe_crlc; // Relocationse_cparhdr; // Размер заголовка
в параграфах
USHORT e_minalloc; //
Minimum extra paragraphs needede_maxalloc; // Maximum extra paragraphs needed
USHORT e_ss; // Начальное (относительное)
значение регистра SSe_sp; // Начальное значение регистра SPe_csum; //
Контрольная суммаe_ip; // Начальное значение регистра IPe_cs; // Начальное
(относительное) значение регистра CSe_lfarlc; // Адрес в файле на таблицу
переадресацииe_ovno; // Количество оверлеевe_res[4]; // Зарезервировано
USHORT e_oemid; // OEM
identifier (for e_oeminfo)e_oeminfo; // OEM information; e_oemid specifice_res2
[10]; // Зарезервированоe_lfanew; // Адрес в файле нового.exe-заголовка
} IMAGE_DOS_HEADER,
*PIMAGE_DOS_HEADER;
Самым важным здесь является поле e_lfanew,
которое содержит 4-байтовое смещение от начала файла до PE-заголовка. Первое
поле структуры e_magic содержит сигнатуру исполняемого файла. Все
MS-DOS-совместимые исполняемые файлы имеют сигнатуру 0x54AD, которая в
ASCII-символах представлена двумя символами MZ. По этой причине заголовок DOS
часто называют MZ-заголовком.
Структура PE заголовка
Заголовок PE (IMAGE_NT_HEADERS) состоит из
трех частей (см. Таблицу 2.2):
Таблица 2.2 - Структура заголовка
|
Сигнатура
|
|
Заголовок файла
|
|
Необязательный
заголовок
|
struct IMAGE_NT_HEADERS {
DWORD
Signature;_FILE_HEADER FileHeader;_OPTIONAL_HEADER OptionalHeader;
};
Заголовок PE всегда начинается с
4-байтовой сигнатуры «PE\0\0» (IMAGE_NT_SIGNATURE). За ней следуют два
заголовка: заголовок файла (IMAGE_FILE_HEADER) и необязательный заголовок
(IMAGE_OPTIONAL_HEADER). Несмотря на свое название, IMAGE_OPTIONAL_HEADER
присутствует в PE-файле всегда (необязательным он является с точки зрения
общего формата COFF, поскольку не используется в объектных и библиотечных
файлах).
Заголовок файла
Заголовок файла состоит из 0x14 байтов
(определение IMAGE_SIZEOF_FILE_HEADER), размещается сразу после сигнатуры и
содержит общее описание файла. Он состоит из следующих полей:
Таблица 2.3 - Структура заголовка файла
|
Смещение (hex)
|
Размер
|
Тип
|
Название
|
Описание
|
|
00
|
2
|
WORD
|
Machine
|
Обозначение
процессора.
|
|
02
|
2
|
WORD
|
NumberOfSections
|
Количество
секций в файле.
|
|
04
|
4
|
DWOR
|
TimeDateStamp
|
Дата и время
создания файла.
|
|
08
|
4
|
DWOR
|
PointerToSymbolTable
|
Смещение до
таблицы символов или 0.
|
|
0C
|
4
|
DWOR
|
NumberOfSymbols
|
Количество
элементов в таблице символов.
|
|
10
|
2
|
WORD
|
SizeOfOptionalHeader
|
Размер
необязательного заголовка.
|
|
12
|
2
|
WORD
|
Characteristics
|
Атрибуты файла.
|
Описание назначения полей.
Поле Machine
16-битовое число, которое задает
архитектуру процессора, на которой может выполняться данная программа.
Поле TimeDateStamp
32-битовое число, которое содержит дату и
время создания данного файла. Формат этого поля недокументирован, однако
сборщики Microsoft заносят сюда время как количество секунд от полуночи
01.01.1970 в UTC (т.е. используют юниксовский формат времени, возвращаемого
функцией time языка C). Между прочим, это означает, что текущее состояние
формата PE действительно только до 18.01.2038 г.
Поскольку формат этого поля
недокументирован, некоторые сборщики третьих фирм сохраняют его значение в
других форматах. Это может оказаться важным, т.к. данное поле используется при
динамическом связывании импорта из DLL.
Поля PointerToSymbolTable
и NumberOfSymbols
Согласно стандарту COFF, эти 4-байтовые поля
должны обеспечивать доступ к отладочной информации в файле. Однако все
известные мне сборщики заносят в них нули, а для доступа к отладочной
информации используется иной способ (см. каталог отладочной информации).
Поле SizeOfOptionalHeader
16-битовое число, задающее размер
необязательного заголовка. Оно равно 0xE0 для файлов PE32
(IMAGE_SIZEOF_NT_OPTIONAL32_HEADER) и 0xF0 для файлов PE32+ (IMAGE_SIZEOF_NT_OPTIONAL64_HEADER).
Поле
Characteristics
16-битовое поле флагов, содержащее COFF-атрибуты файла.
Необязательный заголовок
Необязательный заголовок имеет два
различных формата: для PE32 и для PE32+. Соответствующие структуры называются
IMAGE_OPTIONAL_HEADER32 и IMAGE_OPTIONAL_HEADER64. Их поля сведены в Таблице
2.4:
Таблица 2.4 - Структура необязательного
заголовка
|
Смещение (hex,
PE32/PE32+)
|
Размер
(PE32/PE32+)
|
Тип
(PE32/PE32+)
|
Название
|
Описание
|
|
00
|
2
|
WORD
|
Magic
|
Сигнатура
заголовка.
|
|
02
|
1
|
BYTE
|
MajorLinkerVersion
|
Старшая цифра
номера версии сборщика. Загрузчиком не используется.
|
|
03
|
1
|
BYTE
|
MinorLinkerVersion
|
Младшая цифра
номера версии сборщика. Загрузчиком не используется.
|
|
04
|
4
|
DWORD
|
SizeOfCode
|
Сумма размеров
всех секций, содержащих програмный код.
|
|
08
|
4
|
DWORD
|
SizeOfInitializedData
|
Сумма размеров
всех секций, содержащих инициализированные данные.
|
|
0C
|
4
|
DWORD
|
SizeOfUninitializedData
|
Сумма размеров
всех секций, содержащих неинициализированные данные.
|
|
10
|
4
|
DWORD
|
AddressOfEntryPoint
|
RVA точки
запуска программы. Для драйвера - это адрес DriverEntry, для DLL - адрес
DllMain или нуль.
|
|
14
|
4
|
DWORD
|
BaseOfCode
|
RVA начала кода
программы.
|
|
18/-
|
4/0
|
DWORD
|
BaseOfData
|
RVA начала
данных программы. Ненадежное поле, загрузчиком не используется. В PE32+
отсутствует!
|
|
1С/18
|
4/8
|
DWORD/ULONGLONG
|
ImageBase
|
Предпочтительный
базовый адрес программы в памяти, кратный 64 Кб. По умолчанию равен
0x00400000 для EXE-файлов в Windows 9x/NT, 0x00010000 для EXE-файлов в
Windows CE и 0x10000000 для DLL. Загрузка программы с этого адреса позволяет
обойтись без настройки адресов.
|
|
20
|
4
|
DWORD
|
SectionAlignment
|
Выравнивание в
байтах для секций при загрузке в память, большее или равное FileAlignment. По
умолчанию равно размеру страницы виртуальной памяти для данного процессора.
|
|
24
|
4
|
DWORD
|
FileAlignment
|
Выравнивание в
байтах для секций внутри файла. Должно быть степенью 2 от 512 до 64 Кб
включительно. По умолчанию равно 512. Если SectionAlignment меньше размера
страницы виртуальной памяти, то FileAlignment должно с ним совпадать.
|
|
28
|
2
|
WORD
|
MajorOperatingSystemVersion
|
Старшая цифра
номера версии операционной системы. Загрузчиком не используется.
|
|
2A
|
2
|
WORD
|
MinorOperatingSystemVersion
|
Младшая цифра
номера версии операционной системы. Загрузчиком не используется.
|
|
2C
|
2
|
WORD
|
MajorImageVersion
|
Старшая цифра
номера версии данного файла. Загрузчиком не используется.
|
|
2E
|
2
|
WORD
|
MinorImageVersion
|
Младшая цифра
номера версии данного файла. Загрузчиком не используется.
|
|
30
|
2
|
WORD
|
MajorSubsystemVersion
|
Старшая цифра
номера версии подсистемы.
|
|
32
|
2
|
WORD
|
MinorSubsystemVersion
|
Младшая цифра
номера версии подсистемы.
|
|
34
|
4
|
DWORD
|
Win32VersionValue
|
Зарезервировано,
всегда равно 0.
|
|
38
|
4
|
DWORD
|
SizeOfImage
|
Размер файла в
памяти, включая все заголовки. Должен быть кратен SectionAlignment.
|
|
3C
|
4
|
DWORD
|
SizeOfHeaders
|
Суммарный
размер заголовка и заглушки DOS, заголовка PE и заголовков секций,
выравненный на границу FileAlignment. Задает смещение от начала файла до
данных первой секции.
|
|
40
|
4
|
DWORD
|
CheckSum
|
Контрольная
сумма файла.
|
|
44
|
2
|
WORD
|
Subsystem
|
Исполняющая
подсистема Windows для данного файла.
|
|
46
|
2
|
WORD
|
DllCharacteristics
|
Дополнительные
атрибуты файла.
|
|
48
|
4/8
|
DWORD/ULONGLONG
|
SizeOfStackReserve
|
Размер стека
стартового потока программы в байтах виртуальной памяти. При загрузке в
физическую память отображается только SizeOfStackCommit байт, в дальнейшем
отображается по одной странице виртуальной памяти. По умолчанию равен 1 Мб.
|
|
4C/50
|
4/8
|
DWORD/ULONGLONG
|
SizeOfStackCommit
|
Начальный
размер стека программы в байтах. По умолчанию равен 4 Кб.
|
|
50/58
|
4/8
|
DWORD/ULONGLONG
|
SizeOfHeapReserve
|
Размер кучи
программы в байтах. При загрузке в физическую память отображается только
SizeOfHeapCommit байт, в дальнейшем отображается по одной странице
виртуальной памяти. По умолчанию равен 1 Мб. Во всех 32-разрядных версиях
Windows куча ограничена только размером виртуальной памяти и это поле,
по-видимому, игнорируется.
|
|
54/60
|
4/8
|
DWORD/ULONGLONG
|
SizeOfHeapCommit
|
Начальный
размер кучи программы в байтах. По умолчанию равен 4 Кб.
|
|
58/68
|
4
|
DWORD
|
LoaderFlags
|
Устаревшее
поле, не используется.
|
|
5C/6C
|
4
|
DWORD
|
NumberOfRvaAndSizes
|
Количество
описателей каталогов данных. На текущий момент всегда равно 16.
|
|
60/70
|
128
|
IMAGE_DATA_DIRECTORY[16]
|
DataDirectory
|
Описатели
каталогов данных.
|
Поле Magic
16-битовое поле, содержащее сигнатуру
заголовка. Может принимать значения (см. Таблицу 2.4):
Таблица 2.4 - Допустимые значения поля Magic
|
Название
|
Значение
|
Описание
|
|
IMAGE_ROM_OPTIONAL_HDR_MAGIC
|
0x0107
|
Заголовок
прошивки в ПЗУ
|
|
IMAGE_NT_OPTIONAL_HDR32_MAGIC
|
0x010B
|
Заголовок PE32.
|
|
IMAGE_NT_OPTIONAL_HDR64_MAGIC
|
0x020B
|
Заголовок
PE32+.
|
Поля
MajorSubsystemVersion и MinorSubsystemVersion
16-битовые числа, указывающее ожидаемую
версию Windows. В отличие от всех остальных полей с номерами версий это поле
анализировалось при загрузке программ в NT 4.0 и 95. Если программа была
графическим приложением и это поле не содержало версии 4.0, то считалось, что
программа разработана для NT 3.51 и моделировалось поведение этой ОС (в
частности, отсутствие трехмерных стилей диалогов и пр.). В настоящее время не
используется и практически всегда равно 4.0.
Поле CheckSum
32-битовая контрольная сумма файла.
Проверяется только в Windows NT при загрузке драйверов ядра и нескольких
системных DLL. Алгоритм вычисления контрольной суммы недокументирован, но для
ее вычисления можно использовать системную функцию CheckSumMappedFile из библиотеки
IMAGEHLP.DLL.
Поле Subsystem
16-битовое число, указывающее в какой
подсистеме Windows API должен исполняться данный файл. Его возможные значения
представлены в таблице 2.5:
Таблица 2.5 - Допустимые значения поля
Subsystem
|
Название
|
Значение
|
Подсистема
|
|
IMAGE_SUBSYSTEM_UNKNOWN
|
0
|
Неизвестная
подсистема.
|
|
IMAGE_SUBSYSTEM_NATIVE
|
1
|
Подсистема не
требуется, используется драйверами и «родными» приложениями NT.
|
|
IMAGE_SUBSYSTEM_WINDOWS_GUI
|
2
|
Графическая
подсистема Windows.
|
|
IMAGE_SUBSYSTEM_WINDOWS_CUI
|
3
|
Консольная
подсистема Windows.
|
|
IMAGE_SUBSYSTEM_OS2_CUI
|
5
|
Консольная
подсистема OS/2.
|
|
IMAGE_SUBSYSTEM_POSIX_CUI
|
7
|
Консольная
подсистема POSIX.
|
|
IMAGE_SUBSYSTEM_NATIVE_WINDOWS
|
8
|
«Родной»
драйвер Win 9x.
|
|
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI
|
9
|
Графическая
подсистема Windows CE.
|
|
IMAGE_SUBSYSTEM_EFI_APPLICATION
|
10
|
Программа EFI.
|
|
IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER
|
11
|
Драйвер EFI,
обеспечивающий загрузочный сервис.
|
|
IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER
|
12
|
Драйвер EFI
времени выполнения.
|
|
IMAGE_SUBSYSTEM_EFI_ROM
|
13
|
Прошивка ПЗУ
для EFI.
|
|
IMAGE_SUBSYSTEM_XBOX
|
14
|
Подсистема
Xbox.
|
Поле DLLCharacteristics
16-битовое поле флагов, задающие
дополнительные атрибуты файла. Возможные значения флагов представлены в таблице
2.6.
Таблица 2.6 - Возможные значения флагов
поля DLLCharacteristics
|
Название
|
Значение
|
Описание
|
|
IMAGE_DLLCHARACTERISTICS_NO_SEH
|
0x0400
|
Файл не
использует структурную обработку исключений.
|
|
IMAGE_DLLCHARACTERISTICS_NO_BIND
|
0x0800
|
Запрещает
статическое связывание этого файла.
|
|
IMAGE_DLLCHARACTERISTICS_WDM_DRIVER
|
0x2000
|
Файл является
WDM-драйвером.
|
|
IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE
|
0x8000
|
Если этот флаг
не установлен, то при загрузке программы терминальным сервером будет
загружена вспомогательная DLL, обеспечивающая совместимость кода.
|
Поля NumberOfRvaAndSizes
и DataDirectory
В конце необязательного заголовка
располагается 32-битовое число, в котором хранится количество описателей
каталогов данных. За ним следует массив самих описателей, каждый из которых
имеет такой вид:
struct
IMAGE_DATA_DIRECTORY {VirtualAddress;Size;
};
В настоящее время поле
NumberOfRvaAndSizes всегда содержит число 16 (символическое имя
IMAGE_NUMBEROF_DIRECTORY_ENTRIES). Соответственно массив DataDirectory состоит также
из 16 описателей. Каждый описатель содержит RVA и размер для одного каталога
данных. Если какого-либо каталога в файле нет, то оба поля его описателя равны
нулю.
Каждый из каталогов данных содержит
определенную служебную информацию. Вид этой информации определяется номером каталога
в массиве описателей. Поскольку каталоги данных, как правило, располагаются
внутри секций, для доступа к их содержимому нам потребуется сначала изучить
структуру секций.
Заголовки секций
Сразу после заголовка PE в файле
располагается массив заголовков секций. Его размер задается полем
NumberOfSections заголовка файла. Каждый заголовок секции состоит из 0x28 байт
и имеет следующую структуру (см. Таблицу 2.7):
Таблица 2.7 - Струкура заголовка секции
|
Смещение (hex)
|
Размер
|
Тип
|
Название
|
Описание
|
|
00
|
8
|
CHAR[8]
|
Name
|
Название
секции.
|
|
08
|
4
|
DWORD
|
Misc.
VirtualSize
|
Размер секции в
памяти. Если это значение больше SizeOfRawData, то секция дополняется в
памяти нулевыми байтами.
|
|
0C
|
4
|
DWORD
|
RVA секции в
памяти.
|
|
10
|
4
|
DWORD
|
SizeOfRawData
|
Размер секции в
файле. Всегда кратен FileAlignment из необязательного заголовка. Если секция
содержит только неинициализированные данные, то это поле равно нулю.
|
|
14
|
4
|
DWORD
|
PointerToRawData
|
Смещение в
файле до начала данных секций. Всегда кратно FileAlignment из необязательного
заголовка. Если секция содержит только неинициализированные данные, то это
поле равно нулю.
|
|
18
|
4
|
DWORD
|
PointerToRelocations
|
В исполняемых
файлах это поле всегда равно нулю.
|
|
1С
|
4
|
DWORD
|
PointerToLinenumbers
|
В исполняемых
файлах это поле всегда равно нулю.
|
|
20
|
2
|
WORD
|
NumberOfRelocations
|
В исполняемых
файлах это поле всегда равно нулю.
|
|
22
|
2
|
WORD
|
NumberOfLinenumbers
|
В исполняемых
файлах это поле всегда равно нулю.
|
|
24
|
4
|
DWORD
|
Characteristics
|
Атрибуты
секции.
|
Название секции
Название секции содержит от 0 до 8
ASCII-символов. Вместо константы 8 можно использовать определение
IMAGE_SIZEOF_SHORT_NAME. Если длина названия меньше 8 символов, то оно
дополняется нулевыми байтами. Если оно состоит ровно из 8 символов, то
завершающего нулевого байта нет. Важно отметить, что название секции, вообще
говоря, никак не соотносится с ее содержимым. Каждый компилятор использует свое
собственное соглашение о именовании секций, поэтому полагаться на название
секции при ее анализе нельзя. Единственно надежным способом определить, что
содержит данная секция, является анализ ее атрибутов и содержащихся в ней
каталогов данных.
Атрибуты секции
32-битовое поле Characteristics содержит
набор флагов, описывающих содержимое данной секции. Секции исполняемого файла
могут иметь следующие атрибуты (см. Таблицу 2.8):
Таблица 2.8 - Атрибуты секции
|
Название
|
Значение
|
Описание
|
|
IMAGE_SCN_CNT_CODE
|
0x00000020
|
Секция содержит
исполняемый код.
|
|
IMAGE_SCN_CNT_INITIALIZED_DATA
|
0x00000040
|
Секция содержит
инициализированные данные.
|
|
IMAGE_SCN_CNT_UNINITIALIZED_DATA
|
0x00000080
|
Секция содержит
неинициализированные данные.
|
|
IMAGE_SCN_MEM_DISCARDABLE
|
0x02000000
|
Секция может
быть удалена из памяти после создания процесса.
|
|
IMAGE_SCN_MEM_NOT_CACHED
|
0x04000000
|
Секция не может
кэшироваться.
|
|
IMAGE_SCN_MEM_NOT_PAGED
|
0x08000000
|
Секция не может
выгружаться в файл подкачки.
|
|
IMAGE_SCN_MEM_SHARED
|
0x10000000
|
Все копии
данного файла могут иметь один общий экземпляр этой секции. По-видимому,
используется только для секций данных динамических библиотек.
|
|
IMAGE_SCN_MEM_EXECUTE
|
0x20000000
|
Секцию можно
исполнять как программный код.
|
|
IMAGE_SCN_MEM_READ
|
0x40000000
|
Секцию можно
читать.
|
|
IMAGE_SCN_MEM_WRITE
|
0x80000000
|
В секцию можно
писать.
|
Сами секции располагаются в файле после
всех заголовков секций. Каждая секция выравнена на границу FileAlignment из
необязательного заголовка.
При анализе содержимого секций следует
учитывать, что это содержимое может быть разнородным. Например, одна секция
может содержать и исполняемый код, и таблицу импорта.
.4 Способы заражения
файлов
Общее положение
Существует множество методов заражения (то
есть записи кода вируса в код программы без потери работоспособности
последнего) файлов формата Portable Executeable. Есть простые методы, которые с
лёгкостью отлавливаются антивирусами, есть очень сложные.
Существует три основных метода заражения
PE EXE:
1) внедрение в заголовок;
2) расширение последней секции;
) добавление новой секции.
Внедрение в заголовок
Рассмотрим первый метод заражения PE EXE
файлов, а именно запись в заголовок жертвы. Он не самый простой, но довольно
интересный. Небезызвестный вирус win95.CIH (Чернобыль) записывал свою
загрузочную процедуру именно в то место, которое будет рассмотрено ниже.
«Запись в заголовок» - это не совсем
верное утверждение, так как рассматриваемое пространство находится не в самом
заголовке. На рисунке 2.1 изображена примерная структура PE EXE файла.
Рисунок 2.1 Примерная структура РЕ файла
Участок, помеченный голубым - это и есть
«дыра» в которую записывается тело «вируса». Как видно из рисунка, она
находится между последним элементом (element n) таблицы объектов и смещением
первой секции. Откуда же эта «дыра» взялась? Дело в том, что существует такое
понятие, как выравнивание. За эту величину отвечает поле File
Align в PE Header по смещению 3Ch и имеющее тип DWORD. В большинстве случаев
оно равно 200h и это означает, что секции в файле должны быть расположены по
адресам кратным данному значению. Большинство линкеров, выставляют физический
адрес первой секции равным 600h, следовательно, первая секция располагается в
файле по смещению 600h. Заголовок файла содержит намного меньше информации, чем
600h байт, вот и получается в результате «пробел» - чистый клочок бумаги, на
который можем написать вирус.
Для того чтобы найти это свободное место
необходимо:
) узнать некоторые значения из PE
Header;
) узнать некоторые значения из
Object Table;
) произвести парочку нехитрых
арифметических операций.
Вот нужные поля из заголовка PE EXE файла
(см. Таблицу 2.9):
Таблица 2.9 Необходимые поля РЕ заголовка
|
RVA
|
Size
|
Name
|
Description
|
|
06h
|
Word
|
Num of Objects
|
Число элементов
в Object Table
|
|
14h
|
Word
|
NT Header Size
|
Размер
заголовка PE файла-18h
|
|
54h
|
DWord
|
Header Size
|
Общий размер
всех заголовков
|
Почему в поле NT Header Size присутствует
(«минус» 18h)? Дело в том, что это поле показывает размер PE заголовка, начиная
с поля Magic, которое находится по смещению 18h, следовательно, чтобы найти
размер всего заголовка, необходимо прибавить смещение поля Magic.
Теперь давайте подробнее рассмотрим
действия, которые нам необходимо выполнить для поиска свободного места. В
скобках даны пояснения, откуда берутся значения, из PE Header или Object Table.
) находим размер PE заголовка (PE Header)
) находим размер таблицы объектов, для
этого:
А) берем количество элементов Object Table
(PE Header)
Б) умножаем на размер одного элемента,
т.е. на 40
) к виртуальному адресу (далее VA)
файла-жертвы прибавим сумму результатов вычислений первого и второго пунктов,
получим VA искомой области.
) находим физическое смещение первой
секции:
А) находим смещение первого элемента
таблицы объектов, это конец заголовка PE и начало Object Table
Б) получаем из этого элемента физическое
смещение первой секции и добавляем к нему VA файла - жертвы
) Вычислим разность результатов четвертого
и третьего пунктов, получаем размер искомой области
Расширение последней
секции
Огромным минусом данного метода является
то, что размер зараженного файла увеличится, а, следовательно, увеличится
вероятность быть обнаруженным.
Каждый элемент описывает одну секцию. В
Object Table элементы идут последовательно друг за другом без промежутков, но
необязательно в порядке возрастания Physical Offset и Section RVA. Т.е.
последний элемент не всегда описывает последнюю секцию, хотя в большинстве
случаев это так (под «последней секцией» подразумевается секция, которая
физически и виртуально находится в файле последней). При поиске свободного
места в заголовке производился поиск физического смещение первой секции, т.е.
секции, которая находится в файле первой физически. Здесь же понадобится
физическое смещение последней и смещение элемента (из Object Table) ее
описывающего - для того, чтобы пропатчить некоторые значения. Найдем самое
большое значение Physical Offset из всех элементов. Элемент, содержащий это
значение, и будет нам нужен. Так же понадобится найти элемент, который содержит
наибольшее значение Virtual RVA. Дело в том, что секция может быть физически в
файле последней, а вот виртуально, т.е. в памяти, она может расположиться где
угодно, например первой. Тогда при ее расширении можно затереть последующую
секцию в памяти. Вообще такое довольно редко встречается, но вирус на то и
вирус, чтобы предусмотреть все возможные варианты. Затем нам нужно проверить,
принадлежат ли наибольшие значения Physical Offset и Virtual RVA одному
элементу, если да, то секция является последней и физически в файле и
виртуально в памяти.
Теперь можно дописать свой код в последнюю
секцию и «пропатчить» элемент, который ее описывает.
Однако при внимательном рассмотрении ре
файла можно было заметить довольно интересную вещь. Физический конец последней
секции меньше размера файла.
Т.е. Physical Offset + Physical Size <
File Size, как так, а что же содержится в оставшемся участке? В большинстве
случаев ничего, просто нули, это называется оверлеем. Оверлей - это то, что
находится между физическим концом последней секции и концом файла. Конечно,
оверлей может содержать и полезную для файла информацию.
Теперь, задача определить является ли
оверлей в жертве пустышкой, т.е. содержит нули или это оверлей содержащий какую
либо информацию для жертвы.
Кстати, если найден оверлей-пустышка, то с
таким файлом можно проделать следующее. Когда размер кода, внедряемого в
жертву, меньше размера пустого оверлея, то при записи вирусного кода в файл,
размер его не увеличится. Т.е. секция расширится, а размер не увеличится.
Итак, что нужно сделать, чтобы внедрить
вирус:
) найти смещение последней секции
и ее элемента из Object Table;
) записать код «вируса» в конец последней секции
(Physical Offset+Physical Size=конец секции);
) увеличить физическую и виртуальную длины
последней секции на длину «вируса»;
) увеличить размер загружаемого образа на
длину «вируса»;
) при необходимости изменить
характеристики секции (битовые флаги);
Необходимо учесть такой момент, если у
расширяемой секции физическая длина равна 0, то эту секцию трогать нельзя.
Добавление новой секции
Для начала необходимо еще раз вспомнить структуру ре
заголовка. Одно из полей на которое необходимо сразу же обратить внимание это
поле отвечающае за количество элементов, содержащихся в Object Table. После
добавления новой секции нужно провести инкремент этого поля, т.е. увеличить его
на единицу, если, конечно, добавляется одна секция. В противном случае
увеличивать нужно его на число, равное количеству добавляемых секций.
При заполнении полей Section RVA и
PhysicalOffset, важно помнить, что эти поля должны быть выровнены всегда.
Считаются они так:
SectionRVA (новой сек.) = SectionRVA
(последней сек.) + VirtualSize (последней сек.)
PhysicalOffset (новой сек.) =
PhysicalOffset (последней сек.) + PhysicalSize (последней сек.)
После того как элемент заполнен, в том
числе и поле характеристик секции, можно приступать к копированию кода вируса в
новую секцию. EDI должен указывать на новый элемент в Object Table.
.5 Структура программы
Автоматизированная система создания
сигнатур исполняемых файлов предназначена для выделения вирусной сигнатуры из
файлов зараженных одним семейством вирусов. Также система должна определять заражен
ли файл по имеющимся сигнатурам. Сигнатуры будут храниться в специальном файле.
Автоматическое определение сигнатуры будет происходить с помощью класса AutoSignature. А поиск сигнатур в в
потенциально зараженных файлах будет происходить с помощью класса SignatureScanner.
Принцип выявления новых сигнатур
представлен на Рисунке 2.2.
Рисунок 2.2 - Выявления сигнатуры
Класс AutoSignature имеет следующий вид (см. Рисунок 2.3):
Рисунок 2.3 - Диаграмма класса AutoSignature
Поле bytesarray содержит массивы байт для каждого файла
участвующего в автоматическом выявлении новой сигнатуры. По этому массиву будет
происходить, а также определение вирусной сигнатуры, если таковая будет
определена.
Поле filepath является массивом с именами всех файлов.
Методы GetLastBytes
GetLastSectionBytes GetBytesAfteHeader извлекают массивы байт из уязвимых мест
файлов в массив bytesarray.
Метод LSC принимает на вход два массива байт анализирует их, и
возвращает наибольшую общую последовательность байт.
Имеется также два
конструктора по умолчанию (инициализируется нулями) и с параметрами (получает
на вход массив имен файлов).
Метод analyse является общедоступным. Этот метод производит поиск
сигнатуры вызывая все вышеописанные методы.
Класс SignatureScanner имеет следующий вид (см.
Рисунок 2.3):
Рисунок 2.4 - Диаграмма класса SignatureScanner
Метод checkfile проверяет заражен ли
файл с помощью базы сигнатур. Имеет 2 перегрузки:
) Входные параметры: строка с
именем файла.
) Массив имен файлов.
Поле file имеет тип SignatureFile. Это класс который
реализовывает работу с фалом сигнатур.
Класс SignatureFile имеет следующий вид (см. Рисунок 2.4):
Рисунок 2.5 - Диаграмма класса SignatureFile
Поле signfile является объектом класс FileStream.
Метод isendoffile проверят находится
указатель в конце файла.
Метод next возвращает следующую
сигнатуру из файла.
Метод previous возвращает предыдущую
сигнатуру или null.
3. Реализация и испытание
Ниже приведен код метода analyse класса AutoSignature
public byte[] analyse()
{
GetLastBytes();
byte [] result =bytesarray[0];
for (int
i = 1; i < bytesarray. Count(); i++)
{= LSC
(result, bytesarray[i]);
}(result.
Count() >= 6)
{result;
}
();=
bytesarray[0];(int i = 1; i < bytesarray. Count(); i++)
{= LSC
(result, bytesarray[i]);
}(result.
Count() >= 6)
{result;
}
();=
bytesarray[0];(int i = 1; i < bytesarray. Count(); i++)
{= LSC
(result, bytesarray[i]);
}(result.
Count() >= 6)
{result;
}null;
}
Пример работы программы (см. Рисунок 3.1):
Рисунок 3.1 Примеры работы программы
4. Технико-экономическое
обоснование
.1 Расчет полной
себестоимости ПП
Стоимостная оценка программного средства у
разработчика предполагает составление сметы затрат, которая включает следующие
статьи расходов:
ü Заработную плату
исполнителя (основную - ЗПо и дополнительную - ЗПд);
ü Отчисления на социальные
нужды (Рсоц);
ü Материалы и комплектующие
изделия (Рм);
ü Спецоборудование (Рс);
ü Машинное время (Рмв);
ü Расходы на научные
командировки (Рнк);
ü Прочие прямые расходы
(Рпр);
ü Накладные расходы (Рнр);
ü Затраты на освоение и
сопровождение программного средства (Ро и Рсо);
Полная себестоимость (Сп) разработки
программного продукта рассчитывается как сумма расходов по всем статьям с
учетом рыночной стоимости аналогичных продуктов. Определяется по формуле:
Сп = ЗПо + ЗПд + Рсоц + Рм +Рс + Рмв + Рнк
+ Рпр + Рнр +Ро +Рсо. (4.1)
1) Расчет заработной платы
производится по формуле:
ЗПосн = Тст1 р * Тк / 22 * Фрв * Кпр (4.2)
Тст1 р - Месячная тарифная ставка 1
разряда рабочего утвержденная согласно ЕТС РБ на дату написания дипломного
проекта (275 000 руб.);
Тк - тарифный коэффициент согласно разряду
исполнителя;
- среднее количество рабочих дней в
месяце;
Фрв - фонд рабочего времени исполнителя
Кпр - коэффициент премий
ЗПдоп = ЗПосн * Ндоп.зп / 100
Ндоп.зп - Дополнительная заработная плата
каждого исполнителя;
Таблица 4.1 - Таблица заработной платы
|
Категории
работников
|
Разряд
|
Тарифный
коэффициент
|
Фонд рабочего
времени, дни
|
Коэффициент
премирования
|
Норматив
дополнительной зарплаты, %
|
Заработная
плата, руб.
|
|
|
|
|
|
|
Основная
|
Дополни-
тельная
|
Всего
|
|
Руководитель
проекта
|
16
|
3,72
|
30
|
1,3
|
15
|
1 813 500
|
308 295
|
2 121 795
|
|
Программист 2
категории
|
10
|
2,48
|
50
|
1,2
|
17
|
1 860 000
|
316 200
|
2 176 200
|
|
Итого
|
|
|
|
|
|
3 673 500
|
624 495
|
4 297 995
|
Руководитель:
ЗПосн рук = 275000 * 3,72 /22 * 30 *1,3 =
1 813 500 руб.
ЗПдоп рук= 1 813 500 * 17/100 = 308 295
руб.
ЗПосн рук + ЗПдоп рук = 2 121 795 руб.
Программист 2 категории
ЗПосн пр = 275000 * 2,48 /22 * 50 *1,2 = 1
860 000 руб.
ЗПдоп пр = 1 860 000* 17/100 = 316 200
руб.
ЗПосн пр + ЗПдоп пр = 2 176 200 руб.
Итого:
ЗПосн = ЗПосн рук +ЗПосн пр = 1 813 500 +
1 860 000 = 3 673 500 руб.
ЗПдоп = ЗПдоп рук + ЗПдоп пр = 308 295 +
316 200 = 624 495 руб.
ЗПосн + ЗПдоп = 3 673 500 + 624 495 = 4
297 995 руб.
) Отчисления на социальные нужды
(Рсоц) определяются в соответствии с действующим законодательством по нормативу
(34% - отчисления в ФСЗН + 0,6% отчисления по обязательному страхованию):
Рсоц = (ЗПосн + ЗПдоп) * 34,6 / 100 (4.3)
Рсоц = (3 673 500+ 624 495) * 34,6 /100 =
1 487 106 руб.
) Расходы по статье
«Спецоборудование» (Рс) включает затраты на приобретение технических и
программных средств специального назначения, необходимых для разработки
конкретного ПП, включая расходы на проектирование, изготовление, отладку и др.
(определяются по фактически действующим на рынке ценам). Спецоборудование в
данном проекте не приобреталось.
) По статье «Материалы и комплектующие
изделия» (Рм) отражаются расходы на магнитные носители, бумагу, красящие ленты
и другие материалы, необходимые для разработки ПП. Норма расхода материалов в
суммарном выражении определяются либо в расчете на 100 строк исходного кода,
либо в процентах к основной заработной плате разработчиков. Сумма затрат на
расходные материалы рассчитывается по формуле:
Рм = Нм * (Vо /100) (4.4)
Нм - норма расхода материалов в расчете на
100 строк исходного кода ПП.
Vо - уточненный общий
объем функций строк исходного кода (LOC).
Рм = ЗПосн * Нмз /100
Нмз - норма расхода материалов от основной
заработной платы, 3%.
Рм = 3 673 500 * 3 /100 = 110 205 руб.
5) Расходы по статье «Машинное
время» (Рмв) включают оплату машинного времени, необходимого для разработки и
отладки ПП. Они определяются в машино-часах по нормативам на 100 строк
исходного кода машинного времени в зависимости от характера решаемых задач и
типа ПП.
Рмвi = Цмi * Vo /100 * Нмв (4.5)
где Цмi - цена одного
машино-часа, тыс. руб. (можно принять 5-8 тыс. руб.);
Vо - уточнённый общий
объём функций строк исходного кода (LOC);
Нмв - норматив расхода машинного времени
на отладку 100 строк кода, машино-часов. Принимается в размере 0,6-0,9.
Таблица 4.2 - Подсчет строк кода
|
Номер фкнкции
|
Наименование
(содержание)
|
Объем функций,
LOC
|
|
|
По каталогу
(Vi)
|
уточненный
(Vуi)
|
|
101
|
Организация
ввода информации
|
150
|
150
|
|
102
|
Контроль,
предварительная обработка и ввод информации в интерактивном режиме
|
550
|
550
|
|
303
|
Обработка
файлов
|
1100
|
1100
|
|
602
|
Проведение тестовых
испытаний прикладных программ в интерактивном режиме
|
4300
|
4300
|
|
701
|
Математическая
статистика и прогнозирование
|
3780
|
3780
|
|
Итого
|
|
9880
|
9880
|
Рмв = 7 000 * 9880 / 100 * 0,7 = 484 120 руб.
) Расходы на научные командировки
(Рнк) берутся либо по смете научных командировок, разрабатываемой на
предприятии, либо в процентах от основной заработной платы исполнителей
(10-15%). Научные командировки в данном проекте на требовались.
) Расходы по статье «Прочие
затраты» (Рпр) включают затраты на приобретение специальной научно-технической
информации и специальной литературы. Определяются в процентах к основной
заработной плате исполнителей.
Рпр = ЗПосн * 11 /100 = 3 673 500 * 11
/100 = 404 085 руб.
) Затраты по статье «Накладные
расходы» (Рнр) связаны с содержанием вспомогательных хозяйств, опытных
производств, а также с расходами на общехозяйственные нужды. Определяются по
нормативу в процентах к основной заработной плате исполнителей (для бюджетных
организаций норматив устанавливается в пределах 100%, для иных организаций
можно брать реальные проценты, установленные в организации).
Рнр = 3 673 500 *100 /100 = 3 673 500
Сумма выше перечисленных расходов по
статьям (пп. 1 - 8) на ПП служит исходной базой для расчёта затрат на освоение
и сопровождение ПП:
Сумма затрат1-8 = ЗПо + ЗПд + Рсоц + Рм
+Рс +Рмв + Рнк + Рпр + Рнр. (4.6)
Сумма затрат1-8 = 3 673 500 + 624 495 + 1
487 106 + 110 205 + 0 + 484 120 + 0 + 404 085 + 3 673 500 = 10 457 011 руб.
9) Затраты на освоение ПП (Ро).
Организация-разработчик участвует в освоении ПП и несёт соответствующие
затраты, на которые составляется смета, оплачиваемая заказчиком по договору.
Для упрощения расчётов затраты на освоение определяются по установленному
нормативу (Но =7%) от суммы затрат по пунктам 1 - 8:
Ро = Сумма затрат1-8 *Но /100 (4.7)
Ро = 10 457 011 * 7 /100 = 731 991 руб.
10) Затраты на сопровождение Рсо.
Организация-разработчик осуществляет сопровождение ПП и несёт расходы, которые
оплачиваются заказчиком в соответствии с договором и сметой на сопровождение.
Для упрощения расчётов определяются по установленному нормативу
(Нсо= 6%) от суммы затрат по пунктам 1 -
8:
Рсо = Сумма затрат1-8 * Нсо/100 (4.8)
Рсо = 10 457 011 * 6 /100 = 627 421 руб.
11) Полная себестоимость (Сп)
программного продукта рассчитывается по формуле 4.1
Сп = 3 673 500 + 624 495 + 1 487 106 + 110
205 + 0 + 484 120 + 0 + 404 085 + 3 673 500 + 731 991 + 627 421 = 11 816 423
руб.
Таблица 4.3 - Расчет себестоимости
|
№ п/п
|
Наименование
статей затрат
|
Норматив, %
|
Расчетная
формула
|
Сумма затрат,
руб.
|
|
А
|
В
|
С
|
D
|
|
1
|
Заработная
плата всего
|
-
|
-
|
4 297 995
|
|
1.1
|
Основная
|
-
|
-
|
3 673 500
|
|
1.2
|
Дополнительная
|
-
|
624 495
|
|
2
|
Отчисления на
социальные нужды
|
34,6%
|
1,1D*2В 100
|
1 487 106
|
|
3
|
Спецоборудование
|
-
|
-
|
0
|
|
4
|
Материалы
|
3%
|
1,1D*4В 100
|
110 205
|
|
5
|
Машинное время
|
-
|
-
|
484 120
|
|
6
|
Научные
командировки
|
-
|
-
|
0
|
|
7
|
Прочие затраты
|
11%
|
1,1D*7В 100
|
404 085
|
|
8
|
Накладные
расходы
|
100%
|
1,1D*8В 100
|
3 673 500
|
|
9
|
Сумма затрат
|
-
|
1D+2D+3D+4D+
5D+6D+7D+8D
|
10 457 011
|
|
10
|
Затраты на
освоение и сопровождение
|
7% 6%
|
9D*10В 100
|
1 341 412
|
|
11
|
Полная
себестоимость
|
-
|
9D+10D
|
11 816 423
|
4.2 Расчёт цены и прибыли
по ПП
Для определения цены ПП необходимо
рассчитать плановую прибыль.
) Прибыль рассчитывается по
формуле:
П = Сп * R/100 (4.9)
П - плановая прибыль от реализации ПО,
руб.- уровень рентабельности ПП 18%
П = 11 816 423 * 18/100 = 2 126 956 руб.
Исходя из результатов анализа рыночных
условий, переговоров с заказчиком и согласования с ним отпускной цены,
рентабельность и прибыль создаваемого
ПП = 40 000 000 руб.
2) Прогнозируемая цена ПП без
налогов
Цп = Сп +П (4.10)
Цп = 11 816 423 + 2 126 956 = 13 943 379
руб.
3) Отпускная цена (цена реализации)
ПП включает налог на добавленную стоимость (в настоящее время НДС - 20%)
Цо = Сп + П + НДС (4.11)
НДС = Цп * НДС/100 (4.12)
НДС = 13 943 379 * 20/100 = 2 788 676 руб.
Цо = 11 816 423 + 2 126 956 + 2 788 676 =
16 732 055 руб.
) Прибыль от реализации ПП за
вычетом налога на прибыль (Пч) является чистой прибылью, остается организации
разработчику и представляет собой ЭКОНОМИЧЕСКИЙ ЭФФЕКТ от создания нового
программного продукта.
Пч = П * (1 - Нп/100) (4.13)
Нп - ставка налога на прибыль (в настоящее
время Нп = 18%)
Пч = 2 126 956 * (1 - 18/100) = 1 744 104
руб.
Таблица 4.4 - Расчет прибыли
|
№ п/п
|
Наименование
статей затрат
|
Норматив, %
|
Расчетная
формула
|
Сумма затрат,
руб.
|
|
А
|
В
|
С
|
Д
|
|
1
|
Полная
себестоимость
|
-
|
-
|
11 816 423
|
|
2
|
Прибыль
|
18%
|
1Д*2В 100
|
2 126 956
|
|
3
|
Цена без НДС
|
-
|
1Д+2Д
|
13 943 379
|
|
4
|
НДС
|
20%
|
3Д*4В 100
|
2 788 676
|
|
5
|
Отпускная цена
с НДС
|
-
|
3Д+4Д
|
16 732 055
|
|
6
|
Чистая прибыль
|
(1-18/100)
|
2Д*6В
|
1 744 104
|
5. Энергосбережение
.1 Цели и средства
реализации энергетической политики
Основной целью Энергетической политики
Республики Беларусь является поиск путей и формирование механизмов оптимального
развития и функционирования отраслей ТЭК, а также техническая реализация
надежного и эффективного энергообеспечения всех отраслей экономики и населения,
обеспечивающих производство конкурентоспособной продукции и достижение
стандартов уровня и качества жизни населения высокоразвитых европейских
государств при сохранении экологически безопасной окружающей среды.
Достижение поставленной цели должно
базироваться на:
ü определении влияния
уровня развития производительных сил и социальных условий жизни населения на
потребление энергоносителей;
ü определении оптимального
соотношения импорта и собственного производства энергоносителей, включая
максимальное использование нетрадиционных и возобновляемых источников;
ü выборе надежных и
экономически выгодных поставщиков ТЭР из-за пределов республики;
ü сохранении единства
технологического управления в масштабах ТЭК;
ü рациональной структуре
энергетических мощностей и систем транспорта энергоносителей;
ü надежном и экономичном
энергообеспечении потребителей и максимально эффективным использованием
энергоносителей за счет внедрения энергосберегающих организационно-технических
мероприятий;
ü использовании
геополитического положения республики для транзита всех видов энергоносителей,
а также экспорта электроэнергии собственного производства;
ü удовлетворении интересов
областей и отдельных городов в обеспечении энергоносителями путем расширения их
доли собственности в основных фондах энергетических объектов, включая создание
собственных муниципальных объектов, что предполагает и расширение прав в
управлении и получении доходов, однако требует сохранения единства
технологического управления в масштабах ТЭК;
ü учете принципиальных
особенностей энергообеспечения районов, загрязненных радионуклидами;
ü технической политике, ориентированной
на коренной повышение экономичности производства, распределения и использования
ТЭР, экологической безопасности объектов ТЭК;
ü приоритетах глубокой
переработки нефти на НПЗ и комплексного использования углеводородного сырья;
ü замещении светлых
нефтепродуктов в двигателях внутреннего сгорания.
Цели энергетической политики достигаются с
помощью:
ü ценовой и налоговой
политики, обеспечивающей ликвидацию диспропорций в ценах (тарифах) на
энергоносители и другие товары либо услуги при постепенном переходе к ценам и
тарифам, которым соответствуют мировые цены в качестве верхнего предела и цены
самофинансирования - в качестве нижнего;
ü формирования конкурентной
среды во всех отраслях ТЭК путем создания полноценных хозяйственных субъектов
рынка и рыночной инфраструктуры;
ü создания
нормативно-правовой базы и разработки системы нормативных актов, регулирующих
взаимоотношения субъектов энергетического рынка между собой, с органами
государственного управления и общественностью;
ü совершенствование механизмов
стимулирования широкого экономически целесообразного вовлечения в топливный
баланс местных топливных ресурсов, возобновляемых источников энергии, бытовых и
производственных отходов;
ü проведения активной
инвестиционной политики.
.2 Общие направления и приоритеты энергосберегающей политики
Стратегической целью деятельности в
области энергосбережения на период до 2005 г. должно стать снижение
энергоемкости ВВП и, в результате этого, снижение зависимости республики от
импорта ТЭР, что может быть достигнуто за счет:
ü структурной перестройки
отраслей экономики и промышленности;
ü повышения коэффициента
полезного использования энергоносителей в результате внедрения новых
энергосберегающих технологий, оборудования, приборов и материалов, утилизации
вторичных энергоресурсов;
ü увеличения в топливном
балансе республики доли местных видов топлива и отходов производства,
нетрадиционных и возобновляемых источников энергии.
Организационно-экономической основой
политики энергосбережения в перспективе должно стать развитие необходимой
законодательно-правовой и нормативно-технической базы, в состав которой войдут
ГОСТЫ, СНиПы, отраслевые нормы технологического проектирования и ряд других
документов нормативного характера, определяющих требования в области энергосбережения.
Основные организационно-экономические направления деятельности в области
энергосбережения:
ü осуществление
государственной экспертизы энергетической эффективности проектных решений с
целью их оценки на соответствие действующим нормативам и стандартам в области
энергосбережения и определения достаточности и обоснованности предусматриваемых
мер по энергосбережению;
ü переход к проведению
регулярных энергетических обследований хозяйствующих субъектов, а также
сертификации продукции по энергоемкости и введение в действие системы
прогрессивных норм расхода топлива и энергии;
ü пересмотр тарифной
политики на тепловую, электрическую энергию и топлива с целью поэтапной
ликвидации перекрестного субсидирования, а также включение в тариф только
нормируемых затрат на производство и транспортировку соответствующих видов
энергоресурсов;
ü разработка новых и
совершенствование существующих экономических механизмов, стимулирующих
повышение энергоэффективности производства продукции и оказания услуг и
определяющих меры ответственности за нерациональное потребление ТЭР как для
хозяйственных субъектов в целом, так и для конкретных руководителей и
должностных лиц;
ü реализация положений
Закона Республики Беларусь «Об энергосбережении» о введении обязательной
энергомаркировки бытовых электроприборов и их сертификации по показателям
энергопотребления; разработка стандартов минимальной энергоэффективности
основных видов бытовых электроприборов и их энергомаркировки по классам
энергоэффективности, гармонизированных с Директивами ЕС;
ü разработка и реализация
республиканских, региональных и отраслевых программ энергосбережения на
пятилетний период с периодическим их пересмотром с целью уточнения приоритетов
на ближайшую перспективу.
К основным техническим приоритетам
деятельности до 2005 г. в области энергосбережения относятся:
ü повышение эффективности
работы генерирующих источников за счет изменения структуры генерирующих
мощностей в сторону расширения внедрения парогазовых и газотурбинных
технологий, увеличения выработки электроэнергии на тепловом потреблении,
преобразования котельных в мини-ТЭЦ, оптимизации режимов работы
энергоисточников и оптимального распределения нагрузок энергосистемы;
ü модернизация и повышение
эффективности работы котельных за счет перевода паровых котлов в водогрейный
режим, модернизации тепловой изоляции на всех элементах и оборудовании
котельных и тепловых сетей; отбора дутьевого воздуха с верхней части здания
котельных; установки экономайзеров и других теплообменников для утилизации ВЭР;
оснащения котлов автоматикой контроля процессов сжигания и регулирования, либо
производственного контроля (мониторинга) топочного режима котлов на базе
портативных измерителей тепловых потерь в увязке с режимами потребления
тепловой энергии, установки аккумуляторов теплоты и др.;
ü внедрение котельного
оборудования, работающего на горючих отходах производства, сельского и лесного
хозяйства, деревообработки;
ü снижение потерь и
технологического расхода энергоресурсов при транспортировке тепловой и
электрической энергии, природного газа, нефти и нефтепродуктов за счет снижения
расходов на собственные нужды обслуживаемых подразделений, технического
перевооружения и оптимизации режимов загрузки электрических сетей и
трансформаторных подстанций, тепловых сетей и тепловых пунктов; компрессорных
станций на газопроводах, насосных в тепловых сетях, на нефте- и
продуктопроводах с внедрением регулируемого электропривода;
ü создание мини-ТЭЦ на базе
ПГУ и ГТУ на компрессорных станциях газопроводов;
ü создание технических
условий (объединение тепловых сетей, строительство перемычек, аккумуляторов
теплоты и т.п.) для максимальной передачи нагрузок от котельных любых ведомств
на ТЭЦ со стоимостью тепловой энергии для владельцев котельных на уровне ее
себестоимости на ТЭЦ;
ü наладка и автоматическое
регулирование гидравлических и тепловых режимов тепловых сетей (перерасчет и
шайбирование, замена сетевых насосов, регулировка и т.п.);
ü замена отопительных
электрокотельных на топливные котлы (преимущественно на местных видах, горючих
отходах), а также перевод всевозможных электросушильных установок и
нагревательных печей (где это целесообразно) на топливоиспользующие установки;
ü внедрение автоматических
систем регулирования потребления энергоносителей в системах отопления,
освещения, горячего и холодного водоснабжения и вентиляции жилых, общественных
и производственных помещений, в технологических установках всех типов;
ü разработка и внедрение
новых энергосберегающих технологий при нагреве, термообработке, сушке изделий,
новых строительных и изоляционных материалов с улучшенными теплофизическими
характеристиками и, в частности, спецдобавок при производстве железобетонных
изделий; энерготехнологических комплексов при производстве цемента, стекла,
кирпича, переработке нефти, на предприятиях химической и пищевой промышленности
и т.п.;
ü дальнейшее развитие
системы учета всех видов энергоносителей, включая учет их расхода на отопление
жилых помещений, а также внедрение многотарифных счетчиков энергии;
ü максимальная утилизация
тепловых вторичных энергоресурсов (горячей воды, конденсата, дымовых газов,
вентвыбросов, канализационных стоков) в технологических процессах, системах
отопления и горячего водоснабжения промышленных узлов и отдельных городов и
населенных пунктов;
ü разработка и внедрение
эффективных биогазовых установок для производства горючих газов и удобрений из
отходов животноводства, растениеводства, специально выращиваемой биомассы;
ü разработка и внедрение
технологии использования бытовых отходов и мусора для топливных целей;
ü внедрение теплонасосных
установок на промышленных предприятиях в централизованных и индивидуальных
системах отопления;
ü экономически
целесообразное внедрение ветро-, гелио- и других нетрадиционных источников
энергии;
ü техническое
перевооружение автомобильного транспорта и тракторов, включая перевод на
дизельное топливо, сжиженный и сжатый природный газ, разработка и внедрение
экономичных двигателей, совершенной системы диагностики и регулирования,
оптимальных режимов эксплуатации;
ü разработка и внедрение
технологии получения топлива для дизельных установок из метанола и рапсового
технического масла;
ü разработка, организация
производства и внедрение энергосберегающего оборудования, приборов, материалов;
ü децентрализация систем
энергообеспечения потребителей теплом, топливом, сжатым воздухом с малыми
нагрузками и резкопеременными режимами работы;
ü максимальное снижение
энергозатрат в жилищно-коммунальном хозяйстве путем внедрения регулируемых
систем отопления, вентиляции, горячего водоснабжения, освещения и утилизации
тепла вентвыбросов, сточных вод, использования энергоэффективных строительных
материалов, конструкций, гелиоподогревателей.
.3 Принципы государственной политики энергосбережения
Согласно закона Республики Беларусь «Об
энергосбережении», принятым 15 июля 1998 года, основными принципами
государственного управления в сфере энергосбережения являются:
ü осуществление
государственного надзора за рациональным использованием ТЭР;
ü разработка
государственных и межгосударственных научно-технических, республиканских,
отраслевых и региональных программ энергосбережения и их финансирование;
ü приведение нормативных
документов в соответствие с требованием снижения энергоемкости материального
производства, сферы услуг и быта;
ü создание систем
финансово-экономических механизмов, обеспечивающих экономическую
заинтересованность производителей и пользователей в эффективном использовании
топливно-энергетических ресурсов, вовлечении в топливно-энергетический баланс
нетрадиционных и возобновляемых источников энергии, а также в инвестировании
средств в энергосберегающие мероприятия;
ü повышение уровня
самообеспечения республики местными топливно-энергетическими ресурсами;
ü осуществление
государственной экспертизы энергетической эффективности проектных решений;
ü создание и широкое
распространение экологически чистых и безопасных энергетических технологий,
обеспечение безопасного для населения состояния окружающей среды в процессе
использования топливно-энергетических ресурсов;
ü реализация
демонстрационных проектов высокой энергетической эффективности;
ü информационное
обеспечение деятельности по энергосбережению и пропаганда передового
отечественного и зарубежного опыта в этой области;
ü обучение
производственного персонала и населения методам экономии топлива и энергии;
ü создание других
экономических, информационных, организационных условий для реализации принципов
энергосбережения.
.4 Методы реализации государственной политики
энергосбережения
Методы управления (регулирования)
энергосбережением - это способы воздействия на поведение и деятельность,
управляемых с целью снижения потребления, топливно-энергетических ресурсов при
сохранении или увеличении объемов производства. Выделяют следующие методы
управления:
ü социально-психологические
методы или меры морального стимулирования;
ü административные методы,
основанные на использовании разрешительно-запретительного принципа
государственного управления, выполнение которого обеспечивается возможностью
государственного принуждения;
ü финансово-экономические
методы, базирующиеся на применении денежно-стоимостных отношений,
обусловливающих экономическую заинтересованность в повышении эффективности
использования субъектами хозяйствования топливно-энергетических ресурсов,
внедрения ими энерго- и ресурсосберегающих технологий.
Заключение
В результате выполнения дипломного проекта
была разработана система, предназначенная для автоматического создания сигнатур
исполняемых файлов. Программное средство простое в использовании, поскольку
имеет удобный и привычный для пользователей операционной системы Windows
интерфейс. Программное средство очень хорошо отлажено и ошибки в программе не
найдены.
В ходе выполнения дипломного проекта
сформулированы требования к системе, выбрана структура системы, спроектирован
пользовательский интерфейс, проведены испытания системы, рассчитан
экономический эффект внедрения данного проекта.
Также можно указать о том, что в
программной системе имеется интуитивно понятный интерфейс, который информирует
пользователей о состоянии наблюдаемых процессов и при этом от самих
пользователей практически не требуется никаких действий.
Дипломный проект выполнен на актуальную
тему, связанную с защитой информации с использованием обнаружением вредоносных
программ на основе сигнатурного анализа.
Данный проект может иметь и дальнейшее
продолжение в виде доработки функционала, как интерфейса
По расчетам экономического эффекта
получена полная себестоимость проекта, которая составляет 11 816 423 (руб.), но
отпускаться он будет с учетом всех налогов и прибыли по цене 16 732 055 (руб.).
Чистая прибыль, которую можно получить от реализации проекта составила 1 744
104 (руб.), что и является экономическим эффектом от создания данного
программного средства вычислительной техники.
Все ошибки устранены. В результате
тестирования была выявлена полная работоспособность системы.
Таким образом, возможность практической
реализации данного проекта представляется достаточно рентабельной и
перспективной. Разработанная система облегчит наблюдение за работоспособностью
различных разрабатываемых приложений.
Список использованных
источников
[1] Основы работы антивирусных программ [электронный ресурс]
- http://vudguit.no-ip.biz:3232, 09.06.2014.
[2] Обнаружение, основанное на сигнатурах [электронный
ресурс] - http://ru.wikipedia.org, 09.06.2014.
[3] Кирьянов К.Г. «Сигнатурный анализ», Издательство ННГУ им.
Н.И. Лобачевского, 2004.
[4] Основные направления энергосбережения в республике
Беларусь [электронный ресурс] - http://www.energosovet.ru, 09.06.2014.
[5] Обнаружение и распознавание вирусов [электронный ресурс]
- http://www.nf-team.org, 09.06.2014.
[6] Структура исполняемых фалов Win32 и Win64 [электронный ресурс] -
http://cs.usu.edu.ru, 09.06.2014.
[7] Д.А. Козлов., А.А. Парандовский., А.К. Парандовский
«Энциклопедия компьютерных вирусов», Издательство Солон-Р, 2001.
[8] Троелсен Э. «Язык программирования C# 5.0 и платформа.NET
4.5 (6-е издание)» - Москва, Издательский дом «Вильямс», 2013.
[9] Обеспечение безопасности и защиты информации [электронный
ресурс] - http:// http://bookap.info, 09.06.2014.
[10] Лекция 2. Обзор языка C# [электронный ресурс] -
http://www.ict.edu.ru, 09.06.2014.
[11] Основы программирования на Visual C# (Visual C sharp) [электронный ресурс] -
http://compuzilla.ru, 09.06.2014.
[12] Постановление Совета Министров Республики Беларусь от
11.11.1998 №1731 «Об утверждении Положения о порядке разработки и выполнения
республиканских отраслевых и региональных программ энергосбережения»
[электронный ресурс] - http://pravo.newsby.org, 10.06.2014.
