Презентация лекция №6

1.

ВОЕННО-КОСМИЧЕСКАЯ АКАДЕМИЯ ИМЕНИ А.Ф. МОЖАЙСКОГО
Лекция № 6
Анализ программных реализаций при отсутствии исходных
текстов программ

2.

2
Лекция №6
Анализ исполняемого кода программ.
Цель: Изучить основные особенности
анализа программных реализаций в
условиях отсутствия исходных текстов программ.
Учебные вопросы:
Введение, структура дисциплины.
1. Особенности проведения анализа НДВ программ без
исходных текстов.
2. Сравнительный анализ дизассемблеров.
3. Корректное дизассемблирование. Ошибки
дизассемблирования. Причины
4. Методы анализа исполняемых файлов.

3.

3
Литература
1.
2.
3.
Анализ программных реализаций: электронное учеб.
пособие / В.А. Новиков, А.А. Платонов, А.Н. Киселев. –
СПб.: ВКА им. А.Ф. Можайского, 2017. – 110 с.
Компаниец Р.И.,Ломако А.Г. Методика проведения
статического анализа и динамического контроля потоков
управления в исполняемых кодах программ на отсутствие
недекларированных возможностей (электронное учебнометодическое
пособие
по
дисциплине
«Анализ
программных реализаций»). СПб.: ВКА им. А.Ф.
Можайского, 2021. – 180 с.
Защита программ и данных/А.А. Платонов, А.С. Дудкин,
Р.И. Компаниец. СПб.: ВКА имени А.Ф. Можайского, 2023.224 с.

4.

Структура дисциплины АПР
6 семестр
Введение
Раздел 1. Технология анализа программ
Тема 1. Классификация исходных данных и видов анализа
программных реализаций
Тема 2. Системы анализа программных реализаций
Тема 3. Анализ программных реализаций при наличии исходных
текстов программ
Зачет
7 семестр
Раздел 2. Технология оценивания качества программных
реализаций
Тема 4. Анализ программных реализаций при отсутствии исходных
текстов программ
Тема 5. Анализ защиты программных реализаций от исследования
и нелицензионного копирования
Тема 6. Метрология и качество программного обеспечения
Экзамен

5. 1. Особенности анализа НДВ без исходных текстов

Технология анализа основана на выявлении избыточных и дефектных участков
кода.
Процесс выявления НДВ в условиях отсутствия исходных текстов выполняется при
априорно неполных исходных данных.
Наличие защитных механизмов от исследования (встроенных или навесных)
сильно усложняет саму возможность анализа, а в отдельных случаях делает это в
принципе невозможным.
Влияние среды разработки (компиляторов, компановщиков, загрузчиков,
упаковщиков, шифровальщиков, обфускаторов и др., их версий) на исполняемый
код, платформенная зависимость (аппаратная и операционная), наличие в
исполняемом коде значительного количества функциональных объектов,
отсутствующих в исходном тексте (объекты, созданные компилятором, обращения к
функциям ОС и динамическим библиотекам) существенно увеличивает объем кода
для анализа.
Основная идея исследования программ в указанных условиях заключается в
поэтапном применении технологий перевода исполняемого кода программ к виду
удобному для исследования и формированию по нему однозначных выводов.
Процедуры контроля не всегда удается выполнить в автоматическом режиме,
разработав соответствующее программное обеспечение, часто это ручной труд. Вид
удобный для исследования это листинг программы на языке ассемблер. Основная
проблема его исследования – проблема размерности.
5

6. Типовая схема технологии выявления НДВ программ

6

7. Предварительный анализ данных

7

8. Сбор информации из открытых источников

Подготовив опорную информацию, выполняется поиск «открытых» источников,
например, сайта разработчика объекта исследования и дублирующих
источников, таких как форумы, файловые хранилища. В найденных источниках
обращается внимание и изучается:
версия программы;
периодичность обновления;
возможность получения старых версий программы;
наличие стандартного комплекта разработчика (SDK);
наличие сторонних разработчиков модулей расширяющих возможности
исследуемой программы (plugin);
наличие программ (patcher) изменяющих программно реализованные
алгоритмы разработчика;
наличие доступа к файлам (*.DBG) или базам данных содержащих
отладочную информацию об используемых именах и символах (*.PDB);
сведения об ошибках и реакция разработчика;
наличие
аппаратно
реализованных
компонентов
расширяющих
функциональные возможности;
записи в базах уязвимостей касающиеся программы, их авторы;
наиболее значимые покупатели программы, как правило, их список есть
на сайте;
сотрудники компании, в том числе, сменившие работодателя
публикующие статьи, доклады, ссылки на проекты с доступными исходными
текстами;
ознакомиться
с
алгоритмами,
реализованными
в
открытых
заимствованных библиотеках, выявить отличия.
8

9. Формирование исследовательского стенда предварительного анализа.

Исследовательский стенд предварительного анализа должен
содержать программные инструменты позволяющие:
установить соответствие расширения файла его истинному
формату;
установить особенности установки дистрибутива (комплекта)
программ. К особенностям установки в первую очередь отнесём
применение программно реализованных механизмов скрывающих
установку в ОС отдельных файлов программ от средств наблюдения и
их регистрацию в ОС в качестве служб и сервисов;
сравнить содержание файла сценария дистрибутива с
данными файлового монитора;
установить факт изменения точки входа в исполняемый
файл;
установить наличие «навесных» защит у исполняемых
файлов и их нейтрализацию;
установить наличие реализованных в программе или дампе
памяти стандартных криптографических алгоритмов до выполнения
процедуры дизассемблирования.
9

10. Фиксация состояния объекта исследования и вычислительной среды.

Данный шаг необходим для выявления изменений, которые произошли в ОС
во время запуска. На данном шаге фиксируется контрольная сумма объекта
исследования и делается «снимок» ОС. «Снимок» ОС включает копии записей
реестра, файловых таблиц, списки служб и драйверов и других
конфигурационных файлов.
Для корректного создания описания текущего состояния операционной
системы требуется обоснованно подобрать программу монитор. Анализ
существующих программ, которые предоставляют в качестве одной из своих
функций - создание «снимка» ОС (например, с помощью SysTrac)
10

11. Основные операции анализа

• Контроль запуска объекта исследования.
• Контроль драйверов и устанавливаемых устройств.
• Формирование
тезауруса
ключевых
слов
специфицирующих функциональные объекты.
• Поиск
навесных
механизмов
защиты
от
дизассемблирования.
• Дизассемблирование и проверка его корректности.
11

12. Основные лидеры

2. Сравнительный анализ дизассемблеров
IDA Pro Disassembler
Распознавание стандартных библиотечных
функций (технология FLIRT);
Интерактивность работы;
Развитая система навигации;
Система типов и параметров функций;
Встроенный язык программирования IDC;
Открытая и модульная архитектура;
Возможность работы практически со всеми
популярными процессорами;
Работа со структурами данных высокого
уровня: массивами, структурами,
перечисляемыми типами.
Radare2
Поддержка большого количества
архитектур и платформ;
Встроенные скрипты;
Развитый шестнадцатеричный редактор;
Поддержка различных файловых систем;
Возможность добавления поддержки
новых ассемблеров и дизассемблеров,
парсеры различных форматов файлов и
анализаторы;
Расширенный список доступных
отладчиков;
Возможность сравнения двух бинарных
файлов.
Основные лидеры
1
2

13. Недостатки IDA Pro и Radare2:

Существующие проблемы
Наименование, артикул
Недостатки
IDA Pro и Radare2:
Стоимость,
руб.
Для MS Windows, Linux и Mac OS X
IDA Pro Стандартная плавающая
версия, IDASTAFW
97 250
IDA Pro Расширенная плавающая
версия, IDAPROFW
186 620
Декомпилятор Hex-Rays x86,
HEXX86FW
261 090
Декомпилятор Hex-Rays ARM,
HEXARMFW
261 090
Декомпилятор Hex-Rays x64,
HEXX64FW
261 090
Декомпилятор Hex-Rays ARM64,
HEXARM64FW
261 090
Декомпилятор Hex-Rays PowerPC
(PPC), HEXPPCFW
261 090
Высокая стоимость IDA Pro;
Radare2 - консольное приложение;
Графическая оболочка Cutter не
выполняет все возможности Radare2.
1
3

14. Опубликование нового инструмента

Представители
Агентства
национальной
безопасности
США
объявили
об открытии исходных кодов Ghidra инструмента для обратного инжиниринга,
который сами спецслужбы применяют уже
порядка двадцати лет.
Широкая
общественность
узнала
о
Ghidra в 2017 году благодаря документам
Vault7,
опубликованным
WikiLeaks.
Впрочем, до этого факт существования
Ghidra тоже не был засекречен.
В настоящее время Ghidra уже можно загрузит
ь с официального сайта и GitHub.
Ghidra написана на Java и имеет GUI,
работающий под Windows, Mac и Linux.
1
4

15. Основные характеристики Ghidra

«CodeBrowser» - полнофункциональный дизассемблер с возможностью просмотра
псевдокода;
«Version Tracking» - полезный дизассемблерский инструмент для переноса проделанной
работы на новые версии программы. Отслеживания всех изменений, которые сделали
разработчики по паттернам, сдвигам и т. д.;
Поддержка большого количества различных архитектур;
Настраиваемый пользовательский интерфейс;
Использование шаблонов, расширений и плагинов.
Ghidra
VS
IDA PRO and Radare2
1
5

16. Сравнение функциональных возможностей

Функционал
Radare2
Поддерживаемые типы файлов
15
Количество поддерживаемых форматов файлов
(+40 доп.)
Поддерживаемые архитектуры
Количество поддерживаемых архитектур для
14
дизассемблирования
(+52 доп.)
Количество поддерживаемых архитектур для декомпиляции
14
IDA Pro
14
(+25
доп.)
13
(+24 доп.)
6
Поддерживаемые отладчики (динамический анализ)
4
3
Количество поддерживаемых отладчиков
(+6 доп.)
(+1 доп.)
Emulation (via intermediate language) (Эмуляция кода)
✔
Trace (Трассировка)
✔
Отображение анализируемых данных
Cross References (Перекрестные ссылки)
✔
Graphs (Графы)
✔
Работа с API программы
Bindings/API (Поддержка API программы)
✔