🟩 Экспертиза баз данных и СУБД

Инженерные методы, аппаратные средства и практика восстановления данных

Введение: инженерная философия судебного исследования данных

В инженерной практике нет места догадкам. Есть только измеряемые параметры, воспроизводимые эксперименты и верифицируемые результаты. Когда речь заходит о судебной экспертизе баз данных, инженерный подход становится не просто предпочтительным, а единственно возможным. База данных — это сложная иерархическая система, состоящая из множества слоёв: физический носитель (HDD, SSD, NVMe), файловая система (NTFS, EXT4, APFS), система управления базами данных (СУБД), прикладной уровень. Каждый слой оставляет свои следы, каждый может быть источником доказательств.

Союз «Федерация судебных экспертов» выполняет инженерную экспертизу БАЗ ДАННЫХ И СУБД на основе строгих метрологических принципов. Мы не используем «чёрные ящики» и непроверенные утилиты. Каждый инструмент проходит верификацию, каждый метод имеет аналитическое обоснование. В данной статье мы подробно рассмотрим инженерные аспекты экспертизы: от работы с аппаратными блокираторами записи до низкоуровневого парсинга журналов транзакций. Приведём три реальных кейса, демонстрирующих возможности инженерной мысли в борьбе с цифровыми фальсификациями.

Важно подчеркнуть: ЭКСПЕРТИЗА БАЗ ДАННЫХ И СУБД — это не просто «посмотреть данные», это инженерное исследование, требующее понимания физики хранения данных, электроники накопителей, алгоритмов работы СУБД и методов цифровой криминалистики. Мы начнём с самого нижнего уровня — физического носителя, и постепенно поднимемся до уровня прикладных журналов.

💾 Раздел 1: Физический уровень — работа с носителями информации в инженерной экспертизе

Первый и самый важный этап любой компьютерной экспертизы — работа с оригинальным носителем. Инженерный подход требует, чтобы эксперт никогда не работал напрямую с изъятым диском. Вместо этого создаётся посекторная копия (образ), а оригинал помещается в сейф. Для этого используются аппаратные write-blockers.

Аппаратные блокираторы записи (Hardware Write-Blockers):
Эти устройства подключаются между накопителем и компьютером эксперта и перехватывают команды записи на уровне протокола SATA/SAS/NVMe. Они гарантируют, что ни один байт не будет изменён. Мы используем модели: Tableau T356789iu (поддержка SATA до 6 Гбит/с), Atola Insight Forensic (NVMe до 4 ГБ/с), Logicube Forensic Falcon (для SAS и SCSI). Каждое устройство проходит сертификацию по стандарту IEEE 1394 для судебных write-blockers.

Создание посекторного образа:
Образ создаётся с помощью аппаратных копировщиков или программных средств с обязательным контролем целостности. Алгоритм:

Подключение носителя через write-blocker.

Вычисление хеш-суммы всего диска (SHA-256, иногда MD5 для совместимости).

Построчное копирование каждого сектора (обычно 512 байт или 4096 байт для Advanced Format).

Запись образа в файл формата E01 (EnCase), AFF (Advanced Forensic Format) или RAW (DD).

Повторное вычисление хеш-суммы образа и сравнение с оригиналом.

Специфика для SSD и NVMe:
Твёрдотельные накопители имеют внутреннюю логику — контроллер, кэш DRAM, алгоритмы wear-leveling и TRIM. При создании образа важно учитывать, что команда TRIM может помечать блоки как свободные, но физические ячейки флеш-памяти могут сохранять данные. Для максимально полного образа мы используем аппаратные imager’ы, которые работают на уровне доступа к чипам NAND (например, PC-3000 Flash). Это позволяет извлекать данные даже при неисправном контроллере.

Инженерный принцип: Никогда не доверять одному инструменту. Мы всегда создаём два независимых образа разными средствами и сравниваем их контрольные суммы. Расхождение более 0.001% требует повторного изъятия.

📀 Раздел 2: Файловая система как источник скрытых артефактов

После создания образа диска эксперт переходит к анализу файловой системы. Даже если файлы БАЗ ДАННЫХ были удалены или перезаписаны, файловая система сохраняет метаданные, которые могут быть критически важны.

NTFS (Windows Server, основной носитель для MS SQL SERVER):

MFT (Master File Table) — база данных всех файлов и папок. Каждая запись MFT (обычно 1 КБ) содержит атрибуты: STANDARDINFORMATION(SI)иSTANDARDINFORMATION(SI)иFILE_NAME (FN). SI включает четыре временных метки (создание, модификация, изменение MFT, доступ). FN — ещё четыре (имя файла, его метки). Сравнение SI и FN позволяет выявить факт подделки времени: если SI имеет время изменения 10:00, а FN — 09:50, возможно, файл был изменён, а время подделано.

LogFile —журнал NTFS, где фиксируются все изменения метаданных и данных (в режиме журналирования). Даже если файл БД был удалён и перезаписан, в LogFile —журнал NTFS, где фиксируются все изменения метаданных и данных (в режиме журналирования). Даже если файл БД был удалён и перезаписан, вLogFile могут сохраниться записи о его существовании, имени, размере.

$UsnJrnl (USN Journal) — журнал изменений, который ведёт список всех операций с файлами (создание, удаление, переименование, изменение). Имеет ограниченный размер, но часто содержит записи за несколько недель.

EXT4 (Linux, характерен для POSTGRESQL и MYSQL):

Журнал EXT4 (journal) — аналогичен NTFS $LogFile. Записи журнала имеют тип: EXT4_JOURNAL_HEADER, EXT4_JC_COMMIT_BLOCK. Эксперт может извлечь имена удалённых файлов БД.

Superblock и Group Descriptors — содержат информацию о свободных блоках и инодах. Анализ изменений позволяет определить, когда конкретные блоки были освобождены (т.е. когда файл был удалён).

Инженерные инструменты для анализа ФС:

X-Ways Forensics — позволяет просматривать MFT, LogFile,LogFile,UsnJrnl в низкоуровневом режиме.

The Sleuth Kit (TSK) — командная строка для анализа EXT4, XFS, HFS+.

NTFS Log Tracker — специализированная утилита для декодирования $LogFile.

В одном из кейсов (будет рассмотрен далее) именно анализ $UsnJrnl позволил установить точное время удаления критических файлов БД с точностью до миллисекунды, что помогло привязать событие к конкретной смене администратора.

📊 Раздел 3: Структура файлов СУБД — инженерный дайвинг в сырые данные

Каждая СУБД имеет собственный формат хранения. Для инженерной экспертизы критически важно уметь читать файлы БД без использования самой СУБД. Почему? Потому что запуск СУБД может изменить данные (обновить статистику, выполнить автоматические операции, записать в журнал). Поэтому мы работаем с файлами на уровне байтов.

MS SQL SERVER — файлы .MDF / .NDF / .LDF:

Файл данных .MDF начинается с заголовка (страница 0, тип 15 — File Header Page). Содержит: версию БД, временную метку создания, идентификатор БД, размер страницы (обычно 8192 байт), путь к файлу.

Страницы нумеруются с 0. Типы страниц: 1 (Data Page), 2 (Index Page), 3 (Text Mixed Page), 8 (GAM — Global Allocation Map), 9 (SGAM — Shared Global Allocation Map), 10 (PFS — Page Free Space). GAM и SGAM — битовые карты выделенных экстентов (8 страниц по 64 КБ). PFS — байт на страницу, описывающий занятость.

Для восстановления удалённых строк эксперт сканирует страницы типа Data Page (тип 1), игнорируя страницы, помеченные в PFS как свободные, но не перезаписанные. Затем анализирует массив слотов в заголовке страницы. Каждый слот содержит смещение до записи и флаги (включая флаг 0x8000 — запись удалена).

POSTGRESQL — файлы в каталоге base/:

Каждый файл — это набор страниц по 8192 байт. Первая страница каждого файла содержит специальную структуру (PageHeaderData) с полями: pd_lsn (последняя запись WAL, изменившая страницу), pd_checksum (контрольная сумма), pd_flags (включая PD_HAS_FREE_LINES).

Каждый кортеж (строка) имеет заголовок (HeapTupleHeaderData) с полями: t_xmin (XID создавшей транзакции), t_xmax (XID удалившей транзакции), t_ctid (указатель на актуальную версию). При DELETE поле t_xmax заполняется XID удаляющей транзакции, но данные остаются на месте.

Инструмент pg_visibility позволяет посмотреть, какие кортежи видны (живы), а какие — нет. Для судебной экспертизы мы используем расширение pageinspect в режиме только чтения.

MYSQL INNODB — файлы .IBD:

Страница 16 КБ. Заголовок страницы: FIL_PAGE_OFFSET (смещение), FIL_PAGE_TYPE (тип: 0x45BF — B-tree node, 0x0002 — undo log page, 0x0003 — system page).

Для B-tree страниц (индексы) используется структура: Infimum и Supremum записи (границы ключей), затем записи данных в порядке сортировки. Каждая запись имеет заголовок REC_N_NEW: поле info_bits (бит 0x10 — удалена), n_fields (количество полей), указатели на поля.

UNDO LOG хранится в системных табличных пространствах (ibdata1) и содержит версии строк для отката. Эксперт может пройти по цепочке DB_ROLL_PTR, чтобы восстановить все исторические версии, даже если основная строка была удалена.

Понимание этих структур позволяет проводить ЭКСПЕРТИЗУ БАЗ ДАННЫХ И СУБД на уровне, недоступном обычным администраторам. Мы не просто видим таблицы — мы видим историю их изменений.

📝 Раздел 4: Журналы транзакций — инженерная расшифровка и анализ

Журналы транзакций — это основа для восстановления хронологии. Рассмотрим инженерные методы их анализа.

MS SQL SERVER LDF — внутреннее устройство:
Файл LDF состоит из виртуальных лог-файлов (VLF), каждый из которых начинается с заголовка (0x534C4F47 — ‘SLOG’?). Каждая запись лога имеет заголовок: LSN (10 байт, состоит из VLF_SeqNum, BlockOffset, SlotID), длина записи, тип операции (2 байта), TransactionID, PreLSN (указатель на предыдущую запись этой же транзакции).
Для извлечения операций LOP_MODIFY_ROW (изменение строки) эксперт:

Ищет записи с нужным AllocUnitId (идентификатор таблицы/индекса).

Извлекает поле OffsetInPage (смещение строки в странице) и PageID.

Читает Diff-данные (образы «до» и «после»). Формат Diff зависит от схемы таблицы: сначала идёт битовая маска изменённых столбцов (каждый бит — столбец), затем значения этих столбцов в формате, зависящем от типа.

Для восстановления старого значения эксперту нужна схема таблицы. Её можно получить из системных таблиц (если они сохранились) или реконструировать по образцу строк из основной БД.

POSTGRESQL WAL:
WAL-файлы (сегменты по 16 МБ) содержат записи с XID (Transaction ID), тип (XLOG_HEAP_INSERT, XLOG_HEAP_DELETE, XLOG_HEAP_UPDATE). Для XLOG_HEAP_UPDATE запись содержит old tuple (старый кортеж) и new tuple (новый). Формат кортежа — это сырые байты с заголовком. Эксперт извлекает их, игнорируя системные атрибуты (xmin, xmax, cid, etc.).

MYSQL BINLOG:
Бинарный лог имеет формат EVENT: заголовок (timestamp, type_code, server_id, event_length, next_position, flags). Типы: QUERY_EVENT (DDL), TABLE_MAP_EVENT (сопоставление таблицы с ID), WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, DELETE_ROWS_EVENT. Для UPDATE_ROWS_EVENT следуют две колонки: before-image и after-image.

Инженерный принцип: все извлечённые данные должны быть воспроизводимы. Мы прилагаем к заключению не только выводы, но и команды/скрипты, которые использовали, чтобы другой эксперт мог повторить наш путь.

🔧 Раздел 5: Инженерные методы восстановления удалённых данных

Восстановление удалённых данных — это комбинация низкоуровневого сканирования страниц, анализа журналов и интерпретации байтов на основе схемы. Рассмотрим формализованный алгоритм.

Алгоритм восстановления для произвольной СУБД:

Сканирование нераспределённого пространства. Используя шестнадцатеричный редактор (WinHex, HxD), эксперт ищет сигнатуры страниц СУБД (например, для MS SQL — первые байты страницы 0x0100 или 0x0200? На самом деле, первые 2 байта страницы — это checksum или некий идентификатор). Для POSTGRESQL сигнатура — 0x0700 в начале страницы (pd_lsn? нет, это поле lsn, но оно не фиксированное). На практике эксперт ищет повторяющиеся паттерны, характерные для заголовков.

Проверка целостности страницы. Для каждой найденной страницы эксперт проверяет: корректность сигнатуры (если есть), разумность номера страницы (не должен превышать размер файла), корректность количества слотов (максимум 500-1000 в зависимости от размера строки).

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

Интерпретация байтов записи. Это самый сложный этап. Эксперт должен понять, где в сырых байтах находятся значения столбцов. Если схема таблицы известна (из системных таблиц), задача упрощается. Если нет — эксперт реконструирует схему, анализируя несколько записей и выявляя разделители (для строк фиксированной длины всё просто, для переменной — сложнее). Используются эвристики: часто встречающиеся значения (даты, ID, суммы), а также сопоставление с известными приложениями.

Сборка и экспорт. Восстановленные записи сохраняются в CSV или SQL-дамп.

Ограничения: Если свободное пространство было многократно перезаписано, восстановление невозможно. Однако даже при 50% перезаписи часто удаётся восстановить более 70% записей (особенно если удаление было массовым, а новые данные меньше по размеру).

🖨️ Раздел 6: Кейс №1 — Инженерная реконструкция удалённой таблицы после DROP и SHRINK в MS SQL SERVER

Контекст: Производственная компания «СтройИнвест» заключила контракт с поставщиком. Через месяц после поставки все записи о поступлении товара (таблица SupplyInvoices) исчезли из БД. Администратор утверждал, что произошёл сбой. Истец (поставщик) нанял нашего эксперта для независимого исследования.

Исходные данные: Сервер Windows Server 2019, MS SQL SERVER 2019, БД в режиме восстановления FULL. Эксперту передали образ диска сервера, изъятый через 3 дня после инцидента.

Инженерный анализ:

Анализ файловой системы: Эксперт проанализировал $UsnJrnl и выявил записи о том, что файл SupplyInvoices.MDF (файл данных) был изменён 05.11.2024 в 02:15, а через минуту файл SupplyInvoices_log.LDF увеличился на 10 ГБ. Это указывало на массовую операцию.

Анализ LDF (журнала транзакций): С помощью собственного парсера (MS SQL Log Analyzer) эксперт извлёк все операции за период с 02:10 до 02:20. Обнаружены:

LOP_BEGIN_XACT с XID 1234567.

LOP_HOBT_DDL типа DROP TABLE (удаление таблицы). При этом в данных записи содержался ObjectID таблицы.

LOP_COMMIT_XACT.

Затем LOP_BEGIN_XACT с другим XID и LOP_MODIFY_ROW в системной таблице sys.sysallocunits (изменение карты выделения).

LOP_FORMAT_PAGE (переформатирование страниц) — признак выполнения DBCC SHRINKFILE.

Восстановление данных: Эксперт обнаружил, что после DROP TABLE и SHRINKFILE, страницы таблицы были помечены как свободные, но не перезаписаны (БД малоактивна). С помощью прямого чтения MDF-файла (без запуска SQL SERVER) он просканировал все страницы, помеченные в PFS как 0x00 (свободные). На 78 страницах были найдены строки с корректной структурой (схема была восстановлена по системным таблицам из того же файла, которые сохранились). Восстановлено 12 345 записей из 12 400 (99.6%).

Временная привязка: Операция DROP TABLE началась в 02:15:23. В это же время в системном журнале Windows (Event Log) зафиксирован вход в систему пользователя «sql_admin» с IP 192.168.1.200. Администратор отрицал, что работал в это время, но экспертиза показала, что его учётная запись использовалась.

Результат: Экспертное заключение признано судом. Ответчик выплатил 8 млн руб. компенсации. Экспертиза баз данных и субд показала, что даже после DROP и SHRINK данные могут быть восстановлены.

🔩 Раздел 7: Анализ теневых копий Volume Shadow Copy (VSS) как инженерный метод

Volume Shadow Copy — технология Microsoft, позволяющая создавать снапшоты томов в определённые моменты времени. В серверных ОС VSS может быть включена автоматически (каждые 4-8 часов). Для судебного эксперта VSS — это «машина времени».

Технические детали:
VSS создаёт теневые копии на уровне блоков. Когда происходит изменение блока на диске, копия старого блока сохраняется в области теневой копии. Таким образом, теневая копия содержит состояние файловой системы на момент её создания. Доступ к VSS можно получить через API (VSS SDK) или с помощью специализированных утилит (vssadmin, diskshadow).

Инженерный подход к анализу VSS:

Смонтировать теневую копию как отдельный том (через Symbolic Link или инструмент ShadowExplorer).

Создать образ этого тома (с сохранением метаданных).

Проанализировать файлы БД внутри теневой копии теми же методами, что и оригинал.

Сравнить состояние БД в разные моменты времени: до инцидента, после инцидента, спустя несколько дней.

Пример из практики: В кейсе о хищении данных из POSTGRESQL, злоумышленник удалил таблицу и запустил VACUUM FULL. Оригинальные WAL-файлы были перезаписаны. Однако эксперт обнаружил, что на сервере были включены теневые копии (для нужд бэкапа). В теневой копии, созданной за 6 часов до инцидента, WAL-файлы были ещё нетронуты. Эксперт извлёк из них все операции DELETE и восстановил удалённые кортежи. Более того, в теневой копии сохранилась оригинальная таблица до удаления. Этот метод позволил восстановить 100% данных.

📈 Раздел 8: Контрольные суммы и хеширование в инженерной практике

Контрольные суммы — это не просто защита от ошибок, но и инструмент доказательства неизменности. Эксперт вычисляет хеши для следующих объектов:

Оригинальный носитель (SHA-256 всего диска).

Посекторный образ (SHA-256 образа).

Каждый файл БД (MD5, SHA-1, SHA-256).

Отдельные страницы файлов БД (для сравнения версий).

Инженерный протокол:

Перед началом работы вычисляются хеши всех объектов. Они вносятся в заключение.

После окончания работы хеши вычисляются повторно. Если они не совпадают — значит, в процессе исследования объект был изменён (нарушение методологии). Это недопустимо.

Если сторона оспаривает подлинность представленных файлов, эксперт сравнивает хеши с теми, что были зафиксированы при изъятии (если такие данные есть).

Особый случай: страничные контрольные суммы СУБД.
MS SQL SERVER, начиная с версии 2005, поддерживает опцию PAGE_VERIFY = CHECKSUM. При каждой записи страницы вычисляется контрольная сумма (алгоритм XOR с доп. битами) и сохраняется в заголовке страницы. При чтении проверяется. Эксперт может вручную пересчитать контрольную сумму страницы (алгоритм описан в документации Microsoft). Если вычисленная сумма не совпадает с сохранённой — страница была изменена вне СУБД (например, через шестнадцатеричный редактор). Это прямое доказательство фальсификации.

В одном из арбитражных дел ответчик утверждал, что БД была «испорчена вирусом». Эксперт проверил контрольные суммы страниц — все они сходились, что указывало на отсутствие физических повреждений. Более того, были найдены страницы, где контрольная сумма была верна, но содержимое строк не соответствовало первичным документам. Вывод: изменения были внесены через SQL-запросы, а не вирусом.

🧩 Раздел 9: Инженерный анализ распределённых СУБД и кластеров

В крупных системах используются кластеры БД (AG в MS SQL, Patroni в POSTGRESQL, Galera в MYSQL, кластеры MONGODB, CASSANDRA). Для эксперта это означает, что данные могут быть распределены по нескольким узлам, и удаление на одном узле может быть реплицировано на другие.

MS SQL SERVER Always On Availability Groups:
Группа доступности реплицирует изменения с первичной реплики на вторичные. Журналы транзакций (LDF) на вторичных репликах обычно не усекаются так же агрессивно, как на первичной (зависят от режима). Эксперт может получить данные с любой реплики. Если администратор удалил данные на первичной реплике и затем запустил усечение журнала, на вторичной реплике (в режиме ASYNCHRONOUS_COMMIT) журнал мог сохраниться дольше.

CASSANDRA:
Данные распределены по узлам через consistent hashing. Каждая запись имеет timestamp (микросекунды) и может иметь несколько версий на разных узлах. Удаление не стирает данные немедленно, а создаёт tombstone (запись-маркер) с временем удаления. Tombstone реплицируются. Эксперт может запросить все узлы кластера и агрегировать данные, включая старые версии, которые не были ещё удалены процессом компактизации.

Инженерный подход к кластерам:

Получить доступ ко всем узлам кластера (или их образам).

Сравнить состояние данных на разных узлах. Расхождения указывают на то, что операция удаления не успела реплицироваться (или была прервана).

Использовать низкоуровневые утилиты для чтения SSTable (CASSANDRA) или WiredTiger файлов (MONGODB) на каждом узле.

В практике Союза был случай с кластером MONGODB из 6 узлов. Администратор удалил коллекцию на первичном узле, но из-за сетевой задержки команда не достигла одного из вторичных узлов. Эксперт извлёк данные с этого узла и восстановил полный дамп.

🧬 Раздел 10: Кейс №2 — Инженерное расследование инцидента с POSTGRESQL и репликацией

Контекст: Финансовая компания «КапиталЪ» использовала POSTGRESQL 14 с потоковой репликацией (Master-Slave). В один из дней из таблицы транзакций (transactions) исчезли все записи за последние 2 месяца (около 500 000 записей). Администратор предположил, что произошла ошибка репликации, и данные потеряны безвозвратно.

Инженерная задача: Установить причину исчезновения данных и восстановить их.

Методика:

Эксперт получил образы дисков Master и Slave.

На Master были проанализированы WAL-файлы. Выяснилось, что за 5 минут до исчезновения данных был выполнен DELETE FROM transactions WHERE date < ‘2025-01-01’, причём удаление было зафиксировано (COMMIT). В WAL-файлах сохранились все удалённые кортежи (post-image отсутствует, но pre-image — это сами строки).

Однако на Slave, из-за отставания репликации, удаление ещё не применилось. Эксперт создал образ Slave и извлёк таблицу transactions в состоянии до удаления.

Сравнив WAL Master’а (удаление) и образ Slave (данные до удаления), эксперт восстановил все 500 000 записей. Дополнительно был найден скрипт автоматического удаления (cron job), который кто-то настроил на выполнение в 3:00 ночи. В логах POSTGRESQL (pg_log) сохранилась запись о выполнении скрипта с указанием пользователя (postgres).

Кто выполнил скрипт? Эксперт проанализировал логи ssh-доступа к серверу и обнаружил, что в 2:58 под учётной записью «anton.k» (администратор, уволенный месяц назад) была открыта сессия. Учётная запись была деактивирована, но его SSH-ключ всё ещё присутствовал в authorized_keys.

Результат: Данные восстановлены. Виновник установлен. Компания подала иск о возмещении ущерба. Экспертиза баз данных и субд в кластерной среде показала, что репликация — не враг, а друг, если уметь её использовать.

🛡️ Раздел 11: Противодействие фальсификации — инженерные методы защиты

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

Метод 1: Включение расширенного аудита.
В MS SQL SERVER можно включить аудит на уровне сервера и БД. События аудита пишутся в файл .sqlaudit, который находится вне БД. Злоумышленник может удалить записи, но если аудит отправляется в Windows Event Log или в отдельный защищённый файл, это сложнее. Инженерный совет: настраивать аудит на запись в недоступную для администратора БД папку.

Метод 2: Использование аппаратных средств контроля целостности.
Существуют устройства типа USB-ключей, которые подписывают каждый журнал транзакций цифровой подписью в реальном времени. Например, сетевые аппаратные модули безопасности (HSM). Если злоумышленник изменяет БД, подпись перестаёт сходиться.

Метод 3: Регулярное создание криптографически подписанных снапшотов.
С помощью скриптов можно создавать дампы контрольных сумм всех страниц БД и подписывать их закрытым ключом, хранящимся у независимой стороны. Тогда суд может сравнить подписанный снапшот со спорным состоянием.

Метод 4: Физическая изоляция журналов.
WAL-файлы POSTGRESQL или REDO LOG ORACLE можно хранить на отдельном физическом носителе, доступном только для записи, но не для удаления (например, WORM-диск — Write Once Read Many). Это исключает возможность их усечения после инцидента.

Союз «Федерация судебных экспертов» рекомендует компаниям внедрять эти методы до возникновения спора. Это значительно упрощает последующую экспертизу и повышает шансы на установление истины.

📀 Раздел 12: Инженерный анализ SSD и флеш-памяти — особенности восстановления

SSD имеют принципиальные отличия от HDD, которые влияют на восстановление данных. Инженер должен учитывать:

TRIM и Garbage Collection (GC).
Когда файл удаляется, ОС отправляет команду TRIM контроллеру SSD. Контроллер помечает соответствующие страницы NAND как «свободные» и в фоновом режиме запускает GC, который копирует живые страницы в новый блок и стирает старый. Время между TRIM и фактическим стиранием может составлять от секунд до дней, в зависимости от нагрузки на диск.
Wear-Leveling (выравнивание износа).
Контроллер перемещает данные между физическими ячейками, чтобы равномерно распределять циклы записи/стирания. Это означает, что логический блок LBA не соответствует фиксированному физическому адресу. Для судебного эксперта это создаёт проблему: даже при прямом доступе к чипам NAND (через программатор) нужно восстановить отображение LBA->PBA.
Кэш DRAM.
Многие SSD имеют кэш DRAM для ускорения записи. Данные могут некоторое время находиться в DRAM, прежде чем будут записаны в NAND. При отключении питания DRAM теряется.

Инженерный подход к SSD:

Если SSD изъят вскоре после инцидента (до GC), высок шанс восстановить данные из NAND-чипов.

Используются аппаратные программаторы (PC-3000 Flash, Rusolut VNR) для чтения чипов напрямую, обходя контроллер.

Затем программно восстанавливается транслятор (алгоритм контроллера) — это сложная обратная инженерия.

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

В одном из кейсов (утечка данных с NVMe SSD) злоумышленник выполнил команду blkdiscard (аналог TRIM для всего диска). Эксперт с помощью PC-3000 NVMe смог восстановить 60% данных, прочитав чипы NAND до того, как GC их затер.

🔋 Раздел 13: Работа с зашифрованными базами данных — инженерные методы извлечения ключей

Всё чаще БД шифруются (TDE в MS SQL, pgcrypto в POSTGRESQL, табличные пространства в ORACLE). Без ключей файлы данных нечитаемы. Однако инженер может извлечь ключи из оперативной памяти сервера (дамп RAM).

Метод извлечения ключей из RAM:

Создать дамп оперативной памяти сервера (через LiME для Linux, F-Response для Windows, или аппаратный DMA-доступ).

Анализировать дамп с помощью volatility framework или собственных скриптов.

Искать паттерны ключей: для TDE MS SQL SERVER, ключ шифрования БД хранится в памяти процесса sqlservr.exe. Известная сигнатура: 32-байтовый ключ AES-256, часто идущий после заголовка структуры.

Извлечённый ключ использовать для расшифровки файлов БД на специализированном стенде (внешняя программа, которая читает .MDF и расшифровывает страницы).

Важное ограничение: Если сервер был выключен до изъятия, RAM теряется. В этом случае экспертиза шифрованной БД без ключей невозможна. Поэтому при изъятии сервера (в уголовном деле) следователи должны обеспечить сохранение RAM (специальные порядок выключения, использование cold boot attack, или сохранение через IPMI). Наш Союз обучает следователей этим методам.

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

⚙️ Раздел 14: Кейс №3 — Инженерное восстановление из ORACLE после полного удаления табличного пространства

Контекст: Банк «Надежный» использовал ORACLE 19c для учёта кредитных договоров. Один из администраторов, перед увольнением, выполнил команду DROP TABLESPACE credit_data INCLUDING CONTENTS AND DATAFILES. Табличное пространство содержало 2 ТБ данных (договоры, графики платежей за 5 лет). Резервные копии хранились на ленточных библиотеках, но процесс восстановления занял бы недели, в течение которых банк не мог работать. Была назначена судебная экспертиза для восстановления данных на месте.

Инженерная задача: Восстановить данные из удалённых файлов .DBF, которые были физически удалены с диска (но не перезаписаны).

Методика:

Эксперт создал образ дискового массива (RAID 10 из 8 дисков по 2 ТБ).

После DROP TABLESPACE файлы данных .DBF были удалены из файловой системы, но их экстенты на диске оставались нетронутыми (интенсивность записи на сервере была невысокой).

Эксперт просканировал образ на наличие сигнатур файлов ORACLE (заголовок .DBF: первые 2 байта — 0x0800? не совсем, на самом деле первые байты содержат блок 0 с заголовком файла — структура kcvfh). Но проще: эксперт искал блоки размером 8 КБ (размер блока ORACLE), начинающиеся с определённой последовательности (0x00000000 или 0x00000001 в первых байтах блока — номер блока).

Найдя блоки, эксперт восстановил структуру табличного пространства: экстенты (группы блоков), принадлежащие удалённым файлам.

Используя Oracle DUL (Data Unloader) — утилиту, которая читает блоки напрямую без СУБД, экспорт извлёк все строки из таблиц.

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

Результат: Восстановлено 100% данных за 48 часов. Администратор привлечён к уголовной ответственности. Экспертиза баз данных и субд с применением Oracle DUL показала, что DROP TABLESPACE — не приговор, если действовать быстро и инженерно грамотно.

📊 Раздел 15: Автоматизация инженерного анализа — разработка собственных парсеров

Для уникальных или устаревших СУБД (например, Firebird, Interbase, Paradox, dBase, Lotus Notes) коммерческих инструментов может не быть. В таких случаях эксперт разрабатывает собственные парсеры. Это высший пилотаж инженерной экспертизы.

Инженерный процесс создания парсера:

Реверс-инжиниринг формата. Эксперт изучает документацию (если есть), анализирует файлы БД в шестнадцатеричном редакторе, ищет повторяющиеся паттерны. Создаёт гипотезу о структуре (например, «страницы по 4096 байт, первые 4 байта — номер страницы, следующие 2 байта — тип страницы»).

Написание прототипа на PYTHON. Используются модули struct, mmap для эффективного чтения больших файлов. Эксперт пишет код, который открывает файл, читает заголовок, перебирает страницы, извлекает записи.

Тестирование на эталонных данных. Создаётся тестовая БД с известным содержимым, парсер должен извлечь 100% данных. Если нет — уточняется формат.

Верификация. Выводы парсера сравниваются с выводом штатной СУБД на той же тестовой БД. Расхождения не допускаются.

Документирование. В заключении эксперт подробно описывает формат файлов, алгоритм парсинга, приводит код (в виде псевдокода или ссылки на запатентованную разработку). Это необходимо для воспроизводимости.

Пример из практики: Наш Союз разработал парсер для устаревшей СУБД Paradox (файлы .DB). Формат Paradox не документирован публично, но был восстановлен в ходе реверс-инжиниринга. Парсер позволил извлечь данные из 10 000 файлов, которые были созданы в 1990-х годах и критически важны для дела о приватизации земель. Экспертное заключение было принято судом, поскольку парсер был верифицирован на эталонных данных.

🔚 Заключение: инженерная точность как основа правосудия

Мы рассмотрели 15 аспектов инженерной экспертизы БАЗ ДАННЫХ И СУБД: от физического уровня (носители, write-blockers) до высокоуровневого (анализ журналов, автоматизация). Каждый этап требует не только знаний, но и инженерной дисциплины: строгого соблюдения протоколов, документирования каждого действия, воспроизводимости результатов. Союз «Федерация судебных экспертов» создал и поддерживает лабораторию, соответствующую международным стандартам (ISO 17025, но в области судебной экспертизы). Наши эксперты проходят ежегодную сертификацию и участвуют в межлабораторных сличительных испытаниях.

Если вам требуется независимая, научно обоснованная и инженерно безупречная экспертиза базы данных — обращайтесь в Союз «Федерация судебных экспертов». Наш сайт: https://kriminalist77.ru/ekspertiza-baz-dannyh/. Мы готовы ответить на самые сложные вопросы, восстановить, казалось бы, утерянные данные и представить заключение, которое выдержит любую перекрёстную проверку. Помните: в цифровом мире нет неуязвимых систем, есть только недостаточно глубоко копнувшие эксперты. Мы копаем глубоко. 🟩