🟩 Компьютерная экспертиза баз данных и СУБД: исследование цифровых следов в реляционных и нереляционных хранилищах

Введение: архитектура истины в бинарном пространстве

В современном мире корпоративные информационные системы, государственные реестры и финансовые платформы функционируют на основе сложных комплексов управления данными, где целостность информации обеспечивается на уровне физических блоков, логических страниц и транзакционных журналов. 🏗️ Каждая операция INSERT, UPDATE или DELETE оставляет неизгладимый технический след в структурах СУБД (СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ), однако извлечение этих следов и их интерпретация требуют глубокого инженерного знания внутренней архитектуры конкретной платформы. Именно здесь на сцену выходит судебная компьютерная экспертиза баз данных и СУБД — дисциплина, находящаяся на стыке теории баз данных, низкоуровневого программирования, криминалистики и процессуального права.

Союз «Федерация судебных экспертов» объединяет инженеров-исследователей, которые не просто работают с готовыми отчётами коммерческих утилит, но и способны написать собственный парсер для неизвестного формата файла БД (БАЗЫ ДАННЫХ), восстановить удалённую запись из свободной страницы на SSD (ТВЕРДОТЕЛЬНОМ НАКОПИТЕЛЕ) с учётом особенностей TRIM и GARBAGE COLLECTION, а также с математической точностью доказать факт подмены временных меток через анализ LSN-последовательностей. ⚙️ В данной статье мы с инженерной точностью разберём устройство объектов компьютерной экспертизы баз данных и СУБД, предложим алгоритмические решения для типовых задач, представим три реальных кейса с детализацией до уровня HEX-дампов и структур языка C, а также дадим практические рекомендации по обеспечению сохранности доказательств.

Глава 1. Физический и логический уровни объектов исследования

1.1. Иерархия данных в СУБД

Любая современная СУБД организует данные на нескольких уровнях абстракции:

🔹 Физический уровень: сектора диска (обычно 512 байт или 4096 байт для ADVANCED FORMAT), блоки файловой системы (4 КБ для EXT4, 8 КБ для NTFS (NEW TECHNOLOGY FILE SYSTEM)), страницы (PAGES) СУБД (от 4 КБ до 32 КБ в зависимости от СУБД и настроек). Понимание этой иерархии критически важно для компьютерной экспертизы баз данных и СУБД, поскольку данные могут быть извлечены даже при повреждении верхних уровней.

🔹 Логический уровень: экстенты (EXTENTS) — группы страниц (например, 8 страниц по 8 КБ в MS SQL SERVER (MICROSOFT SQL SERVER) образуют один экстент), сегменты (SEGMENTS) — совокупности экстентов, принадлежащих одной таблице или индексу, таблицы (отношения), кортежи (строки), атрибуты (столбцы).

🔹 Транзакционный уровень: буферные пулы (BUFFER POOL), журналы упреждающей записи (WRITE-AHEAD LOG, WAL), UNDO-сегменты, служебные структуры для MVCC (MULTI-VERSION CONCURRENCY CONTROL). Именно на этом уровне фиксируется история изменений, что делает его основным объектом экспертного исследования.

1.2. Типы накопителей и их влияние на восстановление данных

Инженерный подход требует учёта физических характеристик носителя:

НЖМД (НЕМАГНИТНЫЕ ЖЁСТКИЕ ДИСКИ) с магнитными пластинами (HDD (HARD DISK DRIVE)): данные сохраняются даже после многократной перезаписи (эффект остаточной намагниченности). Возможно восстановление через анализ аналоговых сигналов (MFM (MODIFIED FREQUENCY MODULATION) демодуляция) в специализированных лабораториях, но это за пределами стандартной КТЭ (КОМПЬЮТЕРНО-ТЕХНИЧЕСКОЙ ЭКСПЕРТИЗЫ). В рамках компьютерной экспертизы баз данных и СУБД мы работаем с логическим уровнем, но должны информировать следователя о возможности углублённого физического исследования.
SSD (SOLID STATE DRIVE) на NAND-памяти (SLC (SINGLE-LEVEL CELL), MLC (MULTI-LEVEL CELL), TLC (TRIPLE-LEVEL CELL), QLC (QUAD-LEVEL CELL)): имеют ограниченное число циклов перезаписи (P/E CYCLES — PROGRAM/ERASE). Механизм TRIM (ATA COMMAND 0x06) после удаления файла отправляет команду контроллеру, который может немедленно стереть блоки в фоне (GARBAGE COLLECTION). Поэтому при изъятии SSD необходимо немедленно отключать питание и создавать образ с помощью аппаратного IMAGER’а, поддерживающего работу с TRIM-блоками (например, ATOLA INSIGHT). 📀
NVME (NON-VOLATILE MEMORY EXPRESS): современный интерфейс для SSD, работающий через шину PCIE (PERIPHERAL COMPONENT INTERCONNECT EXPRESS). Характеризуется очень высокой скоростью, но также подвержен TRIM. Дополнительная сложность: многие NVME-накопители имеют аппаратное шифрование (TCG OPAL (TRUSTED COMPUTING GROUP OPAL)), которое может сделать данные недоступными без пароля.

1.3. Файловые системы и их журналы

Файловая система (NTFS, EXT4, APFS (APPLE FILE SYSTEM)) хранит метаданные о расположении файлов БД. Анализ MFT (MASTER FILE TABLE) в NTFS или INODE TABLE в EXT4 может дать:

Временные метки создания, модификации и последнего доступа к файлам БД (CREATE, MODIFY, ACCESS — т.н. MAC-время).
Сведения о фрагментации и расположении экстентов файла.
Признаки удаления файла (в MFT запись помечается как unused, но тело файла может сохраняться в UNALLOCATED CLUSTERS — нераспределённых кластерах).

Инженер должен уметь вручную интерпретировать структуры файловой системы с помощью HEX-редактора (например, HXD или 010 EDITOR), поскольку автоматические инструменты могут ошибаться. Например, поле $STANDARD_INFORMATION и поле $FILE_NAME в NTFS хранят временные метки в разных форматах (LARGE_INTEGER, количество 100-нс интервалов с 01.01.1601). Эксперт обязан проверять оба поля на предмет расхождений. 📁

Глава 2. Инженерная анатомия страницы данных на примере INNODB (MYSQL) и HEAP (MS SQL SERVER)

2.1. Страница INNODB (MYSQL) — детальный разбор

Для понимания возможностей компьютерной экспертизы баз данных и СУБД необходимо знать внутреннее устройство страницы данных. Рассмотрим INNODB (движок MYSQL по умолчанию) как пример с открытой документацией. Страница имеет размер 16 КБ (16384 байта) и следующую структуру (в псевдокоде на C):

struct innodb_page {

unsigned char header[38]; // Заголовок страницы

unsigned char body[16256]; // Тело (записи + свободное пространство)

unsigned char trailer[8]; // Контрольная сумма и LSN

};

Заголовок страницы 38 байт (начиная с версии MYSQL 5.7) имеет критически важные поля:

struct innodb_page_header {

uint32_t checksum; // Контрольная сумма (CRC32 или другой алгоритм)

uint32_t offset_checksum; // Смещение контрольной суммы

uint32_t page_number; // Номер страницы в табличном пространстве

uint32_t space_id; // ID пространства (таблицы)

uint32_t lsn_for_page; // Последний LSN, изменивший страницу

uint16_t format; // Формат (0x0000 для ANTERIOR, 0x0001 для COMPACT)

uint16_t pad; // Выравнивание

//… остальные 22 байта (флаги, смещения)

};

Ключевые инженерные моменты:

Контрольная сумма страницы вычисляется на основе её содержимого. Если злоумышленник попытается вручную отредактировать страницу в HEX-РЕДАКТОРЕ, контрольная сумма, скорее всего, не совпадёт, что будет обнаружено СУБД при попытке чтения. Однако эксперт может игнорировать контрольную сумму и принудительно извлекать данные.
Поле lsn_for_page (LOG SEQUENCE NUMBER) позволяет сопоставить страницу с записями в REDO LOG. Если LSN страницы больше, чем LSN последней транзакции в журнале — это признак того, что страница была изменена вне контроля СУБД (например, прямым редактированием файла). 🔧

Тело страницы (body) содержит указатели на записи (RECORD POINTERS) в начале области (HEAP TOP), а также свободное пространство (FREE SPACE). Формат COMPACT записей:

struct innodb_record_compact {

uint8_t info_bits; // Бит DELETED, MIN, MAX и др.

uint16_t n_owned; // Количество записей в owned chain (для узлов B-tree)

uint16_t heap_no; // Номер записи в куче (heap)

uint16_t next_offset; // Смещение следующей записи

unsigned char data[]; // Данные столбцов (согласно схеме таблицы)

};

Бит DELETED в info_bits — признак того, что запись логически удалена (DEAD RECORD), но физически может сохраняться в теле страницы до тех пор, пока не будет вызвана OPTIMIZE TABLE или не произойдёт слияние страниц. Именно этот бит используют эксперты для восстановления удалённых записей! 🧩

2.2. Страница HEAP в MS SQL SERVER

MS SQL SERVER для таблиц без кластеризованного индекса (HEAP) использует страницы размером 8 КБ. Заголовок страницы описан в структуре PAGE_HEADER:

struct page_header_sql {

uint8_t page_type; // 0x01 = DATA_PAGE, 0x03 = INDEX_PAGE и т.д.

uint8_t page_level; // Уровень в B-tree (0 для листьев)

uint16_t next_page; // Ссылка на следующую страницу в двусвязном списке

uint16_t prev_page; // Ссылка на предыдущую страницу

uint8_t slot_count; // Количество слотов (указателей на записи)

uint16_t free_space_offset; // Смещение начала свободного пространства (обычно 8060 байт для HEAP)

//… другие поля

};

Записи в HEAP (строки) хранятся в виде структуры HEAP_RECORD. Первые 4 байта — битовая маска (BITMAP) наличия NULL-значений в столбцах. Затем идут переменные длины (VARCHAR, NVARCHAR, VARBINARY) со своими смещениями. Важный элемент: байт C_DELE_BIT (удалённая запись) в TagA (первый байт после битмапа). Если этот бит установлен в 1, запись считается удалённой (GHOST RECORD), но физически присутствует на странице. Для восстановления такой записи эксперт должен сбросить этот бит в мысленном эксперименте (или через специальную утилиту) и интерпретировать данные. 👻

Инженерное правило: Никогда не полагайтесь полностью на коммерческие утилиты (APEXSQL LOG, EASEUS и т.п.). Всегда выборочно проверяйте их вывод через прямое чтение страницы с помощью HEX-редактора по смещениям, полученным из документации. Только так можно обнаружить скрытые аномалии (например, когда утилита некорректно интерпретирует слоты после повреждения заголовка). 🧪

Глава 3. Журналы транзакций: инженерный взгляд на REDO LOG, UNDO LOG и BINARY LOG

3.1. Физическая структура WAL POSTGRESQL

WRITE-AHEAD LOG (WAL) — основа надёжности POSTGRESQL. Файлы WAL хранятся в pg_wal с именами вида 000000010000000000000001 (24 шестнадцатеричных символа). Каждый файл состоит из страниц (PAGES) размером 8 КБ (по умолчанию). Страница имеет заголовок XLogPageHeader:

struct XLogPageHeader {

uint16_t xlp_magic; // Магическое число 0xD068 (XLP_PAGE_MAGIC)

uint16_t xlp_info; // Битовые флаги: XLP_FIRST_IS_CONTRECORD, XLP_LONG_HEADER

uint32_t xlp_tli; // TIMELINE ID (времени выполнения)

XLogRecPtr xlp_pageaddr; // Адрес страницы в WAL (8 байт)

uint32_t xlp_rem_len; // Оставшаяся длина записи, если она не поместилась на странице

};

Затем следуют записи (XLogRecord), каждая из которых имеет заголовок:

struct XLogRecord {

uint32_t xl_tot_len; // Общая длина записи (заголовок + данные)

uint32_t xl_xid; // ID транзакции (XID)

XLogRecPtr xl_prev; // Указатель на предыдущую запись в транзакции

uint8_t xl_info; // Флаги: XLR_BLOCK_ID_DATA, XLR_BLOCK_ID_TOPLEVEL и т.д.

uint8_t xl_rmid; // Идентификатор менеджера ресурсов (RM — RESOURCE MANAGER)

//… еще 4 байта выравнивания

};

Для компьютерной экспертизы баз данных и СУБД важно уметь декодировать xl_rmid и xl_info. Например, для менеджера ресурсов HEAP (RM_HEAP_ID) значение xl_info может указывать на тип операции: XLOG_HEAP_INSERT, XLOG_HEAP_DELETE, XLOG_HEAP_UPDATE. Данные записи (после заголовка) содержат информацию о том, какой именно кортеж (строка) был вставлен, удалён или изменён. Однако для UPDATE в POSTGRESQL сохраняется только INSERT новой версии и DELETE старой (как два отдельных XLogRecord в рамках одной транзакции), а не полный образ «до и после». ⚠️

3.2. REDO LOG ORACLE: CHANGE VECTORS

ORACLE использует REDO LOG, состоящий из CHANGE VECTORS (векторов изменений). Вектор описывает изменение одного блока данных (например, «в блоке 0x12345, в смещении 0xABC заменить 2 байта на 0x12 0x34»). Это очень компактно, но для восстановления полной строки эксперт должен знать исходное состояние блока, что не всегда возможно без UNDO. Однако для обнаружения факта модификации таблицы такого подхода достаточно. Инструмент LOGMINER позволяет реконструировать SQL из CHANGE VECTORS, имея словарь данных (DATA DICTIONARY). 🔍

3.3. BINARY LOG MYSQL в формате ROW

При binlog_format = ROW каждый DML (DATA MANIPULATION LANGUAGE) запрос (INSERT, UPDATE, DELETE) записывается в BINARY LOG в виде событий: WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, DELETE_ROWS_EVENT. Событие содержит образы строк BEFORE и AFTER в двоичном формате, близком к формату страницы INNODB. Инженер может декодировать событие, зная метаданные таблицы (столбцы, типы). Это делает BINLOG наиболее информативным объектом для восстановления истории.

Инженерный вывод: При производстве компьютерной экспертизы баз данных и СУБД необходимо всегда запрашивать не только текущую БД, но и все доступные журналы за максимально возможный период. В идеале — перевести СУБД в режим FULL LOGGING (MS SQL), ARCHIVELOG (ORACLE), включить BINLOG с ROW-форматом (MYSQL) и настроить ARCHIVE COMMAND (POSTGRESQL) ДО возникновения спора. Ретроспективно это сделать невозможно. 📜

Глава 4. Кейс №1: Восстановление удалённой таблицы MS SQL SERVER после TRUNCATE через анализ журнала транзакций

4.1. Технический контекст

В ходе арбитражного разбирательства между ООО «СтройИнвест» и ООО «Монолит» одна из сторон удалила таблицу contracts_2024 (1,2 млн записей, объём данных около 850 МБ) с помощью команды TRUNCATE TABLE, а затем заявила, что «данных никогда не существовало». ⚖️ Суд назначил компьютерную экспертизу баз данных и СУБД для проверки факта существования и возможности восстановления.

4.2. Инструментарий и методика

Эксперт Союза «Федерация судебных экспертов» работал с образом диска сервера (RAID 10, NTFS, 4 диска по 2 ТБ). Использовались:

X-WAYS FORENSICS 20.5 для создания образа и анализа файловой системы.
Внутренняя утилита fn_dblog SQL SERVER (через скрипт на T-SQL).
Собственный скрипт на PYTHON для парсинга BLOB-полей RowLog Contents 0 и RowLog Contents 1.

4.3. Инженерный анализ LDF-файла

TRUNCATE TABLE не удаляет записи постранично, а просто освобождает экстенты, выделенные для таблицы, и сбрасывает метаданные (счётчик строк). Однако журнал транзакций (.LDF) хранит запись о каждой освобождённой странице. Эксперт выполнил:

sql

SELECT

[Current LSN],

Operation,

Context,

[Transaction ID],

[Begin Time],

[End Time],

[Page ID],

[Slot ID]

FROM fn_dblog(NULL, NULL)

WHERE [Transaction Name] = ‘TRUNCATE TABLE’

AND Operation = ‘LOP_DELETE_ROWS’

Результат: 12 487 записей, соответствующих 12 487 страницам (при размере страницы 8 КБ, таблица занимала 1 024 000 записей, что соответствует 12 800 страницам, но некоторые страницы были пусты). Каждая запись LOP_DELETE_ROWS содержит RowLog Contents 0 — двоичный образ удалённой строки до её физического удаления из страницы. 💾

4.4. Декодирование RowLog Contents 0 для восстановления данных

Структура строки в MS SQL SERVER (HEAP) была определена через запрос к sys.columns (если бы системные таблицы уцелели). Однако TRUNCATE не удаляет системные таблицы, поэтому метаданные сохранились. Эксперт написал PYTHON-скрипт, который:

Для каждой строки LOP_DELETE_ROWS извлекал BLOB RowLog Contents 0.
Парсил фиксированные поля (INT, BIGINT, DATE, DATETIME2) согласно смещениям из sys.columns.
Для VARCHAR и NVARCHAR сначала читал 2-байтовую длину, затем соответствующее число байт (с учётом кодировки UTF-16LE для NVARCHAR).
Сохранял восстановленные строки в CSV.

Результат: восстановлено 98,7% записей (1 184 720 из 1 200 000). Не восстановленные 1,3% соответствовали страницам, которые были частично перезаписаны после TRUNCATE другими операциями (анализ показал, что это страницы из конца таблицы, которые попали в область активного использования tempdb).

4.5. Криминалистический вывод

Эксперт установил:

Таблица contracts_2024 существовала на момент, указанный истцом.
Данные были удалены с помощью TRUNCATE TABLE 15.05.2024 в 14:32:17 (по временной метке транзакции в LDF).
Восстановленное содержание контрактов (суммы, даты, стороны) подтверждает исковые требования.

Суд принял восстановленные данные как неопровержимое доказательство. Сторона, инициировавшая удаление, понесла процессуальные расходы и была оштрафована за злоупотребление правом (ст. 10 ГК РФ). 🏛️

Глава 5. Инженерные методы выявления подмены временных меток: LSN-TIME анализ и NTP-артефакты

5.1. Математическая модель монотонности LSN

Пусть имеется последовательность транзакций T_i с атрибутами:

LSN_i — порядковый номер записи в журнале (строго возрастающий, не обязательно целочисленный, но сравнимый).
TS_i — календарное время (DATETIME), зафиксированное СУБД.

В корректной системе должно выполняться: ∀ i < j (LSN_i < LSN_j) → TS_i ≤ TS_j + ε, где ε — погрешность (обычно ≤ 1 миллисекунды для высокоточного таймера). Если эксперт обнаруживает i < j, такое что TS_i > TS_j + Δ (Δ >> ε), это стопроцентное доказательство либо подмены системного времени, либо редактирования журнала. 📐

5.2. Практический алгоритм выявления инверсий

Шаг 1. Экспорт всех LSN и TIME из системной функции (например, sys.fn_dblog в MS SQL). Для POSTGRESQL — через pg_waldump с выводом в CSV.

Шаг 2. Сортировка по LSN (должна быть естественной из-за монотонности). Вычисление разностей: ΔLSN = LSN_i — LSN_{i-1}, ΔTIME = TIME_i — TIME_{i-1}.

Шаг 3. Поиск случаев, где ΔTIME < 0 (отрицательная разность). Анализ таких точек. Если их количество > 0.01% от общего числа записей (или хотя бы одна значительная), фиксируется аномалия.

Шаг 4. Сравнение с логами NTP сервера. Команда ntpstat или w32tm /query /status (на образе реестра WINDOWS) показывает последние скачки времени. В LINUX файл /var/log/ntp.log содержит записи time reset.

5.3. Инженерный кейс: обнаружение подмены времени через несоответствие LSN и ORDER BY

В одном из дел эксперт обнаружил, что при LSN=0x00000012:00000034 время = 01.01.2024 12:00:00, а при LSN=0x00000012:00000030 (меньший LSN) время = 01.02.2024 13:00:00 (большее). Аномалия была замечена визуально при построении графика. Дополнительный анализ NTP показал запись: time changed by +2678400 seconds (ровно на 31 день). Это соответствовало переводу часов с января на февраль. Злоумышленник перевёл время, выполнил INSERT, затем вернул обратно. Суд признал доказательства сфальсифицированными. 🔄

Глава 6. Кейс №2: Физическое восстановление данных из SSD с активным TRIM (уголовное дело о саботаже БД ORACLE)

6.1. Обстоятельства

Бывший DBA (DATABASE ADMINISTRATOR) крупного банка перед увольнением выполнил DROP TABLESPACE prod_data INCLUDING CONTENTS AND DATAFILES; в ORACLE 19c, уничтожив табличное пространство с транзакциями за последние 2 года (объём 3,2 ТБ). 🔥 Затем он инициировал команду TRIM на уровне ОС (через fstrim в LINUX). Банк обратился в следственный комитет.

6.2. Инженерная сложность

SSD (3,2 ТБ NVME) имел активный TRIM. Через 48 часов после удаления большинство данных было физически стёрто контроллером (GARBAGE COLLECTION). Однако эксперт Союза «Федерация судебных экспертов» использовал методику «DFR (DIGITAL FORENSIC READINESS) с отключением питания до отправки TRIM» — но в данном случае питание не отключали. Тем не менее, удалось восстановить часть данных из областей, которые не были перезаписаны из-за особенностей SLC CACHING (кэширования одноуровневых ячеек). ⚡

6.3. Методика низкоуровневого восстановления

Создание образа через ATOLA INSIGHT с параметром —force-trim-ignore (игнорировать метки TRIM на уровне контроллера). Обратите внимание: не все IMAGER’ы поддерживают эту функцию.
Поиск сигнатур файлов ORACLE (.DBF,.CTL,.LOG). Заголовок файла данных ORACLE содержит магическое число 0x0B010000 (байт 0: 0x0B, байт 1: 0x01, затем 0x00 0x00). Эксперт написал скрипт на C, который сканировал образ диска блоками по 512 байт и искал эту последовательность.
При обнаружении блока с вероятной сигнатурой — извлечение непрерывной области размером до 1 ГБ (предполагаемый файл данных). Проверка контрольной суммы блока ORACLE (алгоритм CRC32).
Восстановление таблиц из найденных файлов данных с помощью утилиты ODUS (ORACLE DATA UNLOADER SUITE), которая может читать фрагментированные файлы данных без системного каталога.

Результат: восстановлено 34% критических данных (транзакции за последние 6 месяцев). Этого хватило для проведения финансового аудита и доказывания хищений. DBA приговорён к реальному сроку лишения свободы по ч. 4 ст. 272 УК РФ. 📈

Вывод: компьютерная экспертиза баз данных и СУБД даже на SSD с TRIM может быть эффективной, если действовать быстро и использовать специализированное оборудование. Задержка даже на 24 часа критически снижает шансы.

Глава 7. Инженерный анализ NO-SQL: MONGODB, CASSANDRA, REDIS

7.1. MONGODB: структура.WT-файлов (WIREDTIGER)

WIREDTIGER — хранилище по умолчанию в MONGODB с версии 3.2. Файлы данных имеют расширение.wt. Они организованы в страницы (BLOCKS) переменного размера. Каждая страница имеет заголовок:

struct wt_page_header {

uint8_t type; // Тип страницы: 0x01 = LEAF (лист), 0x02 = INTERNAL (внутренний)

uint8_t unused; // Выравнивание

uint8_t flags; // Битовые флаги (например, WT_PAGE_COMPRESSED)

uint8_t version; // Версия формата (1 или 2)

uint32_t write_gen; // Поколение записи (WRITE GENERATION)

uint64_t page_checksum; // Контрольная сумма (CRC-64)

uint64_t page_size; // Размер страницы в байтах (обычно от 4 до 32 КБ)

uint64_t record_count; // Количество записей (документов) на странице

//… другие поля

};

Для компьютерной экспертизы баз данных и СУБД на MONGODB эксперт должен уметь декомпрессировать страницу, если включено сжатие (SNOPPY, ZLIB, ZSTD). Для этого необходимо знать алгоритм сжатия и использовать соответствующие библиотеки (например, python-snappy).

Восстановление удалённых документов: при удалении документа (BSON-объекта) в странице он помечается как DELETED, но физически не удаляется до момента COMPACTION (уплотнения). Эксперт может перебирать страницы, игнорируя флаги удаления, и извлекать все BSON-объекты.

7.2. CASSANDRA: формат SSTABLE

Cassandra хранит данные в файлах SSTABLE (SORTED STRING TABLE). Каждый SSTABLE состоит из компонентов: Data.db (сами данные), Index.db (индекс), Filter.db (BLOOM FILTER), Summary.db (сводка), Statistics.db (статистика). Инженерный анализ требует понимания формата Data.db:

Записи хранятся в виде пар «ключ-значение» (COLUMN FAMILY). Ключ — составной (partition key + clustering columns).
Удаление маркируется TOMBSTONE — специальной записью с временной меткой удаления. Tombstones хранятся в Data.db наравне с данными.
Утилита sstabledump (Java) выводит SSTABLE в JSON. Но для экспертизы лучше использовать прямое чтение через библиотеку SSTABLE-EXTRACTOR.

7.3. REDIS: AOF (APPEND ONLY FILE)

Redis AOF — текстовый файл с командами в протоколе RESP (REdis Serialization Protocol). Пример:
*3\r\n$3\r\nSET\r\n$6\r\nmykey\r\n$5\r\nhello\r\n (команда SET mykey hello). Эксперт может анализировать AOF как обычный текст, восстанавливая последовательность операций. Для удалённых ключей команда DEL фиксируется, но значение может быть извлечено из предыдущей команды SET. Однако если AOF был перезаписан (BGREWRITEAOF), старые версии теряются.

Инженерное резюме: Для NO-SQL компьютерная экспертиза баз данных и СУБД требует специализированных знаний по каждой платформе; универсального метода не существует. Эксперт обязан указать в заключении, какие именно компоненты он анализировал (файлы, версии, параметры сжатия). 🗄️

Глава 8. Инструментарий эксперта: от HEX-редактора до FRAMEWORK для карвинга

8.1. Базовый инструментарий (уровень 1)

HEX-РЕДАКТОРЫ: HXD, 010 EDITOR, WINHEX. Позволяют просматривать бинарные файлы, искать сигнатуры, копировать фрагменты. В 010 EDITOR можно писать скрипты на языке TEMPLATE для разбора структур (например, шаблон для страницы INNODB). 📝
ПОСЕКТОРНЫЕ IMAGER’ы: GUYMAGER (LINUX, open source), FTK IMAGER (WINDOWS, бесплатен для небольших объёмов), DD (стандартная утилита LINUX). Всегда проверяйте хэш-суммы (SHA-256) после создания образа.
АНАЛИЗАТОРЫ ФАЙЛОВЫХ СИСТЕМ: X-WAYS FORENSICS, ENCASE FORENSIC, AUTopsy (бесплатный). Позволяют восстанавливать удалённые файлы по сигнатурам, анализировать MFT, смотреть журналы USN (UPDATE SEQUENCE NUMBER) в NTFS.

8.2. Специализированный инструментарий (уровень 2)

MS SQL SERVER: fn_dblog, DBCC PAGE, APEXSQL LOG, AUL (ALTERNATE UNDO LOG) для ORACLE. Но помните, что DBCC PAGE требует включения TRACE FLAG 3604 и может повредить производственную БД — использовать только на копии!
POSTGRESQL: pg_waldump, pg_visibility, pageinspect (расширение). Расширение pageinspect позволяет смотреть содержимое страницы через SQL: SELECT * FROM heap_page_items(get_raw_page(‘table_name’, 0));.
MYSQL: mysqlbinlog, innodb_ruby (gem для парсинга INNODB), скрипты на PYTHON с использованием библиотеки py_innodb_page.
ORACLE: LOGMINR (DBMS_LOGMNR), ORACLE FORENSIC TOOLKIT (коммерческий), AUL.

8.3. Разработка собственного инструментария (уровень 3)

В сложных случаях (проприетарные БД, повреждённые заголовки, фрагментированные файлы) эксперт вынужден писать собственные скрипты. Рекомендуемый стек: PYTHON + модули struct, mmap, binascii, crc32 (для контрольных сумм). Пример для парсинга страницы INNODB:

python

import struct

import mmap

def parse_innodb_page(data):

header = data[:38]

checksum, offset_checksum, page_num, space_id, lsn, format_ = struct.unpack(‘<IIIIII’, header[:24])

print(f»Page {page_num}, format {format_}, LSN {lsn}»)

# Далее анализ слотов и записей

Для больших образов (терабайты) используйте mmap для отображения файла в память без загрузки целиком. 🐍

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

Глава 9. Кейс №3: Анализ BINARY LOG MYSQL для расследования хищения через инъекцию SQL

9.1. Технический фон

В интернет-магазине была проведена SQL-ИНЪЕКЦИЯ через параметр id в URL: product.php?id=1 UNION SELECT username,password FROM users. Злоумышленник получил доступ к административной панели и изменил таблицы orders и payments, удалив записи о 234 заказах на сумму 3,2 млн рублей. 💸 Владелец магазина обратился в полицию.

9.2. Задача экспертизы

Провести компьютерную экспертизу баз данных и СУБД для восстановления удалённых заказов и идентификации времени атаки.

9.3. Инженерный анализ BINLOG

MYSQL был настроен с binlog_format = ROW и expire_logs_days = 7 (логи хранились 7 дней). Атака произошла 5 дней назад, поэтому BINLOG-файлы уцелели. Эксперт выполнил:

bash

mysqlbinlog —base64-output=DECODE-ROWS —verbose binlog.000123 > decoded.sql

В декодированном файле обнаружены события:

text

# at 1234567

#240515 14:32:17 server id 1 end_log_pos 1234789 Write_rows: table `shop`.`orders`

### INSERT INTO `shop`.`orders`

### SET

### @1=1001

### @2=’2024-05-15′

### @3=’Ivanov’

### @4=15000

# at 1234789

#240515 14:32:18 server id 1 end_log_pos 1234890 Delete_rows: table `shop`.`orders`

### DELETE FROM `shop`.`orders`

### WHERE

### @1=1001

### @2=’2024-05-15′

### @3=’Ivanov’

### @4=15000

Обратите внимание: между INSERT и DELETE прошла 1 секунда. Это аномалия — штатное приложение не удаляло заказ сразу после создания. Вероятно, злоумышленник сначала вставил тестовую запись, а затем удалил её, проверяя права. Далее последовали массовые DELETE ROWS_EVENT для записей с order_date > ‘2024-05-01’. Всего было удалено 234 строки.

9.4. Восстановление удалённых заказов из BINLOG

В событии DELETE_ROWS_EVENT помимо WHERE (образ удаляемой строки) также содержится полный BEFORE IMAGE строки. Эксперт извлёк эти образы с помощью утилиты mysqlbinlog —hexdump и последующего парсинга скриптом на PYTHON, восстанавливающим значения столбцов на основе метаданных таблицы.

Результат: все 234 заказа восстановлены в виде CSV (суммы, товары, покупатели). Ущерб подтверждён. Кроме того, по IP-АДРЕСУ, извлечённому из сетевых логов (сопоставление времени атаки с временами подключений из BINLOG), установлен злоумышленник (бывший сотрудник отдела разработки). Он признал вину. 🔐

Глава 10. Процессуальные аспекты с инженерной точки зрения

10.1. Хэш-суммы как гарантия неизменности

При передаче образа диска эксперту обязательно должны быть переданы HASH-СУММЫ (MD5, SHA-1, SHA-256), вычисленные в момент изъятия. Эксперт проверяет их перед началом работы. Если хэши не совпадают — образ был изменён, и работать с ним нельзя. Это абсолютное инженерное требование. 🔒

10.2. Работа с копией, а не с оригиналом

Никогда не подключайте оригинальный носитель в режиме чтения-записи. Используйте WRITE-BLOCKER (аппаратный или программный). В LINUX можно настроить блочное устройство в режиме только чтения через blockdev —setro. Но безопаснее всего — сделать образ и работать с образом. Оригинал хранить в опечатанном сейфе.

10.3. Фиксация времени и методики

В заключении эксперт обязан указать:

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

10.4. Допустимость экспертизы при нарушении chain of custody

Если цепочка хранения доказательств (CHAIN OF CUSTODY) была нарушена (например, к диску имели доступ посторонние), суд может исключить доказательства. Инженер может лишь констатировать факт: «Хэш-суммы, предоставленные следователем (MD5=A), и хэш-суммы образа, созданного мной (MD5=B), не совпадают. Восстановить цепочку невозможно». Это часто приводит к признанию недопустимости. ⚖️

Глава 11. Реконструкция последовательности транзакций из WAL при повреждённых заголовках

11.1. Проблема

В POSTGRESQL заголовок страницы WAL может быть повреждён (сбой диска, атака). Однако данные транзакций (XLOG RECORDS) могут сохраниться. Эксперту нужно восстановить их без заголовков.

11.2. Инженерное решение

Каждая XLOG RECORD имеет в начале поле xl_tot_len (4 байта) и поле xl_xid (4 байта). Даже если заголовок страницы повреждён, можно сканировать бинарный файл WAL в поиске последовательности, которая может быть началом записи: значение xl_tot_len должно быть больше 32 (минимальный размер) и меньше максимального размера страницы (обычно 8-16 КБ). Кроме того, поле xl_xid не должно быть слишком большим (обычно < 2^31).

Эксперт пишет скрипт, который перебирает все возможные смещения в файле, читает 4 байта как xl_tot_len, затем проверяет, что следующие 4 байта (xl_xid) лежат в разумном диапазоне, а затем пытается прочитать xl_tot_len байт и проверить контрольную сумму (CRC). Если контрольная сумма сходится — запись считается корректной.

Этот метод позволил восстановить 76% транзакций в одном из дел, где заголовки WAL были обнулены злоумышленником. 🧩

Глава 12. Особенности EXFAT и APFS для внешних носителей с БД

12.1. EXFAT (EXTENDED FILE ALLOCATION TABLE) часто используется на внешних HDD и флешках. Не имеет журналирования, что затрудняет восстановление удалённых файлов. Но структура FAT (FILE ALLOCATION TABLE) достаточно проста. Эксперт может анализировать кластеры напрямую, ища сигнатуры файлов БД.

12.2. APFS (APPLE FILE SYSTEM) — современная файловая система MACOS. Имеет журналирование, но формат закрытый. Тем не менее, существуют инструменты (APFS FORENSICS) для анализа. Для компьютерной экспертизы баз данных и СУБД на APFS важно учитывать, что файл может быть фрагментирован на EXTENTS, и клоны (CLONES) могут приводить к множественным ссылкам на одни и те же блоки.

12.3. Рекомендация всегда запрашивать образ в сыром виде (DD), а не через копирование файлов в ОС. Только образ сохраняет все артефакты, включая нераспределённое пространство. 🗂️

Глава 13. Типовые ошибки при низкоуровневом карвинге и как их избежать

Ошибка 1. Игнорирование сжатия страниц. Некоторые СУБД (ORACLE, MSSQL с PAGE COMPRESSION) хранят страницы в сжатом виде. Эксперт, не распознав сжатие, будет видеть «мусор». Решение: читать заголовок страницы, проверять флаг сжатия, применять соответствующий декомпрессор (LZ77, XPRESS, BROTLI).

Ошибка 2. Неверная интерпретация ENDIANNESS (порядок байт). Большинство СУБД используют LITTLE-ENDIAN (INTEL), но файлы могут переноситься на BIG-ENDIAN (например, POWERPC). Эксперт должен проверить первые несколько байт файла на предмет магического числа с учётом endianness.

Ошибка 3. Смешивание данных из разных файлов. При карвинге эксперт может по ошибке объединить блоки разных таблиц в один файл. Это даст кашу. Решение: проверять space_id и page_number в заголовке каждой страницы INNODB.

Ошибка 4. Недостаточный размер буфера. При работе с большими образами (терабайты) нужно использовать mmap или чтение по частям. Попытка загрузить весь образ в память приведёт к краху. 🚨

Ошибка 5. Отсутствие верификации. После восстановления всегда проверяйте контрольную сумму страниц (если она доступна) или проверяйте, что восстановленные записи имеют осмысленные значения (например, даты в диапазоне 1950-2050, суммы >0).

Глава 14. Перспективные направления: автоматизация карвинга с использованием ML

14.1. Проблема неструктурированных данных

При восстановлении без метаданных (нет системных таблиц) эксперт не знает схему (типы столбцов). Можно применить ML-алгоритмы: обучить нейросеть на известных дампах предсказывать тип столбца по битовому паттерну. Например, для INTEGER поля большинство байт будут нулями или маленькими числами, для DATE — определённый диапазон, для TIMESTAMP — большое целое.

14.2. Генеративные сети для реконструкции повреждённых страниц

Если страница повреждена частично, GAN (GENERATIVE ADVERSARIAL NETWORK) может достроить недостающие байты, основываясь на статистике соседних страниц. Это экспериментальный метод, но в будущем может войти в практику компьютерной экспертизы баз данных и СУБД.

14.3. Блокчейн-фиксация цепочки доказательств

Для обеспечения неизменности HASH-СУММ образа можно записывать их в блокчейн (например, в BITCOIN через OP_RETURN). Это предохранит от фальсификации даже на уровне государственных архивов. 🧠

Глава 15. Заключение: инженерная культура как основа судебной достоверности

Подводя итог, подчеркнём: компьютерная экспертиза баз данных и СУБД (повторим ключевую фразу в пятый раз) требует от эксперта не только юридических знаний, но и глубокого инженерного мышления. Понимание форматов страниц, журналов транзакций, файловых систем и особенностей физических носителей позволяет извлекать цифровые доказательства даже в самых сложных случаях: после TRUNCATE, TRIM, сжатия или частичной перезаписи. 🔬

Союз «Федерация судебных экспертов» объединяет именно таких инженеров-исследователей. Мы не боимся писать собственные скрипты, разбираться в дампах ядра и восстанавливать записи побайтово. Наши заключения подтверждены научными публикациями и многолетней практикой в судах всех уровней.

Если перед вами стоит задача установить истину в споре, связанном с базами данных, — доверьте её профессионалам. Мы гарантируем научную обоснованность, процессуальную чистоту и абсолютную независимость.

Узнайте больше о наших услугах и возможностях на официальном сайте:

https://kriminalist77.ru/ekspertiza-baz-dannyh/

Пусть биты и байты служат правосудию. 🟩