Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Создание базы спецификаций форматов данных и их уточнение на основе анализа набора трасс программ

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 14.08.2020
Размер файла 2,8 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

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

Рисунок 13 Интерфейс модуля восстановления формата данных

В поле Trace position задается номер шага, с которого модуль будет выполнять анализ буфера. В поле Buffer необходимо внести информацию об адресе буфера в памяти и его размере. Далее расположено окно для просмотра дерева формата данных. Ниже располагается окно для просмотра содержимого буфера. В Restore Mode задаются параметры восстановления, например, Restore semantics позволяет опционально включать восстановление семантики данных, так как данный процесс не всегда необходим и может занимать довольно продолжительное время. Раздел Format Management позволяет производить импорт и экспорт уже существующих форматов данных в файловую систему или базу данных, которая будет рассмотрена далее. Кнопка Run запускает процесс восстановления формата данных. После завершения восстановления, пользователю будет представлено два дерева формата данных: конкретное (полученной из трассы) и обобщенное. Для отображения обобщенного дерева формата нужно перейти на вкладку Generic tree (Рисунок 14).

Рисунок 14 Интерфейс для просмотра обобщенного дерева формата

Перейдем к рассмотрению базы данных форматов (Рисунок 15).

В зависимости от действия пользователя, интерфейс взаимодействия будет меняться. Если аналитик производит импорт (рисунок сверху), то, выбрав необходимый формат, загрузка производится по нажатию кнопки Load Format или по двойному щелчку мыши. При успешной загрузке, дерево формата будет отображено в окне интерфейса модуля восстановления формата данных (Рисунок 13). Если производится экспорт (рисунок снизу), то появляется поле Name для ввода имени, под котором будет сохранен формат. Сохранение осуществляется по нажатию кнопки Save.

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

Рисунок 15 Интерфейс базы данных форматов

В целях переносимости все форматы хранятся в JSON. Также модуль позволяет производить экспорт форматов в PeachPit для проведения тестирования с помощью генерационного фаззера Peach [19].

На рисунке 16 представлен интерфейс объединения форматов данных. В верхних окнах интерфейса расположены деревья формата, которые необходимо объединить. В левом нижнем окне отображается дерево формата - результат объединения. Группа Merge Parameters представляет собой систему бонусов и штрафов, которую будет использовать алгоритм Нидлмана-Вунша (по умолчанию используются значения из таблицы 1). В группе Action располагаются кнопки Import, Export и Reset. Import и Export, аналогично предыдущему интерфейсу, осуществляют взаимодействие с базой данных форматов. Кнопка Reset позволяет сбросить все настройки: очистить все поля и восстановить первоначальные значения системы бонусов и штрафов.

Рисунок 16 Интерфейс объединения форматов данных

4.2 Тестирование системы объединения форматов данных

Для тестирования системы объединения форматов рассмотрим протокол DNS в соответствии со спецификацией RFC 1035 [16]. Данный протокол используется для преобразования доменных символьных имен в IP-адреса (прямой запрос) и наоборот (обратный запрос).

На рисунке 17 представлены восстановленные форматы обратного (слева) и прямого (справа) DNS запросов, которые имеют различную длину. Основное отличие заключается в том, что в прямом запросе присутствует дополнительная последовательность (Sequence(?,?) -> Field Length(0x8,0x2)), которая отсутствует в обратном запросе. Также в общей последовательности (Sequence(0xd,?) -> Field Delimiter(?,0x1)) варианты содержат различные элементы.

Рисунок 17 Обратный (слева) и прямой (справа) DNS запрос

На рисунке 18 представлен результат объединения прямого и обратного DNS запросов.

Все поля в начале форматов не изменились, кроме поля Field(0x8,0x2) - теперь оно имеет семантику поля длины. Вариант последовательности Sequence(0xd,?) -> Field Delimiter(?,0x1) теперь содержит объединение элементов из исходных форматов данных. Отсутствующая последовательность Sequence(?,?) -> Field Length(0x8,0x2) теперь находится в отдельном элементе типа вариант и ссылается на поле, которое раньше не имело семантики. Так как форматы имеют различную длину, в конце можно увидеть варианты - поля, которым не нашлось соответствие при объединении. Также стоит отметить, что целостность ссылок в результате объединения не была нарушена.

Рисунок 18 Результат объединения прямого и обратного DNS запросов

Рассмотрим еще один пример объединения форматов с использованием протокола прикладного уровня HTTP [18]. Данный протокол является текстовым, но в настоящее время используется для передачи произвольных данных: документы в формате HTML, потоковое видео и звук.

На рисунке 19 представлены части обобщенных форматов HTTP запросов с неизвестными (слева) и известными (справа) данными о значениях разделителей. От системы объединения форматов требуется произвести уточнение данных на основе исходных форматов. Другими словами, в результате объединения должно получиться дерево формата, которое по объему информации не будет уступать ни одному из исходных.

Рисунок 19 HTTP запросы с неполными (слева) и полными (справа) данными о разделителях

На рисунке 20 представлен результат объединения форматов HTTP запросов. Как и требовалось, в результате объединения получилось дерево формата, которое содержит наибольшую возможную информацию об элементах исходных форматов: поля-разделители теперь содержат числовые значения. Также стоит отметить, что целостность ссылок последовательностей не была нарушена и в них также имеется уточненная информация о разделителях.

Рисунок 20 Результат объединения форматов HTTP запросов

В таблице 3 представлены результаты объединения DNS и HTTP сообщений с точки зрения количества элементов в исходных и объединенных форматах данных.

Таблица 3

Результаты объединения DNS и HTTP сообщений

Протокол

Тип формата

Число полей

Число полей с семантикой

Число последовательностей

Число структур

Число вариантов

DNS

Обратный запрос

18

14

5

12

2

Прямой запрос

34

26

12

29

9

Объединенный

40

34

16

41

15

HTTP

Неизвестная семантика

57

19

19

19

0

Известная семантика

72

36

19

19

12

Объединенный

72

36

19

19

12

4.3 Выводы по главе

В данной главе рассмотрена реализация и архитектура модуля восстановления формата данных в составе среды анализа бинарного кода. Реализованы следующие составные компоненты модуля:

1) Система восстановления и обобщения форматов данных;

2) Система объединения и уточнения обобщенных форматов данных;

3) База данных форматов.

Работоспособность и эффективность реализованного модуля была продемонстрирована на восстановленных форматах сообщений прикладных протоколов DNS и HTTP.

Заключение

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

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

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

1) Более точно восстановить из трассы структуру и семантику буфера с данными;

2) На основе восстановленной конкретной структуры данных получить обобщенное представление формата данных;

3) Произвести уточнение формата данных с помощью объединения нескольких обобщенных форматов.

Среди направлений дальнейших работ можно выделить следующее:

4) Автоматизация определения шагов и буферов памяти в бинарной трассе;

5) Разработка средств для решения задачи восстановления автомата состояний исследуемого протокола

Список литературы

1. Аветисян А.И., Падарян В.А., Гетьман А.И. О некоторых методах повышения уровня представления при анализе защищённого бинарного кода // В кн.: Материалы XIX Общероссийской научно-технической конференции "Методы и технические средства обеспечения безопасности информации". Санкт-Петербург. 2010. С. 97-98.

2. Гетьман А.И., Маркин В.Ю., Падарян В.А., Щетинин Е.И. Восстановление формата данных // В кн.: Труды Института системного программирования РАН. 2010. С. 195-214.

3. Падарян В.А., Гетьман А.И., Соловьев М.А., Бакулин М.Г., Борзилов А.И., Каушан В.В., Ледовских И.Н., Маркин Ю.В., Панасенко С.С. Методы и программные средства, поддерживающие комбинированный анализ бинарного кода // В кн.: Труды Института системного программирования РАН. 2014. С. 251-276.

4. Падарян В.А., Гетьман А.И., Соловьёв М.А. Программная среда для динамического анализа бинарного кода. Т. 19. // В кн.: Труды Института системного программирования. 2009. С. 51-72.

5. Тихонов А.Ю., Падарян В.А. Применение программного слайсинга для анализа бинарного кода, представленного трассами выполнения // В кн.: Материалы XVIII Общероссийской научно-технической конференции «Методы и технические средства обеспечения безопасности информации». 2009. С. 131.

6. Beddoe A. Network Protocol Analysis using Bioinformatics Algorithms, The Protocol Informatics Project, 2005.

7. Bossert G., Hiet G. Towards Automated Protocol Reverse Engineering Using Semantic Information // In: 9th ACM Symposium on Information, Computer and Communications Security. 2014. pp. 51-62.

8. Caballero J., Yin H., Liang Z., Song D. Automatic Extraction of Protocol Message Format using Dynamic Binary Analysis // In: Proceedings of the 14th ACM conference on Computer and communications security. 2007. pp. 317-329.

9. Clause J., Li W., Orso Dytan A. A generic dynamic taint analysis framework // In: Proceedings of the 2007 International Symposium on Software Testing and Analysis. 2007. pp. 196-206.

10. Comparetti P.M., Wondracek G., Kruegel C., Kirda E. Prospex: Protocol Specification Extraction // In: In Proceedings of the 30th IEEE Symposium on Security and Privacy. 2009. pp. 110-125.

11. Kaufman L., Rousseeuw P. Finding Groups in Data: An Introduction to Cluster Analysis. Wiley. 1990.

12. Lim J., Reps T., B. L. Extracting Output Formats from Executables // In: Proceedings of the 13th Working Conference on Reverse Engineering. 2006. pp. 167-178.

13. Needleman S.B., Wunsch C.D. A General Method Applicable to the Search for Similarities in the Amino Acid Sequence of Two Proteins // Journal of Molecular Biology, 1970. pp. 443-453.

14. Wondracek G., Kruegel C., Kirda E., Milani P. Automatic Network Protocol Analysis // In: In Proceedings of the 15th Annual Network and Distributed System Security Symposium (NDSS). 2008.

15. Deep packet inspection [Электронный ресурс] // Wikipedia: [сайт]. URL: https://ru.wikipedia.org/wiki/Deep_packet_inspection (дата обращения: 01.05.2020).

16. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION [Электронный ресурс] // RFC 1035: [сайт]. [1987]. URL: https://tools.ietf.org/html/rfc1035 (дата обращения: 01.05.2020).17. Fuzzing - Mutation vs. Generation [Электронный ресурс] // Infosec: [сайт]. [2018]. URL: https://resources.infosecinstitute.com/fuzzing-mutation-vs-generation (дата обращения: 01.05.2020).

18. Hypertext Transfer Protocol [Электронный ресурс] // RFC 2616: [сайт]. [1999]. URL: https://tools.ietf.org/html/rfc2616 (дата обращения: 01.05.2020).

19. Peach Pit Files [Электронный ресурс] // Peach Fuzzer: [сайт]. [2018]. URL: http://community.peachfuzzer.com/v3/PeachPit.html (дата обращения: 01.05.2020).

20. Qt framework [Электронный ресурс] URL: https://www.qt.io (дата обращения: 01.05.2020).

21. Standard C++ [Электронный ресурс] // ISOCPP: [сайт]. URL: https://isocpp.org/ (дата обращения: 01.05.2020).22. The SNORT network intrusion detection system [Электронный ресурс] // Snort: [сайт]. URL: http://www.snort.org (дата обращения: 01.05.2020).

23. UPGMA: Hierarchical Clustering Method [Электронный ресурс] // Wikipedia: [сайт]. URL: https://en.wikipedia.org/wiki/UPGMA (дата обращения: 01.05.2020).

Размещено на Allbest.ru

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены