Система автоматического создания сигнатур исполняемых файлов
Введение
антивирус программный
энергетический
Мы живем в эпоху новой научно-технической
революции. В эпоху великих открытий, но не географических, а открытия тайн
нашего удивительного мира. Человек не в состоянии хранить в голове всю
информацию касательно исследований, которые он проводит, или другую не менее
важную для него информацию. Можно конечно было использовать листок бумаги и
ручку, но несомненно в XXI веке гораздо удобней хранить такую информацию на
электронно-вычислительной машине (к примеру на персональном компьютере). Ведь
если рассудить компьютер стал незаменим помощником в жизни человека. Теперь без
него не куда. Без ЭВМ не может обойтись ни коммерческая фирма, ни
государственная организация. Однако, в связи с этим обострилось проблема защиты
информации.
Одним из самых распространенных способов
для несанкционированного доступа к информации являются компьютерные вирусы. Но
современные компьютерные вирусы позволяют не только считывать важные данные, а
также может препятствовать нормальной работе компьютера, разрушать файловую
структуру и наносить ущерб информации хранимой на персональном компьютере.
Вирусы, получившие широкое распространение в компьютерной технике, взбудоражили
весь мир. Многие пользователи компьютеров весьма обеспокоены тем, что с помощью
компьютерных вирусов злоумышленники взламывают сети, грабят банки, крадут
интеллектуальную собственность. Все чаще в системах массовой информации
появляются заявления об разного рода проделках неких хакеров или IT-хулиганов,
о появлении все более совершенных саморазмножающихся программ. Компьютерные
вирусы влияют на скорость работы и производительность системы, на выполнение
отдельных заданий затрачивается больше времени, чем прежде. Некоторые из
вирусов оказывают настолько большой вред, что вся система может «полететь» и
перестать работать и в результате будут потеряны данные. Если давать
определение компьютерному вирусу, то оно будет выглядеть примерно так:
компьютерный вирус - это самокопирующаяся программа, разработанная с целью
тиражирования самой себя помимо ведома и против воли пользователей.
Распространение вирусов реализуется через присоединение их к другим программам,
документам или путём записи в сектор начальной загрузки диска.
Несмотря на принятые во многих странах
законы о борьбе с компьютерными преступлениями, их количество все равно
продолжает расти. Поэтому появилась необходимость в создании средств от
различного рода кибератак. Для того чтобы разработать качественный программный
продукт направленный на предотвращение или исправления вирусных атак,
разработчик должен быть хорошо осведомлен о природе вируса. Одним из самых
распространенных способов заражения файлов, это заражение исполняемых фалов.
пользователь просто запускает какой-нибудь исполняемы файл, даже не подозревая
что он может быть заражен, тем самым неосознанно активирует работу вируса. И
для того чтобы выявить заражение системы, пользователь должен обладать
обширными знаниями в этой области. выходит если человек не хочет чтобы его
постигла участь кибержертвы, он должен либо осваивать методы выявления вирусов,
либо не приобретать компьютер. Оба эти варианта неприемлемы для большинства
пользователей. Поэтому существуют антивирусы - программы позволяющие неопытному
пользователю выявлять компьютерные вирусы. у многих этих антивирусов общий
принцип работы очень схож. Если вкратце описать процесс создания и работы
программ-антивирусов, то он бы выглядел примерно так:
) Эксперты зондируют интернет в поиске
новых вирусов
) При нахождении нового вируса они
выявляют его сигнатуру (последовательность байт, которая практически не
отличается в разных файлах зараженных одним вирусом).
) Добавляют эту сигнатуру в базу данных
сигнатур антивируса
) Антивирус ищет в файлах сигнатуры
имеющиеся в базе.
Сам по себе процесс выявление сигнатуры
обычно производится руками, и это требует очень глубоких знаний в этой области
от эксперта.
1. Системный анализ и постановка задачи
.1 Общая информация о работе антивируса
Для обнаружения, удаления и защиты от
компьютерных вирусов разработаны специальные программы, которые позволяют
обнаруживать и уничтожать вирусы.
Такие программы называются антивирусными.
Современные антивирусные программы представляют собой многофункциональные
продукты, сочетающие в себе как превентивные, профилактические средства, так и
средства лечения вирусов и восстановления данных.
В работе антивирусов
можно выделить три составляющих:
1) Диагностика.
Антивирус проверяет все доступные для
вирусов места на жёстком диске компьютера, и если он обнаруживает вирус, то
оповещает об этом пользователя.
) Лечение.
Найдя вирус, антивирусная программа может
(по усмотрению пользователя):
А) Попытаться вылечить заражённый файл.
Б) Поместить его в карантин. То есть, если
этот файл ценен для вас и содержит какую-то важную информацию, его можно поместить
в папку карантина. В дальнейшем, вы можете попытаться его вылечить «вручную»
самостоятельно либо же с помощью специалиста, иногда это помогает.
В) Удалить инфицированный файл. Если
лечение файла оказалось невозможным, он либо безнадёжно испорчен вирусом либо
он сам является вирусом. Значит такой файл необходимо просто удалить с
компьютера.
Г) Вы можете не предпринимать никаких
действий. Иногда антивирус выдаёт ложную тревогу и если вы уверены, что
просканированный файл не является вирусом, то вы смело можете дать отбой своему
антивирусу.
) Профилактика.
Полноценные антивирусные программы, как
правило, действуют / защищают компьютер всё время / постоянно. То есть,
запускаются вместе с запуском операционной системы и проверяют на наличие
вирусов каждую запускаемую программу (файл) и если она содержит вирус или
вызывает какое-либо подозрение, то антивирус сразу же даёт вам об этом знать, и
далее предлагает вам на выбор принять решение что с этой программой необходимо
сделать: вылечить или поместить в карантин или же удалить её с компьютера, либо
продолжить работу не предпринимая никаких действий по отношению к данному
файлу.
В данной дипломном проекте будет
реализован один из функционалов антивирусной программы - диагностика.
Существует несколько способов диагностики
файла на зараженность вирусом. Но из всех методов антивирусной защиты можно
выделить две основные группы:
ü Сигнатурный анализ
ü эвристический анализ
Сигнатура (signature) - означает «подпись»,
или же в переносном смысле «характерная черта, нечто идентифицирующее».
Сигнатурный анализ заключается в выявлении характерных идентифицирующих черт
каждого вируса и поиска вирусов путем сравнения файлов с выявленными чертами.
Сигнатура вируса - совокупность черт,
позволяющих однозначно идентифицировать наличие вируса в файле (включая случаи,
когда файл целиком является вирусом).
Антивирусная база - совокупность сигнатур
известных вирусов. Задачу выделения сигнатур решают эксперты в области
компьютерной вирусологии, способные выделить код вируса из кода программы и
сформулировать его характерные черты в форме, наиболее удобной для поиска.
Лучшим же антивирусом будет тот, для которого сигнатура нового вируса была
выпущена раньше всех. Очень часто для обнаружения семейства похожих вирусов
используется одна сигнатура.
Важное дополнительное свойство сигнатур -
точное и гарантированное определение типа вируса. Данное свойство позволяет
занести в базу, как сигнатуры, так и способы лечения вируса. Если бы
сигнатурный анализ не давал ответа, что это за вирус, очевидно, лечение было бы
не возможно - слишком большим был бы риск совершить не те действия и вместо
лечения получить дополнительные потери информации.
Отрицательное свойство - для получения
сигнатуры необходимо иметь образец вируса. Следовательно, сигнатурный метод
непригоден для защиты от новых вирусов, т.к. до тех пор, пока вирус не попал на
анализ к экспертам, создать его сигнатуру невозможно. С момента появления
вируса в сети Интернет до выпуска первых сигнатур обычно проходит несколько
часов, и все это время вирус способен заражать компьютеры почти
беспрепятственно. Почти - потому что в защите от новых вирусов помогают
дополнительные средства защиты, рассмотренные ранее, а также эвристические
методы, используемые в антивирусных программах.
Сигнатурный анализ - это классический
способ, позволяющий обнаруживать и однозначно распознавать большинство
известных вирусов.
При сигнатурном анализе антивирус работает
по следующей схеме:
Каждый компьютерный антивирус содержит
антивирусную базу данных, то есть он знает все имеющиеся в наличии на
сегодняшний день вирусы (почти все) поимённо, можно сказать «в лицо». «Лицо»
этих вирусов - это так называемая сигнатура, то есть признаки по которым их
можно определить.
При работе антивируса (проверке файлов),
антивирус сверяет все сканируемые им файлы по своей базе данных и если
обнаруживается подозрительный файл, то он сразу срабатывает и «бъёт» тревогу.
Антивирусная база обновляется. Обновляется
она очень часто, иногда даже по несколько раз в день, потому что каждый день
появляется очень много новых вирусов; которые соответственно и заносятся в
антивирусную базу.
Эвристика - значит, «находить».
Эвристический анализ основывается на (весьма правдоподобном) предположении, что
новые вирусы часто оказываются похожи на какие-либо из уже известных. Поэтому в
антивирусных базах находятся сигнатуры для определения не одного, а сразу
нескольких вирусов. Следовательно, эвристический метод заключается в поиске
файлов, которые не полностью, но очень близко соответствуют сигнатурам
известных вирусов.
Преимущества: возможность обнаружить новые
вирусы еще до того, как для них будут выделены сигнатуры
Недостатки:
ü вероятность ошибочно
определить наличие в файле вируса, когда на самом деле файл чист - такие
события называются ложными срабатываниями;
ü невозможность лечения - и
в силу возможных ложных срабатываний, и в силу возможного неточного определения
типа вируса, попытка лечения может привести к большим потерям информации, чем
сам вирус, а это недопустимо;
ü низкая эффективность -
против действительно новаторских вирусов, вызывающих наиболее масштабные
эпидемии, этот вид эвристического анализа малопригоден.
Поиск вирусов, выполняющих подозрительные
действия.
Другой метод, основанный на эвристике,
исходит из предположения, что вредоносные программы так или иначе стремятся
нанести вред компьютеру, и основан на выделении основных вредоносных действий.
Например:
ü удаление файла;
ü запись в файл;
ü запись в определенные
области системного реестра;
ü открытие порта на
прослушивание;
ü перехват данных вводимых
с клавиатуры;
ü рассылка писем;
Выполнение каждого такого действия по
отдельности не является поводом считать программу вредоносной. Однако, при
выполнении программой последовательно нескольких таких действий, например,
записывает запуск себя же в ключ автозапуска системного реестра, перехватывает
данные вводимые с клавиатуры и с определенной частотой пересылает эти данные на
какой-то адрес в Интернет, значит эта программа, по меньшей мере,
подозрительна. Основанный на этом принципе эвристический анализатор постоянно
следит за действиями, которые выполняют программы.
Преимущества: возможность обнаруживать
неизвестные ранее вредоносные программы, даже если они не очень похожи на уже
известные (использование для проникновения на компьютер новую уязвимость, а
после этого - выполнять уже привычные вредоносные действия). Такую программу
может пропустить эвристический анализатор первого типа, но вполне может
обнаружить анализатор второго типа.
Недостатки:
ü ложные срабатывания;
ü невозможность лечения;
ü невысокая эффективность.
Если говорить об эвристическом методе -
антивирус анализирует программу, если он видит какой-либо подозрительный по его
мнению участок кода, то он тоже предупреждает об этом, но тут конечно не
невозможно дать 100%-ные гарантии, что та или иная подозрительная программа это
обязательно вирус, поэтому могут быть и ошибки, но всё-таки очень часто такие
подозрительные программы впоследствии действительно оказываются вредоносными.
В данном дипломном проекте будет
реализован один из функционалов антивируса, а именно поиск вирусов по
сигнатурам. Также система должна будет автоматизировано анализировать
зараженные файлы и выявлять их сигнатуры.
.2 Обоснование
необходимости создание системы
Как известно, сигнатурой вируса, можно
назвать последовательность байт характерных для этого вируса и отличающих
зараженную программу от «здоровых» и от других вирусных файлов зараженных
другим семейством вирусов.
Известно, что задачей по выявлению
вирусов, а также созданием сигнатур для них занимаются эксперты в это области.
Однако, данный процесс требует от вирусного аналитика достаточно глубоких
знаний в данной области. Эксперт вручную просматривает зараженный файл и ищет
подозрительные участки и определяет, какие действия выполняет вирус. Затем на
основе собранных данных по вирусу, а также анализу зараженного файла создает
сигнатуру для этого вируса, для того чтобы другие пользователи могли гораздо
быстрее определить заражен ли файл или нет. Естественно, что данная работа по
выявлению сигнатуры может отнимать достаточно много времени у эксперта. Это
время можно сократить, если вместо человека данную задачу будет решать система.
Система, которая могла бы сама анализировать зараженные файлы и самое главное
создать их сигнатуры. А для этого на систему необходимо будет перенести часть
знаний эксперта в области вирусологии. Несомненно, что система, которая
выявляет сигнатуры вирусов, в разы способна сократить работу аналитика, а также
уменьшить время появления новых сигнатур в базе данных антивируса и тем самым
обезопасить пользователей персональных компьютеров.
1.3 Постановка задачи на создание системы
Наименование программы
Наименование программы: «Система
автоматического создания сигнатур исполняемых файлов»
Назначение и область применения
Программа предназначена для выявления
сигнатур в ре файлах зараженных одним семейством вирусов. Также программа иметь
возможность проверять файл на предмет наличия вируса по имеющимся сигнатурам.
Также в программе предусмотрен собой графический интерфейс для удобства в использовании.
Требования к функциональным характеристикам
Программа должна обеспечивать возможность
выполнения перечисленных ниже функций:
1) Требования к программе
ü Добавление/удаление фалов
в список зараженных обрабатываемых на выявление сигнатуры.
ü Выявление сигнатуры
вируса из списка зараженных файлов.
ü Добавление сигнатуры в
список сигнатур.
ü Хранение сигнатур.
ü Добавление/удаление
файлов в список проверяемых
ü Проверка в файлах, из
списка проверяемых на наличие сигнатур.
ü Предоставление краткой отчетности
о проверки.
2) Требования к обеспечению надежного функционирования
программы
Надежное (устойчивое) функционирование
программы должно быть обеспечено выполнением Заказчиком совокупности
организационно-технических мероприятий, перечень которых приведен ниже:
А) организацией бесперебойного питания
технических средств;
Б) использованием лицензионного
программного обеспечения;
В) регулярным выполнением рекомендаций
Министерства труда и социального развития РБ.
3) Отказы из-за некорректных действий пользователей системы
Отказы программы вследствие некорректных
действий пользователя при взаимодействии с программой через оконное приложение
недопустимы.
Условия эксплуатации
1) Климатические условия эксплуатации
Климатические условия эксплуатации, при
которых должны обеспечиваться заданные характеристики, должны удовлетворять
требованиям, предъявляемым к техническим средствам в части условий их
эксплуатации
2) Требования к квалификации и численности
персонала
Минимальное количество персонала,
требуемого для работы программы, должно составлять не менее 1 штатной единицы -
конечный пользователь программы. Требования к конечному пользователю:
А) базовое знание ПК
Б) базовые знания о сигнатурах
(необязательно)
3) Требования к составу и параметрам технических средств
В состав технических средств должно входить IВМ-совместимый
персональный компьютер (ПЭВМ):
А) процессор Pentium-2.0Hz;
Б) оперативную память объемом, 1Гигабайт, не менее;
В) HDD 100 мб (может варьироваться в зависимости от
количества сигнатур);
Г) операционная система Windows XP/ VISTA/7;
4) Требования к исходным кодам и языкам
программирования
Дополнительные требования не
предъявляются.
5) Требования к программным средствам,
используемым программой
Системные программные средства,
используемые программой, должны быть представлены лицензионной локализованной
версией операционной системы Windows XP/ VISTA/ 7.
6) Требования к защите информации и программ
Требования к защите информации и программ
не предъявляются.
7) Специальные требования
При добавлении в нового файла в список
обрабатываемых файл должен быть зараженным. Предполагается, что программа не
имеет возможности определять заражен файл или нет, если он находится в списке
обрабатываемых.
Требования к программной документации
Состав программной документации должен
включать в себя пояснительную записку со всеми имеющимися приложениями.
.4 Описание аналогов
В ходе дипломного проекта реализуется
программа, которая выполняет часть функционала антивируса. Следовательно, в
качестве аналогов можно отметить всем известные антивирусы: Dr. Web 9.0,
Kaspersky Internet Security, Avast! Internet Security, NOD32 Antivirus 7, AVG Internet Security 2014. Обычному
пользователю тяжело понять какой из этих антивирусов лучше, точнее какой из них
лучше будет соответствовать запросам пользователя. Для этого необходимо
произвести небольшое сравнение. Наиболее простыми, и в то же время необходимыми
критериями сравнения будут: сравнение функционала и сравнение эффективности
выполнения.
Функциональность антивирусов
В основной своей массе антивирусы имеют одни и те же функции.
Это обусловлено тем, что исполняют они одни и те же задачи - проверка,
идентификация вирусов и их устранение. Но даже, несмотря на эту их схожесть,
есть некоторая разница между функционалом, который разработчик внедряет в свой
продукт, поэтому стоит тщательно подбирать ту утилиту, которая максимально
будет соответствовать требованиям пользователя. Ниже приведена таблица 1.1
отображающая функционал разных антивирусных программ.
Таблица 1.1 - Сравнение антивирусных
программ
|
Dr. Web 9.0
|
AVG IS 2014
|
Kaspersky IS
|
Avast! IS
|
NOD32 AV 7
|
|
Защита от
вирусов
|
|
|
|
|
|
|
Защита от
шпионского ПО
|
|
|
|
|
|
|
Защита от
рекламного ПО
|
|
|
|
|
|
|
Скан по
расписанию
|
|
|
|
|
|
|
Проверка
почтовых сообщений
|
|
|
|
|
|
|
Проверка
траффика
|
|
|
|
|
|
|
Эвристическая
защита
|
|
|
|
|
|
|
Превентивная
защита
|
|
|
|
|
|
|
Возможность
установки на зараженный ПК
|
|
|
|
|
|
|
Функция
самозащиты
|
|
|
|
|
|
|
Диалоговые
окна
|
|
|
|
|
|
|
Круглосуточная
тех. поддержка
|
|
|
|
|
|
|
Автоматическое
обновление баз
|
|
|
|
|
|
|
«Облачные»
сервисы
|
|
|
|
|
|
|
Защита
личных данных
|
|
|
|
|
|
|
Сканер
архивов
|
|
|
|
|
|
|
«Безопасный
поиск»
|
|
|
|
|
|
|
Защита IM
сервисов
|
|
|
|
|
|
|
Защита от
фишинга
|
|
|
|
|
|
|
Проверка
ссылок
|
|
|
|
|
|
|
Шифрование
файлов
|
|
|
|
|
|
|
Блокировка
распорстранителей спама и пр.
|
|
|
|
|
|
|
Оптимизация
работы ПК
|
|
|
|
|
|
|
Блокировка
хакерских атак
|
|
|
|
|
|
|
Безопасность
онлайн покупок / банкинга
|
|
|
|
|
|
|
Родительский
контроль
|
|
|
|
|
|
|
«Безопасная
среда»
|
|
|
|
|
|
В плане требовательности к ресурсам
компьютера, эти антивирусы тоже отличаются. Но как показала практика - если
компьютер без проблем функционирует на Windows 7/8, то особых проблем ни с
одним из антивирусов возникнуть не должно.
Но все равно по количеству потребляемых
ресурсов антивирусы разместились вот таким образом (1 место - самая высокая
«прожерливость», 5 место - самая низкая).
1. Kaspersky Internet Security
2. NOD32 Antivirus 7
. Avast! Internet Security
. AVG Internet Security 2014
. Dr. Web 9.0
Эффективность исполнения
своих обязанностей
Каждый антивирус справляется со своими
обязанностями по-разному. Это зависит не только от того, какими ресурсами
оперирует программа, но и от того, какая база вирусов используется компанией,
насколько прост к ней доступ, насколько часто она обновляется и множество
других факторов. Но, как ни крути, а существует КРВ (Комплекс Распространенных
Вирусов). В КРВ продемонстрированы самые распространенные виды вредоносного
кода и программ, на которые может натолкнуться пользователь. Именно на основе
этого «сборника нечисти», проводились тесты антивирусов. И вот, какие
результаты они показали (количество пойманных антивирусом угроз в процентах от
общего количества) (см. таблицу 1.2):
Таблица 1.2 - Результат тестов по
обнаружению вирусных программ
|
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.