Разработка библиотеки программных компонентов определения форматов файлов и ее использование в системах безопасности промышленных сетей

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

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

Введение

интерфейс программный компьютерный сеть

Автоматизированные системы управления различными технологическими процессами современных промышленных предприятий - это сложные программно-аппаратные комплексы, в которых применяются серверы приложений, серверы баз данных, автоматизированные рабочие места на основе персональных компьютеров и мобильных устройств, программируемые логические контроллеры различных производителей. Информационная безопасность АСУ ТП стала предметом пристального внимания после появления вируса, получившего известность как Stuxnet, который нанёс серьёзный ущерб иранской ядерной программе в 2010 году. Stuxnet стал первым компьютерным вирусом, который способен перехватывать и модифицировать поток данных между ПЛК и рабочими станциями SCADA-систем. Данный инцидент обратил внимание специалистов по информационной безопасности на весьма новую для них область, которая ранее казалась недоступной для атак по причине физической изолированности таких сетей и использования весьма специфичного оборудования. В настоящее время, для предотвращения нарушения работы промышленного оборудования создаются различные системы, призванные своевременно обнаружить и нейтрализовать вредоносное ПО во внутреннем контуре промышленных сетей.

Объектом исследования данной выпускной квалификационной работы являются некоторые вопросы безопасности систем АСУТП, к числу которых относятся разработка систем обнаружения вторжений и аномалий в сетевом трафике. Данные системы позволяют своевременно обнаруживать и предотвращать инциденты в сфере информационной безопасности промышленных компьютерных сетей.

Целью ВКР является разработка библиотеки программных компонентов для определения форматов файлов и возможностей исполняемых файлов. Данная библиотека является частью системы обнаружения вторжений и аномалий в сетевом трафике, которая работает на участке между программируемыми логическими контроллерами и рабочими станциями SCADA-систем. Для достижения данной цели необходимо провести разработку методики определения форматов файлов, выполнить поиск существующих аналогов и разработать программный код библиотеки. Итоговый проект представляет собой библиотеку программных компонентов, решающих задачу определения форматов файлов, а также задачу проведения анализа исполняемых файлов на предмет характера их активности.

1. Аналитический обзор

1.1 Описание промышленных компьютерных сетей

Библиотека программных компонентов для определения форматов файлов является частью системы обнаружения вторжения и аномалий сетевого трафика для промышленных сетей (англ. Intrusion Detection System (IDS)). Данная система отслеживает состояние сетевого трафика в промышленных сетях между программируемыми логическими контроллерами (ПЛК) и рабочими станциями SCADA-систем.

Промышленная сеть Ethernet - это обычная сеть Ethernet, элементами которой являются в основном ПЛК, установленные на промышленном оборудовании, взаимодействующие с рабочими станциями SCADA-систем с помощью промышленных протоколов. К подобным протоколам относятся, например, Modbus, Profibus, Siemens-S7, которые в свою очередь, работают поверх TCP/IP. Сам контроллер - это миниатюрный компьютер со своей операционной системой и программой выполнения, предназначенный для управления каким-либо промышленным агрегатом, станком, насосом, сборочной линией и др. Наиболее распространёнными контроллерами являются контроллеры фирм Siemens, Shneider, Vipa, Advantech, ABB, Delta Electronics. Операционная система на ПЛК-либо собственной разработки производителя, информация о которой малодоступна, либо открытая, например Lunix, VxWorks, либо QNX, WindowsCE или WindowsXP. Архитектура контроллеров обычно является модульной: как правило существует главный модуль к которому подключаются различные дополнительные модули ввода-вывода управляющие различными компонентами промышленного оборудования, различные датчики, элементы человеко-машинного интерфейса. Основной режим работы ПЛК - это длительное автономное использование, часто в неблагоприятных условиях окружающей среды, без специального обслуживания и практически без вмешательства человека.

Система обнаружения вторжений и аномалий сетевого трафика в данной области обычно устанавливается либо на рабочей станции SCADA-систем, либо между ней и ПЛК. Одной из её задач является анализ сетевого трафика, а именно, определение содержимого сетевых пакетов на предмет выявления попыток передачи исполняемых файлов вредоносного ПО и их компонентов.

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

1.2 Постановка задачи по анализу файлов, передаваемых по промышленным сетям и общие требования к реализуемой библиотеке

При выполнении инспекции сетевого трафика необходимо выявлять, прежде всего, исполняемые файлы, ибо именно они могут являться вредоносным программным обеспечением. Так как наиболее распространёнными операционными системами на ПЛК являются ОС на основе Windows и Linux, то наибольший интерес представляют исполняемые файлы форматов ELF и PE. Вредоносное программное обеспечение, как правило, использует сеть для передачи данных и собственного распространения. Также оно может внедряться в компоненты операционной системы, либо в компоненты стороннего ПО, установленного на устройстве. Для выявления таких возможностей необходимо проводить анализ структуры самого файла, что также входит в круг задач, решаемых библиотекой. Ещё одной немаловажной задачей является детектирование исполняемых скриптов командной оболочки типов bash и shell, которые могут выполнять довольно обширный набор команд на целевой системе.

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

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

1) определения формата файла: выявление исполняемых файлов (форматов ELF и PE), загрузочных файлов-образов (U-boot image), компонентов файловых систем (Squashfs), структурированных файлов (ICO, GIF, TAR, GZIP, ZIP), исполняемых скриптов (sh, bash);

2) определение типа исполняемых файлов: исполняемый файл с сетевыми возможностями, драйвер, модуль ядра ОС;

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

1) определение следующих типов файлов: ELF, PE, U-boot, Squashfs.NET, компоненты COM\DCOM, bash, shell, ICO, GIF, TAR, ZIP, GZIP;

2) определение следующих типов исполняемых файлов по функционалу: файл с сетевыми возможностями, драйвер, модуль ядра;

3) библиотека должна реализовывать идиому Zero-Copy (не создавать внутри себя копий анализируемых данных), не должна изменять сами анализируемые данные. Данное требование продиктовано соображениями безопасности и быстродействия;

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

5) библиотека должна собираться с помощью системы сборки Сmake для платформ Windows и Linux аналогично с основным приложением, которое её использует;

6) для удобства использования в состав исходного кода библиотеки должен входить набор примеров использования интерфейсов библиотеки обоих уровней;

1.3 Обзор существующих решений

На данный момент в сети Internet встречаются следующие библиотеки прикладного программирования, выполняющие похожие задачи: libmagic, Chilkat.

Библиотека libmagic является свободно распространяемым программным обеспечением с собственной открытой лицензией. Данный программный продукт располагает функционалом для определения множества форматов файлов и является кроссплатформенным. В комплекте с библиотекой поставляются набор примеров использования и описание программного интерфейса библиотеки. Также большим достоинством данной библиотеки является тот факт, что она входит в состав официального репозитория Linux Ubuntu, что говорит о её надёжности и проверенности тестированием. Недостатки библиотеки: она имеет только один уровень абстракции интерфейса, который не позволяет использовать отдельные её компоненты самостоятельно; библиотека требует от пользователя создания и удаления своих собственных структур данных, то есть управляет ресурсами; функционал для определения типов исполняемых файлов отсутствует.

Библиотека от компании Chilkat позволяет определять различные типы файлов, по так называемым «magic bytes». Пример размещённый на сайте производителя даёт весьма ограниченное представление о функционале библиотеки. Данный продукт является проприетарным и без покупки лицензии определить насколько он соответствует требованиям проекта не представляется возможным.

Ещё одним, близким по функционалу программным компонентом является pe-parser от проекта TrailOfBits. Он представляет собой небольшой программный модуль, основной функцией которого является парсинг файлов формата PE. Основным недостатком модуля является тот факт, что в процессе своей работы он копирует довольно много данных, а также в нем отсутствует какой-либо дополнительный функционал, кроме парсинга формата PE.

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

1.4 Выбор технологий реализации

Языком программирования для реализации данного проекта является язык С/С++ с использованием возможностей стандарта С++11. Выбор данного языка обусловлен его объектно-ориентированными возможностями с одной стороны и тем фактом, что основной продукт, использующий разрабатываемую библиотеку также написан на этом языке. С/С++ это компилируемый язык со статической типизацией, который позволяет реализовывать высокоуровневую архитектуру проекта с использованием всех возможностей объектно-ориентированного подхода и строить удобные лаконичны интерфейсы. Также данный язык подходит для системного и сетевого программирования. Стандарт С++11 добавляет множество новых удобных механизмов и возможностей, облегчающих написание эффективных и безопасных программ.

В качестве среды разработки выбрана IDE QtCreator. Её основными достоинствами являются бесплатность использования и широкий набор встроенных средств, позволяющих эффективно редактировать код. Она включает в себя графический интерфейс для отладчика и визуальные средства разработки графического интерфейса. Поддерживает следующие компиляторы: GCC, MSVC, Clang, MinGW и другие. QtCreator поддерживает следующие системы сборки: autotools, qmake, cmake, а также системы контроля версии Git, Mercurial, Subversion.

В качестве компилятора выбран GCC - набор компиляторов для различных языков программирования, разработанный проектом GNU. GCC представляет собой свободное программное обеспечение, распространяемое фондом свободного программного обеспечения (FSF) на условиях лицензий GNU GPL и GNU LGPL. Он используется в качестве стандартного компилятора для UNIX-подобных операционных систем.

Отладчик - GDB переносимый отладчик, созданный также в рамках проекта GNU, который может работать на UNIX-подобных системах и позволяет выполнять отладку различных языков программирования, включая Си, C++. GDB - свободное программное обеспечение, распространяемое на условиях лицензии GPL. GDB предлагает обширные средства для слежения и контроля за выполнением исполняемых файлов. Пользователю предоставляется возможность изменять внутренние переменные программы, а также вызывать функции независимо от стандартного поведения программы. GDB способен выполнять отладку исполняемых файлов в формате a.out, COFF (в том числе исполняемые файлы Windows), ECOFF, XCOFF, ELF, использовать отладочную информацию в различных форматах, таких как stabs, COFF, ECOFF, DWARF, DWARF2. Наибольшие возможности отладки предоставляет формат DWARF2. GDB может быть скомпилирован для поддержки приложений нескольких целевых платформ и может переключаться между ними во время отладочной сессии. Целевые платформы, на которых GDB не может быть запущен, в частности встроенные системы, могут поддерживаться с помощью встроенного симулятора (процессоры ARM, AVR), либо приложения для них могут быть скомпилированы с участием специальных подпрограмм, обеспечивающих удаленную отладку под управлением GDB-server, запущенном на компьютере разработчика.

Система сборки CMake - это кроссплатформенная система автоматизации сборки программного обеспечения из исходного кода. CMake не занимается непосредственно сборкой, она генерирует файлы управления сборкой для разных систем. Для Unix это makefile для системы сборки make, для Windows это файлы projects/solutions (.vcxproj/.vcproj/.sln) для сборки с помощью Visual C++.

1.5 Описание форматов файлов, используемых в промышленных сетях

Описание формата ELF

Описание формата ELF представлено в [1]. Формат ELF - это формат объектных файлов для операционной системы UNIX. Объектные файлы могут быть трёх видов: релоцируемые(relocatable) - предназначены для статической линковки с другими объектными файлами; исполняемые (executable) - предназначенные создания образа процесса и его исполнения; разделяемые (shared object) - предназначенные для динамической линковки в качестве динамических библиотек. Общая структура файла представлена на рисунке 1.1.



Рисунок 1.1. Структура файла формата ELF

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

В самом начале файла расположен заголовок ELF-header. Набор полей заголовков представлен в таблице 1.1.

Таблица 1.1. Поля заголовка ELF-header

Имя	Описание
e_ident[]	Массив 16 байт, предназначен для идентификации файла. Первые четыре байта в массиве содержат сигнатуру файла: 0x7f 0x45 0x4c 0x46.
e_type	Тип файла.
e_machine	Архитектура аппаратной платформы, для которой файл создан.
e_version	Номер версии формата.
e_entry	Точка входа.
e_phoff	Смещение до таблицы заголовков программы.
e_shoff	Смещение до таблицы заголовков разделов.
e_flags	Набор флагов.
e_ehsize	Размер заголовка файла.
e_phentsize	Размер каждого заголовка программы.
e_phnum	Число заголовков программы.
e_shentsize	Размер каждого заголовка разделов.
e_shnum	Число заголовков разделов.
e_shstrndx	Индекс записи в таблице разделов, указывающей на таблицу названий разделов.

Поле e_type может принимать значения, указанные в таблице 1.2.

Таблица 1.2. Значения поля e_type

Имя	Значение	Описание
ET_NONE	0	-
ET_REL	1	Релоцируемый
ET_EXEC	2	Исполняемый
ET_DYN	3	Разделяемый
ET_CORE	4	Файл ядра
ET_LOPROC	0xff00	Зарезервировано
ET_HIPROC	0xffff	Зарезервировано

По смещению, указанному в поле e_phoff заголока ELF-header расположен массив заголовков Program header, каждый элемент которого содержит информацию, которая относится непосредственно к процессу создания образа процесса при его запуске. Каждый заголовок содержит набор полей, представленный в таблице 1.3.

Таблица 1.3. Поля заголовка Program header

Имя	Описание
p_type	Тип сегмента и его интерпретация.
p_offset	Смещение от начала файла.
p_vaddr	Виртуальный адрес, по которому сегмент загружается в память при запуске процесса.
p_paddr	Не используется.
p_filesz	Размер сегмента в байтах в файле.
p_memsz	Размер сегмента в байтах в памяти процесса.
p_flags	Набор флагов.
p_align	Выравнивание.

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

Таблица 1.4. Поля заголовка секции

Имя поля	Описание
sh_name	Имя секции, представленное индексом в таблице строк.
sh_type	Тип секции.
sh_flags	Набор флагов.
sh_addr	Адрес загрузки секции в память процесса.
sh_offset	Смещение от начала файла до начала секции.
sh_size	Размер секции в байтах.
sh_link	Индекс ссылки.
sh_info	Дополнительная информация. Зависит от поля sh_type.
sh_addralign	Выравнивание.
sh_entsize	Фиксированный размер секции.

ELF - файл может содержать следующие секции:

1) bss - Служит для хранения неинициализированных переменных или представления области памяти. В момент запуска программы заполнена нулями.

2) data - Содержит инициализированные данные программы.

3) debug - Содержит отладочную информацию.

4) dynamic - Содержит информацию для динамической линковки.

5) dynstr - Содержит набор строк, которые представляют собой символьные имена, необходимые для динамической линковки.

6) dynsym - Содержит символьную таблицу для динамической линковки.

7) init - Содержит информацию, необходимую для инициализации процесса. Используется до вызова точки входа (main).

8) shstrtab - Содержит список имён секций.

9) symtab - Содержит символьную таблицу.

10) text - Содержит набор инструкций, составляющих программу.

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

Таблица 1.5. Поля структуры таблицы символов

Имя	Описание
st_name	Индекс строки с именем в таблице строк.
st_value	Значение символа (может быть адресом, индексом и т.п.).
st_info	Информация о типе и связывании символа.
st_other	Зарезервировано.

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

Описание формата PE

Формат PE (Portable Executable) - это формат исполняемых файлов, объектного кода и динамических библиотек, который используется в различных версиях операционной системы Microsoft Windows. Он представляет собой структуру данных, содержащую всю информацию, необходимую PE-загрузчику для отображения файла в память. Исполняемый код включает в себя ссылки для связывания динамически загружаемых библиотек, таблицы импорта и экспорта API функций, данные для управления ресурсами и данные локальной памяти потока (TLS). Общая структура файла представлена на рисунке 1.2.



Рисунок 1.2. Структура файла формата PE

Файл формата PE состоит из набора заголовков и секций с данными. К заголовкам относятся IMAGE_DOS_HEADER, IMAGE_FILE_HEADER, IMAGE_OPTIONAL_HEADER. Заголовок IMAGE_DOS_HEADER унаследован от операционной системы MS-DOS и в версиях для ОС Windows большинство его полей не используются. Сразу за ним расположен набор «магических байт», идентифицирующий формат PE для ОС Windows. Далее расположен обязательный заголовок IMAGE_FILE_HEADER. Поля данного заголовка перечислены в таблице 1.6.

Таблица 1.6. Поля заголовка IMAGE_FILE_HEADER

Имя	Описание
Machine	Тип архитектуры целевой системы.
NumberOfSections	Число секций в таблице секций.
TimeDateStamp	Время создания файла.
PointerToSymbolTable	Смещение до таблицы символов.
NumberOfSymbols	Число записей в таблице символов.
SizeOfOptionalHeader	Размер опционального заголовка.
Characteristics	Набор флагов.

Каждый файл-образ должен содержать заголовок IMAGE_OPTIONAL_HEADER. Слово «OPTIONAL» в имени заголовка говорит о том, что не все файлы формата PE содержат этот заголовок. Размер этого заголовка не фиксирован, его можно узнать из поля SizeOfOptionalHeader заголовка IMAGE_FILE_HEADER. В начале содержится набор «магических байт», которые идентифицируют битность архитектуры: 0x10b для 32-х битной и 0x20b для 64-х битной. Заголовок содержит три основных раздела: стандартный набор полей (англ. Standard fields), раздел для OC Windows (англ. Windows-specific fields), директории данных (англ. Data directories). Стандартный набор полей содержит поля определённые для всех реализаций формата COFF (унаследован от UNIX). Раздел для OC Windows содержит поля, специфичные только для ОС Windows. Директории данных, это набор структур, каждая из которых содержит адрес и размер тех или иных таблиц (например, таблиц импорта и экспотра), которые используются операционной системой. Стандартный набор полей представлен в таблице 1.7.

Таблица 1.7. Стандартный набор полей

Имя	Описание
Magic	Идентификатор архитектуры: 0x10B при 32-х битной архитектуре, 0x20B при 64-х битной.
MajorLinkerVersion	Старшая версия линкера.
MinorLinkerVersion	Младшая версия линкера.
SizeOfCode	Размер секции кода.
SizeOfInitializedData	Размер секции, содержащей инициализированные данные.
SizeOfUninitialized	Размер секции, содержащей неинициализированные данные (BSS).

Раздел Windows-specific Располагается сразу после стандартного набора полей и состоит из 21 поля, данные из которых используются линкером и загрузчиком операционной системы. В таблице 1.8 представлены поля, которые непосредственно используются библиотекой в процессе выполнения её основных функций.

Таблица 1.8. Поля раздела Windows-specific

Имя	Описание
ImageBase	Предпочтительный адрес по которому загружается образ процесса в память компьютера при его создании.
SectionAlignment	Выравнивание для секций, обычно соответствует размеру страницы памяти.
FileAlignment	Выравнивание для данных внутри секций. По умолчанию равно 512 байт.
SizeOfImage	Размер образа процесса создаваемого в памяти при его загрузке.
SizeOfHeaders	Размер всех заголовков образа.

Раздел директорий данных состоит из набора структур, каждая из которых содержит адрес и размер каждой секции файла-образа, используемой операционной системой. Адрес представляет собой смещение относительно адреса загрузки образа процесса в память операционной системы. Размер указывает размер таблицы в байтах. Набор таблиц, которые может содержать файл-образ, представлен в таблице 1.9.

Таблица 1.9. Виды таблиц файла-образа

Имя	Описание
Export Table(.edata)	Таблица экспорта. Содержит символьные имена, экспортируемые модулем (предоставляемые другим модулям).
Import Table(.idata)	Таблица импорта. Содержит символьные имена, импортируемые из других модулей.
Resource Table(.rsrc)	Таблица ресурсов.
Exception Table(.pdata)	Таблица исключений.
Certificate Table	Таблица атрибутов сертификата.
Debug(.debug)	Содержит отладочную информацию.
Architecture	Зарезервировано. Всегда 0.
Global Ptr	Зарезервировано. Всегда 0.
TLS Table(.tls)	Локальное хранилище данных потока.
CLR Runtime Header(.cormeta)	Содержит данные для загрузки окружения для выполнения.NET-компонентов.

Сразу за заголовком IMAGE_OPTIONAL_HEADER расположена таблица секций, состоящая из структур IMAGE_SECTION_HEADER. Число структур в таблице указано в заголовке IMAGE_FILE_HEADER, размер каждой структуры равен 40 байтам. Поля заголовка содержать информацию, описывающую каждую секцию, имеющуюся в файле. Поля перечислены в таблице 10.

Таблица 1.10. Поля структуры IMAGE_SECTION_HEADER

Имя	Описание
Name	Имя секции. Содержит либо не нуль-терминированную строку с именем, либо индекс строки в таблице строк если имя не умещается в 8 байт.
VirtualSize	Размер секции, когда он загружен в память процесса.
VirtualAddress	Смещение в байтах относительно адреса загрузки процесса в память.
SizeOfRawData	Размер секции в файле на диске.
PointerToRawData	Адрес секции в файле на диске.
PointerToRelocations	Адрес реллокации. Только для объектных файлов.
Characteristics	Набор флагов.

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

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

Описание COM - компонентов формата PE

Стандарт COM был разработан в 1993 году корпорацией Microsoft в качестве основы для развития технологии OLE. Основное понятие, которым оперирует стандарт COM, это COM-компонент. Программы, построенные на стандарте COM, по сути, не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор и может одновременно использоваться во многих программах. Компонент взаимодействует с другими программами через COM-интерфейсы - наборы абстрактных функций и свойств. Windows API предоставляет различные базовые функции, которые позволяют использовать COM-компоненты.

Все COM-компоненты имеют формат PE описанный ранее. Единственное отличие - это экспорт интерфейса DllGetClassObject, который является точкой входа компонента.

Описание.NET - компонентов формата PE

NET Framework - это программная платформа, выпущенная компанией Microsoft в 2002 году. В качестве основы для платформы выступает общеязыковая среда исполнения Common Language Runtime (CLR), которая подходит для различных языков программирования. Функциональные возможности CLR доступны в любых языках программирования, использующих указанную среду. Основной идеей при разработке.NET Framework являлось обеспечение свободы разработчика за счёт предоставления ему возможности создавать приложения различных типов, способные выполняться на различных типах устройств и в различных средах. Программа для.NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для.NET промежуточный байт-код Common Intermediate Language (CIL). В терминах.NET получается сборка (англ. assembly). Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой в исполняемый код для конкретного целевого процессора. Архитектура.NET Framework описана и опубликована в спецификации Common Language Infrastructure (CLI), разработанной Microsoft и утверждённой ISO и ECMA. В CLI описаны типы данных.NET, формат метаданных программы и система исполнения байт-кода. Сами сборки имеют формат РЕ.

Описание формата ZIP

Формат ZIP - это один из наиболее широко используемых форматов для сжатия данных, был разработан в 1989 году. Формат описан в [5]. Он может использоваться для агрегации файлов и каталогов, их сжатия и шифрования. Целостность данных внутри архива обеспечивается подсчётом контрольной суммы. Архив ZIP может содержать один или несколько файлов и каталогов, которые могут быть сжаты разными алгоритмами. Наиболее часто в ZIP используется алгоритм сжатия Deflate. Как указано в спецификации [5], файлы формата ZIP могут иметь разные расширения, такие как JAR, DOCX, XLXS, PPTX, ODT, и другие. Обычно архивы представляют собой файлы с расширением «.zip» или «.ZIP». Если есть необходимость, то ZIP-архив может быть объединён с модулем-распаковщиком в единый исполняемый файл с расширением.EXE (SFX-архив). Поэтому программы, работающие с данным форматом должны полагаться на внутренние данные заголовков, а не на указанное расширение файла. Общая структура файла представлена на рисунке 1.3.

Рисунок 1.3. Структура файла формата ZIP

В начале каждого файла упакованного в ZIP-архив располагается заголовок Local file header. Первым его полем является 4-х байтовый набор «магических байт», идентифицирующих заголовок. Далее располагаются поля содержащие информацию о методе сжатия, дате и времени модификации файла, контрольной сумме, размере сжатого и распакованного файла и др.

Сразу за заголовком Local file header должны располагаться сами сжатые данные, но в случае, если они зашифрованы, то сначала располагается заголовок шифрования, а потом непосредственно данные. После данных располагается заголовок Data descriptor, но как указано в спецификации, только если установлен соответствующий бит в поле флагов заголовка Local file header. Он содержит контрольную сумму, размер сжатого и распакованного файла. Последовательность из [local file header] [encryption header] [file data] [data descriptor] повторяется для каждого входящего в архив файла.

В конце файла расположен заголовок Archive decryption header, который был введён в версии формата 6.2 (2004 г.). Его назначение - это поддержка режима шифрования Strong Encryption и структуры Central Directory, которая располагается далее в файле. Сразу за ней расположен заголовок Archive extra data. Оба этих заголовка присутствуют в файле, только если структура Central Directory зашифрована.

Структура Central directory была введена в спецификацию в версии формата 6.2 для поддержки режима шифрования Strong Encryption. Данный режим предусматривает шифрование с использованием криптографических сертификатов. Она состоит и набора заголовков, каждый из которых описывает атрибуты одного файла, входящего в архив. Завершает набор специальная структура, которая содержит набор «магический баит» и цифровую подпись.

Описание формата TAR

Формат TAR был разработан в 1998 году и первоначально использовался для архивирования данных на магнитной ленте. Формат описан в [7]. В настоящее время используется для хранения нескольких файлов внутри одного файла. Также данный формат удобен для сохранения каталогов и создания архивов файловых систем, так как в файл записываются данные о владельце, группе владельца, временные метки, структура каталогов. Файл формата TAR представляет собой несколько файлов, помещенных в один файл (по умолчанию - без сжатия). Файл TAR можно сжать другими приложениями, позволяющими сжимать данные (например, GZIP). Расширение.tar при этом меняется на.tar.gz. Общая структура архива представлена на рисунке 1.4:

Рисунок 1.4. Общая структура архива TAR.

Файлы с расширением TAR состоят из данных файла, а также заголовка, округленного до 512 байт. Каждый файл, входящий в архив начинается с заголовка со списком полей, представленным в таблице 11.

Таблица 1.11. Список полей заголовка файла, входящего в архив TAR

Имя	Описание
name	Имя файла.
mode	Режим сжатия.
uid	ID пользователя в системе.
gid	ID группы, в которую входит пользователь.
size	Размер файла.
mtime	Время создания файла.
chksum	Контрольная сумма заголовка.
typeflag	Тип файла.
linkname	Имя файла ссылки.
magic	Набор «магических байт».
version	Версия формата.
uname	Имя пользователя, создавшего файл.
gname	Имя группы, в которую входит пользователь.

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

Описание формата GZIP

Формат GZIP описан в [6]. Он был разработан в 1992 году для UNIX-систем, во многих из которых является стандартом де-факто. GZIP - это формат архива который использует алгоритм Deflate и может работать только с одним непрерывным файлом. Архивация нескольких файлов в один архив невозможна. Для этой цели несколько файлов сначала упаковывают в один файл формата TAR, используя одноимённую утилита, и лишь потом сжимают. Полученный архив имеет расширение.tar.gz. gzip может работать с непрерывным потоком данных, упаковывая-распаковывая их «на лету». Данный подход широко применяется в UNIX-системах: при помощи перенаправления потоков можно работать с упакованными файлами так же легко, как и с распакованными (распаковка в памяти при чтении и упаковка при записи). Многие UNIX-утилиты имеют встроенную поддержку такого механизма.

Файл формата GZIP состоит из набора записей (сжатых наборов данных). Записи следуют одна за другой до конца файла. Каждая запись состоит из заголовка и следующих за ним сжатых данных. Поля заголовка описаны в таблице 1.12.

Таблица 1.12. Поля заголовка записи

Имя	Описание
Magic	Набор «магических байт» для идентификации.
CM	Метод сжатия.
FLG	Набор флагов.
MTIME	Время создания файла.
XFL	Дополнительный набор флагов.
OS	Операционная система, на которой выполнялось сжатие.
XLEN	Длинна дополнительных полей.
CRC32	Контрольная сумма.
ISIZE	Размер несжатого файла.

Общая структура файла изображена на рисунке 1.5.

Рисунок 1.5. Структура файла GZIP

Описание формата U-Boot

Формат U-Boot - это формат файлов универсального загрузчика Das U-Boot, который представляет собой загрузчик операционной системы, используемый для встроенных устройств архитектур MIPS, PowerPC, ARM и других. Das U-Boot - это свободное программное обеспечение, распространяемое по условиям лицензии GNU General Public License и обладающее самым широким набором возможностей по сравнению с другими загрузчиками. Оно может применяться на любой поддерживаемой архитектуре с использованием инструментария кросс-разработки GNU. Как правило, загрузчик хранится в загрузочной ПЗУ и запускается сразу после подачи питания на плату устройства и прохождения Post-инициализации. Основная функция загрузчика - произвести загрузку операционной системы в память устройства. Общая структура файла формата U-Boot представлена на рисунке 1.6.



Рисунок 1.6. Структура файла формата U-Boot

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

Таблица 1.13. Поля заголовка файла формата U-Boot

Имя	Описание
ih_magic	Набор «магических байт».
ih_hcrc	Контрольная сумма заголовка файла.
ih_time	Время создания файла.
ih_size	Размер файла.
ih_load	Адрес загрузки образа.
ih_ep	Адрес точки входа.
m_ih_dcrc	Контрольная сумма файла-образа.
ih_os	Тип операционной системы.
ih_arch	Архитектура процессора.
ih_type	Тип образа.
ih_comp	Тип сжатия.
ih_name	Имя образа процесса.

Описание формата Squashfs

Squashfs - это файловая система для операционной системы Linux, предоставляющая доступ к данным в режиме «только для чтения» и располагающая функционалом для сжатия данных. Squashfs может сжимать файлы, индексные дескрипторы и каталоги, а также поддерживает блоки данных различных размеров до 1024 Кбайт для лучшего сжатия. Она является свободным программным обеспечением с лицензией GPL. Squashfs предназначена для широкого использования в файловых системах с доступом «только для чтения», а также в ограниченных по размеру блочных устройствах (например, во встраиваемых системах). Наиболее распространенный пример использования данной файловой системы, это дистрибутивы LiveCD различных операционных систем на основе Linux: Debian, Ubuntu, Gentoo, Fedora и др.

Описание заголовка файла формата Squashfs взято из исходного кода, размещённого на официальном сайте проекта [10]. Поля заголовка описаны в таблице 1.14.

Таблица 1.14. Поля заголовка файла формата Squashfs

Имя	Описание
s_magic	Набор «магических байт».
inodes	Число индексных дескрипторов.
mkfs_time	Время создания файла.
block_size	Размер блока.
fragments	Число фрагментов.
compression	Тип сжатия (доступны алгоритмы Deflate, LZMA).
flags	Набор флагов.
s_major	Старшая версия файловой системы.
s_minor	Младшая версия файловой системы.

Описание формата ICO

Формат ICO - это формат хранения файлов значков в операционной системе Microsoft Windows. Один ICO-файл может содержать один или несколько значков, размер и другие атрибуты каждого из которых задаются отдельно. Начиная с версии Windows 98/2000, формат поддерживает хранение изображений в формате JPEG и PNG. Файл состоит из заголовка фиксированной длины, каталога информации о изображениях и самих изображений. Данный формат файлов является специфичным для операционной системы Windows. Заголовок имеет размер 6 байт, его поля описаны в таблице 1.15.

Таблица 1.15. Поля заголовка файла ICO

Имя	Описание
reserved	Зарезервировано. Всегда 0.
Type	Тип файла: 1 для значков (.ICO) 2 для курсоров (.CUR) Иные значения недопустимы.
count	Количество изображений в файле, минимум 1.

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

Таблица 1.16. Поля структуры описания изображения

Имя	Описание
width	Ширина изображения в пикселах. Может принимать значения от 0 до 255. Если указано 0, то изображение имеет ширину 256 пикселов.
height	Высота изображения в пикселах. Может принимать значения от 0 до 255. Если указано 0, то изображение имеет высоту 256 пикселов.
colors	Количество цветов в палитре изображения. Для полноцветных значков должно быть 0.
reserved	Зарезервировано. Всегда 0.
planes	Количество плоскостей. Может быть 0 или 1.
bpp	В.ICO определяет количество битов на пиксель (bits-per-pixel). Это значение может быть 0, так как легко получается из других данных; например, если изображение не хранится в формате PNG, тогда количество битов на пиксель рассчитывается на основе информации о размере растра, а также его ширине и высоте. Если же изображение хранится в формате PNG, то соответствующая информация хранится в самом PNG.
size	Размер растра в байтах.
offset	Размер растра в байтах.

Описание файлов сценариев командной оболочки

Командная оболочка UNIX (англ. Unix shell, sh) - это командный интерпретатор, используемый в операционных системах семейства UNIX, в котором пользователь может либо давать отдельные команды операционной системе, либо запускать скрипты, состоящие из списка команд.

Bash - один из наиболее популярных командных интерпретаторов UNIX, представляет из себя усовершенствованную версию интерпретатора sh. Особенно популярна в среде Linux, где она часто используется в качестве предустановленной командной оболочки. Bash - это командный процессор, работающий, как правило, в интерактивном режиме в текстовом окне. Bash также может читать команды из файла, который называется скриптом (или сценарием). Данный файл представляет собой обычный текстовый файл, отличительной особенностью которого является наличие в начале файла строки следующего содержания #!/usr/bin/ bash либо #!/usr/bin/ sh.

Описание формата GIF

Формат GIF - это растровый формат графических изображений, который способен хранить данные без потерь качества (с ограничением не более 256 цветов). Формат был разработан в 1987 году CompuServe. В дальнейшем он был модифицирован для поддержки прозрачности и анимации, а также использования компрессии LZW. Данная модификация описана в стандарте GIF89 [17].

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

Файл формата GIF содержит несколько заголовков, содержащих различную информацию о содержимом файла. В самом начале файла расположен набор магических байт и заголовок логического дескриптора экрана (англ. Logical screen descriptor). Набор полей логического дескриптора экрана описан в таблице 1.17. Общая структура представлена на рисунке 1.5.

Таблица 1.17. Поля логического дескриптора экрана

Имя	Описание
Width	Ширина экрана.
Height	Высота экрана.
Fields	Набор флагов.
Background color index	Значение цвета фона.
Pixel aspect ration	Индекс масштабирования.

Рисунок 1.5. Общая структура логического дескриптора экрана

Сразу за данным заголовком расположена глобальная таблица цветов (англ. Global Color Table). Данная таблица содержит последовательность байт представляющих цвета в формате RGB. Данная таблица присутствует в файле только если в заголовке логического дескриптора экрана установлен соответствующий флаг. Если таблица отсутствует, то описание цветовой палитры берётся из файлов самих изображений для каждого изображения входящего в файл

Файл формата GIF может хранить в себе множество изображений, которые расположены в файле сразу после глобальной таблицы цветов. Каждое изображение начинается с заголовка, который описан как дескриптор изображения (англ. Image descriptor). Поля данного заголовка описаны в таблице 1.18. Общая структура представлена на рисунке 1.6.

Таблица 1.18. Поля заголовка Image Descriptor

Имя	Описание
ImageSeparator	Идентификатор начала изображения. Значение всегда 0x2C.
LeftPosition	Отступ слева от границы экрана.
TopPosition	Отступ сверху от границы экрана.
Width	Ширина изображения в пикселах.
Height	Высота изображения в пикселах.
Flags	Набор флагов.

Рисунок 1.6. Общая структура дескриптора изображения

За данным заголовком расположена локальная таблица цветов, которая используется вместо глобальной, за которой расположены блоки данных самого изображения. Внутри изображения также содержатся ещё несколько структур данных, которые оставлены без описания, так как они не имеют непосредственного отношения в идентификации формата. Общая структура файла изображена на рисунке 1.7.



Рисунок 1.7. Описание файла формата GIF

Помимо этой информации в том случае, если файл содержит анимацию, то кроме самих изображений, составляющих анимацию в файле хранится информация, необходимая для её «проигрывания». Изображение в формате GIF хранится построчно, и поддерживается только формат с индексированной палитрой цветов. Стандарт разрабатывался только для поддержки 256-цветовой палитры. Формат GIF поддерживает анимационные изображения. Они представляют собой последовательность из нескольких статичных кадров и информацию о том, сколько времени каждый кадр должен быть показан на экране. GIF использует формат сжатия LZW который, является алгоритмом сжатия без потерь. Файл формата GIF может хранить в себе множество изображений, которые расположены в файле сразу после глобальной таблицы цветов. Каждое изображение начинается с заголовка, который описан как дескриптор изображения (англ. Image descriptor). Стандарт разрабатывался только для поддержки 256-цветовой палитры. Формат GIF поддерживает анимационные изображения. Они представляют собой последовательность из нескольких статичных кадров и информацию о том, сколько времени каждый кадр должен быть показан на экране.

1.6 Разработка методики определения форматов файлов

Методика определения форматов неисполняемых структурированных файлов

Большинство типов файлов содержат в себе так называемые «магические байты» (англ. - magic bytes). Как правило, это последовательность байт, которая расположена в начале файла и содержит какой-либо определённый набор символов. Ниже перечислены основные наборы «магических байт» для тех форматов, которые библиотека должна детектировать:

Таблица 1.19. Значения magic bytes для форматов файлов

Формат файла	Hex - значение	ASCII - значение
TAR	0x75, 0x73, 0x74, 0x61, 0x72	ustar
GZIP	0x1f, 0x8b, 0x08	-
ZIP	0x50, 0x4b, 0x03, 0x04	PK
ICO	0x00, 0x00, 0x01, 0x00
ELF	0x7F, 0x45, 0x4C, 0x46	ELF
PE	0x4d, 0x5a	MZ
U-boot	0x27, 0x05, 0x19, 0x56	-
Squashfs	0x68, 0x73, 0x71, 0x73	hsqs

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

Определение форматов исполняемых файлов и файлов-образов

Исполняемые файлы являются наиболее сложными по своей структуре. Также в рамках одного формата они сильно отличаются между собой по архитектуре целевой системы - это могут быть архитектура ARM, x86, MIPS и другие. Кроме нахождения «магических байт» также использутся частичный или полный разбор структуры файла, в ходе которого извлекается ряд параметров, необходимых для идентификации целевой архитектуры.

Методика определения формата ELF

Для идентификации данного формата файла библиотека в процессе своей работы кроме «магических байт» проверяет набор полей заголовка, указанных в таблице 1.20.

Таблица 1.20. Набор проверяемых полей для формата ELF.

Поле	Возможное значение	Описание
EI_CLASS	0x01, 0x02	Разрядность системы: 32, 64
EI_DATA	0x01, 0x02, 0x10	Порядок байт: little-endian, big-endian, multibyte
EI_OSABI	… 0x03, 0x06, 0x09	Операционная система: Linux, FreeBSD, Solaris
e_type	0x01, 0x02, 0x03	Тип файла: rellocatable, executable, shared
e_phoff	0x34, 0x40	Смещение программного заголовка: x86, x86-64
e_shoff	-	Смещение таблицы секций

Методика определения формата PE

PE-формат (англ.-portable executable) - это формат исполняемых файлов для операционный систем семейства Windows NT. На данный момент существует два формата PE-файлов: PE32 и PE32+. PE32 формат для x86 систем, а PE32+ для x64. Формат описан в [2]. Структура файла представляет собой набор заголовков, содержащих в себе данные, необходимые для создания образа процесса в оперативной памяти компьютера. Как и формат ELF PE-файл содержит в себе «магические байты» для идентификации.

Для получения информации о файле проверяются значения полей, указанных в Таблице 1.21.

Таблица 1.21. Набор проверяемых полей для формата PE

Поле	Возможное значение	Описание
signature	'P', 'E', '\0', '\0'	«набор магических байт»
size_of_code	0 - размер файла	Размер исполняемого файла
Machine	-	Идентификатор CPU целевой машины
majorOperatingSystemVersion	4 - 10	Старшая версия операционной системы

Определение исполняемых скриптов командной оболочки

Для определения того факта, что текстовый файл является исполянемым скриптом в нём производится поиск подстроки следующего содержания:

«#!/bin», «#!/usr/bin», «#!/bin/sh», «#!/bin/bash», «#!/system/bin/sh».

1.7 Обзор методики определения типов исполняемых файлов

Исполняемый файл, если он не является драйвером устройства или модулем ядра, работает в пространстве пользователя. Пространство пользователя - это адресное пространство виртуальной памяти операционной системы, отводимое для пользовательских программ. Выполняясь в данном пространстве пользовательский процесс не может напрямую обращаться к аппаратным ресурсам компьютера, таким как, например, сетевой адаптер. Данной возможностью обладает только ядро операционной системы. Для того, чтобы передавать и принимать данные по сети, процесс должен воспользоваться интерфейсом системных вызовов операционной системы. Системный вызов - это обращение программы, работающей в пространстве пользователя к ядру операционной системы для выполнения какой-либо операции. К сетевым системным вызовам относятся следующие: socket, connect, accept, listen, sendto, recvfrom, select, poll, epoll. Сами системные вызовы скрыты за интерфейсом стандартной библиотеки libstdc [3]. Набор системных вызовов может отличаться для различных операционных систем.

Определение возможностей взаимодействия с сетью для файлов формата ELF

Для того, чтобы определить использует ли создаваемый из файла процесс сетевые системные вызовы используется метод поиска символьных имён соответствующих вызовов в секции строк. Символьное имя функции - это имя, которое присваивается компилятором каждой функции, описанной программистом в исходном коде или библиотечной функции, которая является обёрткой над системным вызовом. Секция строк содержит символьные имена, используемые программой, в строковом виде. Она представляет собой массив строк, где каждая строка отделена нулевым символом в конце. Для поиска символьных имён сетевых системных вызовов необходимо найти таблицу строк по смещению, указанному в заголовке файла и проверить каждое символьное имя на совпадение со строками, указанными в списке сетевых системных вызовов. Стоит отметить, что в таблице строк символьные имена функций хранятся в искажённом виде. Искажение представляет собой добавление различных символов в начало и конец имени. Это происходит на этапе компиляции и носит название «мэнглинга» имён (англ. name mangling). Эта процедура необходима для обеспечения уникальности каждого символьного имени в программе. Например, описанный в стандартной библиотеке класс char_traits в программе будет иметь символьное имя _ZStlsIcSt11char_traitsIcESaIcEERS, оператор вывода стандартной библиотеки std:cout будет иметь имя _ZSt4cout@@GLIBCXX_3.4.

Определение модулей ядра для операционной системы Linux

Определение того факта, что исполняемый файл формата ELF является модулем ядра операционной системы выполняется также методом поиска символьных имён. Каждый модуль ядра использует пару системных вызовов init_module и cleanup_module для своей инициализации и деинициализации. Данный факт является достаточным для правильной идентификации модуля.

Определение возможностей взаимодействия с сетью для файлов формата PE

В операционной системе Windows интерфейс взаимодействия с сетью находиться в динамической библиотеке WinSock, которая загружается в память при первом обращении к ней. Перед тем как использовать её функционал пользовательский процесс должен произвести её инициализацию путём вызова функции WSAStartup [4]. Без вызова данной функции использование WinSock невозможно. Таким образом, для определения того факта, что создаваемый из PE - файла пользовательский процесс располагает функционалом для взаимодействия с сетью достаточно детектировать обращение к функции WSAStartup. Детектирование проводится методом поиска символьного имени «WSAStartup» в таблице строк файла.