Прелюдия
Read in English: Database Reverse Engineering, Part 1: Introduction Database Reverse Engineering, Part 2: Main Approaches Database Reverse Engineering, Part 3: Code Reuse, Conclusion Read in Russian: Database Reverse Engineering, Part 1: Introduction Database Reverse Engineering, Part 2: Main Approaches Database Reverse Engineering, Part 3: Code Reuse, Conclusion
Сегодняшнее сообщество RE сосредоточено на исследовании кода, и его главный вопрос - «как работает код и как он обрабатывает данные?» Мы посмотрим на обратный инжиниринг под другим углом и спросим: «Как организованы данные, обрабатываемые кодом?» Мы увидим, что обратная инженерия данных менее развита, чем обратная инженерия кода.
Что вы можете ожидать, так это проприетарный формат файла и анализ базы данных, межфайловые форматы, подходы к обратному проектированию структуры данных, методы исследования без дизассемблера и отладчика, а также способы распаковки данных. Пожалуйста, не ждите полного исходного кода и баз данных SQL.
Обратное проектирование форматов файлов
База данных RE - это процесс, основанный на файловом формате RE, первый из которых более абстрактен, чем второй.
На первом уровне абстракции мы исследуем отдельные файлы, которые не зависят друг от друга или связаны только семантически, например набор файлов .jpg в папке. Давайте сначала определим термины файл, формат файла и двоичный файл.
Файл - это данные, структурированные по определенным правилам.
Формат файла - это правила для структурирования данных в файле.
Простым примером является текстовый файл, содержащий несколько строк. Формат этого файла можно рассматривать как текст в кодировке UTF-8, разделенный символами новой строки.
For us, and for our tragedy, Here stooping to your clemency, We beg your hearing patiently.
Двоичный файл - это файл, содержащий необработанные байты и / или информацию, удобную для чтения.
Предположим, двоичный файл, в котором хранятся сообщения и их дата. Вы можете увидеть содержимое файла ниже. Его формат более строг, чем тот, который был показан ранее: первые четыре байта - это длина сообщения (0xC), следующие байты - это сообщение с указанной длиной без NULL-байтов («Некоторое сообщение»), за которым следует один байт для описания дня добавления. (0x6 = 6), один байт описывает месяц сложения (0xB = 11), а последние два - год сложения (0x7E1 = 2017).
0C 00 00 00-53 6F 6D 65-20 6D 65 73-73 61 67 65 ♀ Some message 06 0B E1 07- - - ♠◙с•
В Интернете есть пара статей о реверс-инжиниринге форматов файлов, но нельзя сказать, что они есть повсюду. Кроме того, есть инструменты для описания форматов файлов, в первую очередь шестнадцатеричные редакторы, дополненные императивными языками сценариев. Одним из передовых инструментов является Kaitai Struct, который позволяет декларативно описывать формат двоичного файла.
Обратный инжиниринг базы данных
Второй уровень абстракции появляется, когда мы исследуем набор двоичных файлов, связанных между собой внутренне. Мы называем этот набор «базой данных».
База данных - это набор двоичных файлов, которые содержат структурированные данные и перекрестные ссылки друг на друга.
Обратите внимание, что это очень низкоуровневое определение базы данных. Сегодня процесс обратного проектирования все еще детализирован, и RE базы данных не является исключением, у нас очень мало случаев, когда можно обойти внутренние исследования базы данных, чтобы немедленно начать работу с данными. В тех редких случаях нет необходимости в обратном инжиниринге.
Рассмотрим базу данных музыкальных групп, состоящую из трех двоичных файлов. Band.dat1 - это список групп, Album.dat2 содержит альбомы каждой группы, а Image.dat3 содержит фотографии участников группы и обложки альбомов.
Band.dat1 Album.dat2 Image.dat3
Опишем Band.dat1. Он состоит из массива одиночных элементов, описываемых следующей структурой:
- Word - идентификатор группы.
- 0x20 байт - название бэнда; неиспользуемые байты обнуляются.
- Список слов до конца 0xFFFF - список идентификаторов альбомов.
- 0xFFFF терминатор.
- Список двойных слов до терминатора 0xFFFFFFFF - список удостоверений личности с фотографией.
- 0xFFFFFFFF терминатор.
Есть две зависимости: идентификатор альбома (перекрестная ссылка на Album.dat2) и идентификатор фотографии (перекрестная ссылка на Image.dat3).
00 00 54 6F-6F 6C 00 00-00 00 00 00-00 00 00 00 Tool 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 00 00 00 00-01 00 02 00-03 00 FF FF-00 00 00 80 ☺ ☻ ♥ А 01 00 00 80-FF FF FF FF- - ☺ А
Посмотрите сейчас на Album.dat2. Существует массив из четырех элементов, каждый из которых описывается следующим образом:
- Word - идентификатор альбома.
- Слово - год выпуска.
- Байт - длина названия альбома.
- N байт - название альбома.
- Dword - идентификатор обложки.
Здесь мы видим только одну зависимость: идентификатор обложки (перекрестная ссылка на Image.dat3).
00 00 C9 07-08 55 6E 64-65 72 74 6F-77 02 00 00 ╔•◘Undertow☻ 80 01 00 CC-07 06 41 65-6E 69 6D 61-03 00 00 80 А☺ ╠•♠Aenima♥ А 02 00 D1 07-09 4C 61 74-65 72 61 6C-75 73 04 00 ☻ ╤•○Lateralus♦ 00 80 03 00-D6 07 0A 31-30 30 30 30-20 44 61 79 А♥ ╓•◙10000 Day 73 05 00 00-80 - - s♣ А
Изучите наконец Image.dat3. Мы видим массив из шести элементов размером 0x10 байт, никаких зависимостей от других файлов, формат элемента:
- Dword - идентификатор изображения.
- 0xC байтов - изображение (вымышленное, конечно).
00 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 АPIC 01 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 ☺ АPIC 02 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 ☻ АPIC 03 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 ♥ АPIC 04 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 ♦ АPIC 05 00 00 80-50 49 43 00-00 00 00 00-00 00 00 00 ♣ АPIC
Ниже приведены три формата файлов и их зависимости, которые на самом деле представляют собой архитектуру базы данных.
Итак, мы изучили два уровня абстракции - уровень формата файла и уровень базы данных - и готовы сформулировать задачу исследования базы данных.
Проблема обратного проектирования базы данных - это проблема восстановления неизвестных структур данных и нахождения зависимостей между ними.
RE базы данных - это этап, а не конечная цель многих реальных задач. После этого этапа начинается обработка данных с последующим преобразованием данных в новую, возможно, реляционную базу данных. Этот процесс можно назвать ETL (извлечение, преобразование, загрузка), но он не имеет ничего общего с обратным проектированием базы данных.
Я не нашел никаких документов по этому поводу. Полагаю, это потому, что специалисты не различали формат файла RE и RE базы данных. Другая причина заключается в том, что обратный инжиниринг базы данных - это очень трудоемкий процесс, который будет выполняться в основном для клиентов в соответствии с соглашением о неразглашении, что окажет информативное влияние на потенциальные документы.
Резюме
Мы дали достаточно формальное определение базы данных как набора файлов, но в действительности границы могут быть размыты, и часто мы называем ее базой данных только из-за нашего субъективного видения ее как связанного набора данных. Важно исследовать, как данные связаны, независимо от того, находятся ли они в одном файле или разделены на несколько файлов. Но вся сложность сосредоточена в этом исследовательском процессе. Начиная новую задачу, у нас есть масса файлов с бессмысленными именами и расширениями и программа, обрабатывающая эти файлы. Мы начинаем просматривать файлы один за другим с помощью шестнадцатеричного редактора и обращаем внимание на их различие, их возможную структуру, наличие или отсутствие текстовых файлов и т. Д. После этого мы проверяем саму программу. Когда обзор будет завершен, мы останемся наедине с десятками капель, создатели которых не горели желанием позволить нам исследовать. В следующих частях вы узнаете, что делать дальше.
