Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

антивирус программный энергетический

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

Одним из самых распространенных способов для несанкционированного доступа к информации являются компьютерные вирусы. Но современные компьютерные вирусы позволяют не только считывать важные данные, а также может препятствовать нормальной работе компьютера, разрушать файловую структуру и наносить ущерб информации хранимой на персональном компьютере. Вирусы, получившие широкое распространение в компьютерной технике, взбудоражили весь мир. Многие пользователи компьютеров весьма обеспокоены тем, что с помощью компьютерных вирусов злоумышленники взламывают сети, грабят банки, крадут интеллектуальную собственность. Все чаще в системах массовой информации появляются заявления об разного рода проделках неких хакеров или IT-хулиганов, о появлении все более совершенных саморазмножающихся программ. Компьютерные вирусы влияют на скорость работы и производительность системы, на выполнение отдельных заданий затрачивается больше времени, чем прежде. Некоторые из вирусов оказывают настолько большой вред, что вся система может «полететь» и перестать работать и в результате будут потеряны данные. Если давать определение компьютерному вирусу, то оно будет выглядеть примерно так: компьютерный вирус - это самокопирующаяся программа, разработанная с целью тиражирования самой себя помимо ведома и против воли пользователей. Распространение вирусов реализуется через присоединение их к другим программам, документам или путём записи в сектор начальной загрузки диска.

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

1) Эксперты зондируют интернет в поиске новых вирусов

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

3) Добавляют эту сигнатуру в базу данных сигнатур антивируса

4) Антивирус ищет в файлах сигнатуры имеющиеся в базе.

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



1. Системный анализ и постановка задачи

1.1 Общая информация о работе антивируса

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

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

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

1) Диагностика.

Антивирус проверяет все доступные для вирусов места на жёстком диске компьютера, и если он обнаруживает вирус, то оповещает об этом пользователя.

2) Лечение.

Найдя вирус, антивирусная программа может (по усмотрению пользователя):

А) Попытаться вылечить заражённый файл.

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

В) Удалить инфицированный файл. Если лечение файла оказалось невозможным, он либо безнадёжно испорчен вирусом либо он сам является вирусом. Значит такой файл необходимо просто удалить с компьютера.

Г) Вы можете не предпринимать никаких действий. Иногда антивирус выдаёт ложную тревогу и если вы уверены, что просканированный файл не является вирусом, то вы смело можете дать отбой своему антивирусу.

3) Профилактика.

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

В данной дипломном проекте будет реализован один из функционалов антивирусной программы - диагностика.

Существует несколько способов диагностики файла на зараженность вирусом. Но из всех методов антивирусной защиты можно выделить две основные группы:

ь Сигнатурный анализ

ь эвристический анализ

Сигнатура (signature) - означает «подпись», или же в переносном смысле «характерная черта, нечто идентифицирующее». Сигнатурный анализ заключается в выявлении характерных идентифицирующих черт каждого вируса и поиска вирусов путем сравнения файлов с выявленными чертами.

Сигнатура вируса - совокупность черт, позволяющих однозначно идентифицировать наличие вируса в файле (включая случаи, когда файл целиком является вирусом).

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

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

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

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

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

Каждый компьютерный антивирус содержит антивирусную базу данных, то есть он знает все имеющиеся в наличии на сегодняшний день вирусы (почти все) поимённо, можно сказать «в лицо». «Лицо» этих вирусов - это так называемая сигнатура, то есть признаки по которым их можно определить.

При работе антивируса (проверке файлов), антивирус сверяет все сканируемые им файлы по своей базе данных и если обнаруживается подозрительный файл, то он сразу срабатывает и «бъёт» тревогу.

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

Эвристика - значит, «находить». Эвристический анализ основывается на (весьма правдоподобном) предположении, что новые вирусы часто оказываются похожи на какие-либо из уже известных. Поэтому в антивирусных базах находятся сигнатуры для определения не одного, а сразу нескольких вирусов. Следовательно, эвристический метод заключается в поиске файлов, которые не полностью, но очень близко соответствуют сигнатурам известных вирусов.

Преимущества: возможность обнаружить новые вирусы еще до того, как для них будут выделены сигнатуры

Недостатки:

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

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

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

Поиск вирусов, выполняющих подозрительные действия.

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

Например:

ь удаление файла;

ь запись в файл;

ь запись в определенные области системного реестра;

ь открытие порта на прослушивание;

ь перехват данных вводимых с клавиатуры;

ь рассылка писем;

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

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

Недостатки:

ь ложные срабатывания;

ь невозможность лечения;

ь невысокая эффективность.

Если говорить об эвристическом методе - антивирус анализирует программу, если он видит какой-либо подозрительный по его мнению участок кода, то он тоже предупреждает об этом, но тут конечно не невозможно дать 100%-ные гарантии, что та или иная подозрительная программа это обязательно вирус, поэтому могут быть и ошибки, но всё-таки очень часто такие подозрительные программы впоследствии действительно оказываются вредоносными.

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

1.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) Специальные требования

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

Требования к программной документации

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

1.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

3. Avast! Internet Security

4. AVG Internet Security 2014

5. 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.2 Выбор среды и языка разработки

В качестве языка разработки был выбран C#. C# является языком программирования, который разработан для создания множества приложений, работающих в среде.NET Framework. Язык C# прост, типобезопасен и объектно-ориентирован. Благодаря множеству нововведений C# обеспечивает возможность быстрой разработки приложений, но при этом сохраняет выразительность и элегантность, присущую С-подобным языкам.

В качестве среды разработки была выбрана среда Microsoft Visual Studio. Visual Studio - это полный набор инструментов и служб для создания различных приложений как для платформы Microsoft, так и для других платформ. Visual Studio также позволяет связать все ваши проекты, группы и всех заинтересованных лиц. Теперь ваша группа сможет работать более гибко практически где угодно независимо от используемого средства разработки (в том числе Eclipse и Xcode). Вы сможете разрабатывать важные приложения.NET, писать невероятно быстрый код с помощью C++ AMP или тестировать и отлаживать облачное приложение на HTML или JavaScript, которое работает на множестве устройств - присоединитесь к миллионам разработчиков во всем мире, которые выбрали Visual Studio как основную среду разработки.

Visual 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) секций. Заголовки содержат служебную информацию, описывающую различные свойства исполняемого файла и его структуру. Секции содержат данные, которые размещаются в адресном пространстве процесса во время загрузки исполняемого файла в память.

PE-файлы являются файлами с относительной загрузкой, т.е. теоретически могут размещаться в пространстве адресов 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);

ь 4-байтовое (DWORD) смещение от начала файла до заголовка PE, находяшееся по смещению 0x3C (e_lfanew).

При загрузке 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 заголовок

USHORT e_magic; // Магическое число

USHORT e_cblp; // Количество байт на последней странице файла

USHORT e_cp; // Количество страниц в файле

USHORT e_crlc; // Relocations

USHORT e_cparhdr; // Размер заголовка в параграфах

USHORT e_minalloc; // Minimum extra paragraphs needed

USHORT e_maxalloc; // Maximum extra paragraphs needed

USHORT e_ss; // Начальное (относительное) значение регистра SS

USHORT e_sp; // Начальное значение регистра SP

USHORT e_csum; // Контрольная сумма

USHORT e_ip; // Начальное значение регистра IP

USHORT e_cs; // Начальное (относительное) значение регистра CS

USHORT e_lfarlc; // Адрес в файле на таблицу переадресации

USHORT e_ovno; // Количество оверлеев

USHORT e_res[4]; // Зарезервировано

USHORT e_oemid; // OEM identifier (for e_oeminfo)

USHORT e_oeminfo; // OEM information; e_oemid specific

USHORT e_res2 [10]; // Зарезервировано

LONG 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;

IMAGE_FILE_HEADER FileHeader;

IMAGE_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 {

DWORD VirtualAddress;

DWORD 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	VirtualAddress	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 из необязательного заголовка.

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

2.4 Способы заражения файлов

Общее положение

Существует множество методов заражения (то есть записи кода вируса в код программы без потери работоспособности последнего) файлов формата Portable Executeable. Есть простые методы, которые с лёгкостью отлавливаются антивирусами, есть очень сложные.

Существует три основных метода заражения PE EXE:

1) внедрение в заголовок;

2) расширение последней секции;

3) добавление новой секции.

Внедрение в заголовок

Рассмотрим первый метод заражения PE EXE файлов, а именно запись в заголовок жертвы. Он не самый простой, но довольно интересный. Небезызвестный вирус win95.CIH (Чернобыль) записывал свою загрузочную процедуру именно в то место, которое будет рассмотрено ниже.

«Запись в заголовок» - это не совсем верное утверждение, так как рассматриваемое пространство находится не в самом заголовке. На рисунке 2.1 изображена примерная структура PE EXE файла.

Рисунок 2.1 Примерная структура РЕ файла

Участок, помеченный голубым - это и есть «дыра» в которую записывается тело «вируса». Как видно из рисунка, она находится между последним элементом (element n) таблицы объектов и смещением первой секции. Откуда же эта «дыра» взялась? Дело в том, что существует такое понятие, как выравнивание. За эту величину отвечает поле File Align в PE Header по смещению 3Ch и имеющее тип DWORD. В большинстве случаев оно равно 200h и это означает, что секции в файле должны быть расположены по адресам кратным данному значению. Большинство линкеров, выставляют физический адрес первой секции равным 600h, следовательно, первая секция располагается в файле по смещению 600h. Заголовок файла содержит намного меньше информации, чем 600h байт, вот и получается в результате «пробел» - чистый клочок бумаги, на который можем написать вирус.

Для того чтобы найти это свободное место необходимо:

1) узнать некоторые значения из PE Header;

2) узнать некоторые значения из Object Table;

3) произвести парочку нехитрых арифметических операций.

Вот нужные поля из заголовка 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.

1) находим размер PE заголовка (PE Header)

2) находим размер таблицы объектов, для этого:

А) берем количество элементов Object Table (PE Header)

Б) умножаем на размер одного элемента, т.е. на 40

3) к виртуальному адресу (далее VA) файла-жертвы прибавим сумму результатов вычислений первого и второго пунктов, получим VA искомой области.

4) находим физическое смещение первой секции:

А) находим смещение первого элемента таблицы объектов, это конец заголовка PE и начало Object Table

Б) получаем из этого элемента физическое смещение первой секции и добавляем к нему VA файла - жертвы

5) Вычислим разность результатов четвертого и третьего пунктов, получаем размер искомой области

Расширение последней секции

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

Каждый элемент описывает одну секцию. В Object Table элементы идут последовательно друг за другом без промежутков, но необязательно в порядке возрастания Physical Offset и Section RVA. Т.е. последний элемент не всегда описывает последнюю секцию, хотя в большинстве случаев это так (под «последней секцией» подразумевается секция, которая физически и виртуально находится в файле последней). При поиске свободного места в заголовке производился поиск физического смещение первой секции, т.е. секции, которая находится в файле первой физически. Здесь же понадобится физическое смещение последней и смещение элемента (из Object Table) ее описывающего - для того, чтобы пропатчить некоторые значения. Найдем самое большое значение Physical Offset из всех элементов. Элемент, содержащий это значение, и будет нам нужен. Так же понадобится найти элемент, который содержит наибольшее значение Virtual RVA. Дело в том, что секция может быть физически в файле последней, а вот виртуально, т.е. в памяти, она может расположиться где угодно, например первой. Тогда при ее расширении можно затереть последующую секцию в памяти. Вообще такое довольно редко встречается, но вирус на то и вирус, чтобы предусмотреть все возможные варианты. Затем нам нужно проверить, принадлежат ли наибольшие значения Physical Offset и Virtual RVA одному элементу, если да, то секция является последней и физически в файле и виртуально в памяти.