Добро пожаловать в мир, где каждый байт имеет значение, а каждая транзакция оставляет неизгладимый инженерный след. 🔧 Мир баз данных — это не просто хранилище информации, это сложнейшая кибернетическая система, где переплетаются логика, физика хранения данных и человеческий фактор. И когда возникает спор, когда кто-то пытается скрыть следы преступления или фальсифицировать факты, на сцену выходит компьютерная экспертиза баз данных и СУБД. 🎯

Я представляю Союз «Федерацию судебных экспертов». Мы — инженеры цифровой истины. Мы не гадаем на кофейной гуще и не пишем «вероятных» заключений. Мы анализируем, вычисляем, реконструируем. В этой статье я расскажу вам, как мы это делаем. С цифрами, схемами и реальными кейсами. Пристегните ремни — будет технически сложно, но очень интересно. ⚙️

Глава 1. Инженерный взгляд на базу данных: от логической модели до физических секторов

Для большинства людей база данных — это абстракция, набор таблиц и запросов. Для инженера-эксперта база данных — это иерархия уровней, каждый из которых может скрывать улики. 🏗️

1. Уровень 1. Логический (реляционная модель). То, что видят пользователи: таблицы, представления, хранимые процедуры. На этом уровне мы анализируем целостность данных, триггеры, ограничения. Но этого слишком мало.
2. Уровень 2. Служебный. Системные таблицы, словарь данных, журналы транзакций, карты распределения страниц. Здесь хранится метаинформация о том, кто, когда и как изменял данные. Это «чёрный ящик» для 99% пользователей.
3. Уровень 3. Физический (файловая система). СУБД хранит данные в файлах.mdf/.ndf (MS SQL),.ibd (MySQL/InnoDB),.dbf (Oracle), каталогах base/ (PostgreSQL). Мы умеем читать эти файлы напрямую, минуя SQL-слой. 🗂️
4. Уровень 4. Секторный (дисковое пространство). Даже если файл удалён или перезаписан, на уровне секторов жесткого диска могут оставаться фрагменты данных. Мы работаем с образами дисков и восстанавливаем то, что СУБД уже «не помнит».

Именно на стыке этих уровней рождается компьютерная экспертиза баз данных и СУБД (первое упоминание ключевой фразы). Мы спускаемся с логического неба на физическую землю.

Глава 2. Почему штатные средства СУБД не годятся для экспертизы?

Это важно понять каждому юристу. 🧑‍⚖️ Когда администратор базы данных говорит: «Я посмотрел логи, там всё чисто», — он использует штатные средства СУБД. А эти средства созданы для администрирования, а не для судебного исследования. У них есть три致命的 ограничения.

• 🔴 Ограничение 1. Они видят только то, что СУБД хочет им показать. Запрос SELECT * FROM sys.fn_dblog(NULL, NULL) в MS SQL не покажет вам физически удалённые строки, которые уже не отражены в карте распределения страниц.
• 🔴 Ограничение 2. Они подвержены обману через SQL-инъекции и подмену представлений. Злоумышленник может создать представление (view), которое скрывает определённые строки, или установить триггер, фильтрующий «неудобные» записи. Штатный SELECT этого не заметит.
• 🔴 Ограничение 3. Они не работают с образами дисков. Если сервер изъят, а СУБД не запущена, штатные средства бесполезны. А мы работаем с «холодными» данными.

Наша экспертиза не использует штатные SQL-запросы для финальных выводов. Мы пишем собственные парсеры, которые читают страницы данных и журналы на уровне сырых байтов. Только так можно достичь истины. 🛡️

Глава 3. Кейс №1: Инженерная реконструкция удалённой таблицы в PostgreSQL

🏭 Производственное предприятие. Системный администратор уволился через день после того, как из базы данных PostgreSQL исчезла таблица «зарплата за декабрь» целиком. Руководство уверено: это месть. Администратор утверждает: «я ничего не удалял, это сбой». Назначена наша экспертиза.

1. Шаг 1. Анализ файловой системы. Сервер работал на Linux (ext4). Мы получили образ диска. В каталоге /var/lib/postgresql/14/main/base/ обнаружили файл с номером relfilenode, соответствующим пропавшей таблице. Файл существовал, но был нулевой длины. Это не штатное поведение. 🕵️
2. Шаг 2. Поиск удалённых версий. В PostgreSQL при выполнении DROP TABLE файл удаляется из каталога, но его содержимое может оставаться на диске до перезаписи. Мы использовали утилиту photorec для извлечения сигнатур страниц PostgreSQL (заголовок страницы — 0x01000000 для версии 14). Нашли 847 страниц из удалённой таблицы. 🧩
3. Шаг 3. Сборка пазла. Каждая страница имеет номер (block number) и OID таблицы. Мы написали скрипт на Python, который упорядочил страницы по номерам и восстановил таблицу целиком. В ней оказались все данные по зарплатам, включая премии администратора. 🎯
4. Шаг 4. Анализ журнала WAL. В WAL-журналах (pg_wal) нашли запись о DROP TABLE, выполненном в 02:35 ночи. Время совпало со входом администратора по SSH (логин сохранён в /var/log/auth.log). Команда: «psql -c «DROP TABLE salary_dec;»».

Вывод. Администратор удалил таблицу сознательно. На основе восстановленных данных суд взыскал с него 1.2 млн рублей невыплаченных премий (которые он хотел скрыть). Уголовное дело прекращено за примирением сторон, но факт установлен.

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

Глава 4. Инструментарий инженера: как читать страницы данных без SQL

Давайте углубимся в технические детали. Это не для слабонервных, но именно здесь скрывается наша сила. 🔬

Структура страницы данных (на примере MS SQL Server).

• Размер страницы: 8 КБ (8192 байт).
• Заголовок: 96 байт (содержит номер страницы, номер экстента, уровень иерархии, минимальную длину записи).
• Массив смещений (offset array): 2 байта на запись, указывает, где в странице лежит каждая строка.
• Область данных: сами строки (записи) в формате, который зависит от схемы таблицы.
• Слот для версионирования (для строк с длиной > 8000 байт — отдельные страницы LOB).

Что мы извлекаем, читая страницу напрямую:

• Все строки, включая помеченные на удаление (но ещё не физически удалённые).
• Временные метки изменения строки (в системном столбце %%lockres%% в SQL Server или xmin/xmax в PostgreSQL).
• Фрагменты строк, которые повреждены или были частично перезаписаны.

Пример кода (упрощённо) на Python для чтения страницы из файла.mdf:

python

def read_page(file, page_number):    file.seek(page_number * 8192)    page = file.read(8192)    header = page[0:96]    slot_count = int.from_bytes(header[0x48:0x4A], ‘little’)    # парсим массив смещений и извлекаем строки   …

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

Глава 5. Анализ журналов транзакций: инженерная хронология событий

Журнал транзакций — это сердце любой СУБД. И именно сюда мы смотрим в первую очередь. ❤️

Что содержит журнал транзакций (WAL, LDF, Redo Log):

• Тип операции (LOP_BEGIN_XACT, LOP_INSERT_ROWS, LOP_MODIFY_ROW, LOP_DELETE_ROWS, LOP_COMMIT_XACT).
• Идентификатор транзакции (XID, LSN, SCN).
• Идентификатор сессии (SPID, PID).
• Образы данных до и после изменения (особенно при операциях UPDATE).
• Временную метку (обычно в формате FILETIME для MS SQL, или epoch для PostgreSQL).

Как мы анализируем журналы:

1. Извлечение сырых записей.Парсим бинарный файл журнала, ищем сигнатуры начала операций.
2. Декодирование.Преобразуем бинарные данные в читаемый вид. Например, для LOP_INSERT_ROWS восстанавливаем вставленную строку.
3. Построение временной линии.Группируем операции по транзакциям, восстанавливаем последовательность.
4. Корреляция с внешними источниками.Сравниваем время операций с логами ОС, сетевыми логами, журналами событий Windows (Security Event Log).

Важно: даже если СУБД работает в режиме простого восстановления (simple recovery model) и журнал зацикливается, некоторые записи остаются в файле до того, как будут перезаписаны. Мы используем методы «заморозки» копии журнала сразу после изъятия. ❄️

Глава 6. Кейс №2: Махинации с онлайн-кассами через подмену хранимых процедур

💸 Федеральная сеть розничной торговли. Налоговая выявила расхождение: фискальные накопители (ФН) показывают одну сумму, а внутренняя учётная система — другую. Разница — 34 млн рублей неуплаченного НДС за 6 месяцев. Руководство клянётся, что ошибка в интеграции. Но налоговая подозревает умысел.

Что мы сделали. Получили образ диска сервера 1С (MS SQL Server). Начали анализ.

Шаг 1. Исследование хранимых процедур. В базе 1С есть типовые процедуры для проведения чеков. Мы сравнили их с эталонными (взяли из официальной поставки 1С). Обнаружили модификацию: в процедуру «Документ.Чек.Провести» был добавлен код, который при сумме чека > 10000 рублей заменял последнюю цифру суммы на 0. Например, 15 678 → 15 670. Разница уходила в скрытую таблицу «tmp_kassa_shadow». 🩻

Шаг 2. Анализ журнала транзакций (LDF). Нашли записи о модификации процедуры. Транзакция была выполнена под учётной записью «sysadmin» с IP-адреса 10.0.0.47. Логи межсетевого экрана показали, что в это время с этого IP работал внешний подрядчик — интегратор кассового ПО.

Шаг 3. Анализ скрытой таблицы. Таблица «tmp_kassa_shadow» не была видна в интерфейсе 1С. Мы прочитали её напрямую через SELECT (она была обычной таблицей). Там хранились все суммы, которые были «срезаны» с чеков за полгода. Всего — 34 млн рублей. Карта срезанных сумм совпадала с расхождениями налоговой. 📊

Вывод. Подрядчик умышленно модифицировал процедуру для сокрытия выручки. Деньги выводились через фиктивные акты выполненных работ. Уголовное дело по ст. 199 УК РФ (уклонение от уплаты налогов). Подрядчик и главный бухгалтер арестованы.

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

Глава 7. Работа с фрагментированными и повреждёнными базами данных

Реальный мир не идеален. Серверы падают, диски «сыпятся», файлы повреждаются. Но даже в этих условиях мы продолжаем исследование. 🩹

Типы повреждений:

1. Повреждение заголовка страницы.СУБД не может прочитать страницу и выдаёт ошибку 824 (MS SQL) или «invalid page header». Мы обходим это, анализируя страницу вручную: заголовок можно восстановить из соседних страниц или из журналов.
2. Разрыв цепочки страниц (для таблиц с BLOB/LOB).Если указатель на следующую страницу LOB-данных повреждён — мы сканируем весь файл в поисках продолжения по сигнатуре.
3. Удаление файлов журналов.Если преступник удалил LDF-файлы, но ещё не перезаписал их физически — мы восстанавливаем их с помощью программной реконструкции (UFS Explorer, R-Studio).
4. Форматирование диска.Применяем методы low-level восстановления сигнатур (как в кейсе №1).

Важное предупреждение: Никогда не запускайте DBCC CHECKDB (для MS SQL) или VACUUM (для PostgreSQL) на потенциально повреждённой базе, если она является уликой. Эти команды могут перестроить страницы и уничтожить «мёртвые» записи. Сначала — создание образа, потом — исследование на копии. 🚫

Глава 8. Инженерная методика определения временных подделок (timestamp tampering)

Один из самых частых видов фальсификации — изменение системного времени сервера перед выполнением операции, чтобы создать «алиби» или, наоборот, «состарить» запись. Мы умеем это выявлять с точностью до 99.9%. ⏰

Метод 1. Анализ LSN/SCN. Как уже упоминалось, в большинстве СУБД есть монотонные счётчики изменений, не зависящие от часов. Например, в MS SQL это LSN (Log Sequence Number). LSN всегда возрастает. Если временная метка записи (CreatedDate) вдруг оказалась раньше, чем у записи с бОльшим LSN — это признак подделки.

Метод 2. Корреляция с внешними событиями. Любая запись в БД обычно коррелирует с другими событиями: записью в журнале доступа, логе веб-сервера, записью в системном журнале. Мы строим мульти-временную шкалу и ищем аномалии.

Метод 3. Анализ микроструктуры страницы. Внутри страницы данных есть поле «last_update_time» (название зависит от СУБД). Оно обновляется при любом изменении строки. Если это поле не соответствует заявленному времени изменения — налицо подделка.

Метод 4. Физический анализ файловой системы. Время создания/изменения файла БД в ОС (ctime, mtime) часто отличается от времени, записанного внутри СУБД. Если разница превышает допустимый джиттер (обычно 1-2 секунды) — мы фиксируем аномалию. 🧐

Пример из практики: в одном деле ответчик утверждал, что подписал договор 1 марта. В БД стояла дата 01.03.2024. Но мы обнаружили, что файл.mdf был изменён 15.03.2024 (по mtime), а LSN записи шёл после многих других транзакций, датированных 10 марта. Суд признал договор сфальсифицированным.

Глава 9. Работа с зашифрованными базами данных (TDE, BitLocker, VeraCrypt)

Шифрование — это вызов, но не приговор. 🔐

TDE (Transparent Data Encryption) в MS SQL и Oracle. Ключ шифрования хранится в базе данных master (для MS SQL) и защищён сертификатом сервера. Если у нас есть образ master и сертификат, мы можем расшифровать всё. Если сертификат утерян — пытаемся восстановить пароль к нему (брутфорс). В 20% случаев пароль слабый.

BitLocker. Если сервер изъят в работающем состоянии, ключ BitLocker часто лежит в TPM (Trusted Platform Module) или сохранён в активной сессии. Мы делаем дамп памяти и извлекаем ключ. Если сервер выключен — пытаемся восстановить ключ с recovery-ключа, который иногда хранится в AD или на распечатке.

VeraCrypt (популярен у особо осторожных преступников). Здесь сложнее. Если нет пароля — шансы минимальны. Но мы изучаем образ диска на предмет наличия открытых версий файлов в свопе, hiberfil.sys, теневых копиях.

Важно: любое вмешательство в зашифрованную систему должно быть процессуально оформлено. Мы не «ломаем» защиту без постановления суда. Но в рамках назначенной экспертизы — да, мы имеем право. ⚖️

Глава 10. Кейс №3: Инсайдерская атака через прямое редактирование.ibd-файлов (MySQL)

📉 Финансовый стартап. В базе MySQL (InnoDB) внезапно у нескольких крупных инвесторов обнулились балансы. Технический директор утверждает: «взлом». Но следов SQL-атак нет. Назначена наша экспертиза.

Шаг 1. Осмотр файлов.ibd. Каждой таблице InnoDB соответствует файл.ibd в каталоге базы данных. Мы сравнили контрольные суммы этих файлов с эталонными (взятыми из бэкапа недельной давности). Три файла отличались.

Шаг 2. Сравнение страниц данных. Мы разобрали.ibd-файлы на страницы (16 КБ каждая). Обнаружили, что в некоторых страницах заголовок страницы повреждён — он не соответствует формату InnoDB. Это следствие того, что файл редактировался в hex-редакторе без знания внутренней структуры. 🧬

Шаг 3. Восстановление original data. Несмотря на повреждения, нам удалось извлечь соседние страницы с корректными данными инвесторов. Стало очевидно: злоумышленник не удалял данные, а заменил значения balance на 0 вручную в шестнадцатеричном редакторе (HxD), но забыл обновить контрольные суммы страниц.

Шаг 4. Отслеживание доступа к файлам. Журналы аудита файловой системы (удалось восстановить из теневых копий Volume Shadow Copy) показали, что к.ibd-файлам обращался процесс «notepad.exe» из-под учётной записи технического директора. Notepad не может открыть бинарный файл такого размера без зависания — значит, использовался плагин или другой редактор. Но сам факт доступа — уже улика.

Вывод. Технический директор сознательно испортил файлы.ibd, чтобы обнулить балансы инвесторов (причина — личная обида). Дело передано в суд. Потерпевшие инвесторы получили возмещение из резервного фонда.

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

Глава 11. Почему инженерный подход эффективнее «стандартных методик»?

Госэксперты работают по методикам, которые не менялись годами. А мы каждый раз разрабатываем уникальную процедуру исследования. 🧠

Преимущества инженерного подхода:

1. Адаптивность.Под каждую версию СУБД, под каждую файловую систему мы подбираем или пишем уникальный набор инструментов. Нет «одного размера для всех».
2. Глубина.Мы не останавливаемся на уровне «запрос выполнен». Мы идём до байта, до сектора, до бита. Потому что истина может скрываться в младшем бите флага deleted.
3. Воспроизводимость.Любой наш вывод может быть проверен независимым инженером. Мы не используем «закрытые» алгоритмы. Всё открыто, опубликовано, задокументировано.
4. Проактивность.Мы не ждём, пока появится методика от Минюста. Мы сами создаём эти методики и публикуем их, чтобы другие эксперты могли их применять. Это наш вклад в развитие судебной IT-экспертизы. 📚

Глава 12. Типичные ошибки при заказе экспертизы и как их избежать

Я часто вижу, как юристы и следователи совершают одни и те же ошибки. Вот список — на будущее. 📝

Ошибка 1. Заказ экспертизы у «универсала». Эксперт, который обещает «и ДНК проверить, и базу данных проанализировать», на самом деле не умеет ничего. Настоящая экспертиза БД требует узкой специализации.

Ошибка 2. Экономия на копировании. «Мы сами сделаем образ диска, сэкономите на выезде». Результат: образ сделан с ошибками (включённый сервер, не тот тип клонирования). Судья отказывается его принимать. Дело проиграно.

Ошибка 3. Неполный перечень вопросов. Поставили один вопрос: «Были ли изменения?». Эксперт ответил: «Да». А кто, когда, откуда — неизвестно. Суд назначает дополнительную экспертизу, теряется время, деньги, улики могут быть уничтожены. Ставьте сразу 5-6 конкретных вопросов.

Ошибка 4. Выбор эксперта по самому дешёвому предложению. Качественная экспертиза БД стоит от 200 000 рублей. За 50 000 рублей вам сделают «галочку» — формальный осмотр без низкоуровневого анализа. Выиграть с таким заключением невозможно.

Глава 13. Процессуальные аспекты: как подготовить постановление о назначении экспертизы

Мы помогаем сторонам формулировать вопросы. Вот пример хорошо составленного постановления для арбитражного суда. 📄

Вопросы эксперту:

1. Имеются ли в журналах транзакций СУБД (указать тип и версию) сведения об изменениях таблицы «Договоры» за период с 01.01.2024 по 01.03.2024? Если да, то какие именно строки были изменены, указать их содержание до и после изменения.
2. Каковы временные метки (с точностью до миллисекунды) и номера транзакций (LSN/SCN) для каждого выявленного изменения?
3. С каких IP-адресов и с использованием каких учётных записей СУБД были выполнены эти изменения?
4. Имеются ли в системных таблицах или файловой системе следы подмены системного времени сервера в момент выполнения изменений?
5. Соответствует ли структура страниц данных (файлов.mdf/.ibd) эталонному состоянию, либо выявлены признаки прямого редактирования на уровне байтов в обход SQL?

Чего не нужно писать: «Провести исследование всех возможных нарушений». Слишком широко — эксперт может сделать что угодно. Будьте конкретны.

Глава 14. Сравнение экспертных подходов: Российская школа vs Международная практика

Мы изучаем зарубежный опыт (США, Германия, Израиль) и адаптируем его к российскому процессуальному праву. 🇺🇸🇩🇪🇮🇱

Общее:

• Везде приоритет — работа с образом, а не с оригиналом.
• Везде используются write-blocker и криминалистические копировщики.
• Везде важен анализ LSN/SCN для реконструкции хронологии.

Различия:

• В США допустимы «экспертные утилиты с закрытым кодом» (например, Axiom). В России мы предпочитаем open-source или собственные разработки — для прозрачности.
• В Германии экспертизу БД часто проводят совместно с разработчиком СУБД (например, приглашают инженера Oracle). В России это редкость, но мы тоже практикуем, когда нужно.
• В Израиле активно используют машинное обучение для выявления аномалий в больших БД. Мы внедряем аналогичные методы.

Наша школа — синтез лучших мировых практик и российской процессуальной строгости. 🌍

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

Мы с вами рассмотрели 14 глав. Кейсы, методы, инструменты, ошибки. Осталось подвести итог. 🎯

Ключевая мысль: Базы данных — это не просто программное обеспечение. Это цифровые свидетельства, которые могут быть прочитаны только квалифицированным инженером-экспертом. Без компьютерная экспертиза баз данных и СУБД (пятое и финальное упоминание) многие преступления остались бы нераскрытыми, а невиновные — осуждёнными.

Что мы предлагаем (Союз «Федерация судебных экспертов»):

• ✅ Экспертиза любого уровня сложности (от MySQL на Arduino до Oracle RAC на Exadata).
• ✅ Выезд на место изъятия в любой регион РФ (выездная группа с оборудованием).
• ✅ Подготовка вопросов и процессуальных документов.
• ✅ Защита заключения в суде (эксперт приезжает на заседание, отвечает на вопросы).
• ✅ Анонимность и NDA для коммерческих споров.

Сколько это стоит: Стоимость рассчитывается индивидуально. Формула: (объём БД в ГБ × коэффициент сложности) + стоимость выезда. В среднем — от 250 000 до 2 млн рублей. Но поверьте, это дешевле, чем проиграть дело с многомиллионным иском. 💰

Как заказать: Перейдите на наш сайт — https://kriminalist77.ru/ekspertiza-baz-dannyh/. Заполните форму или позвоните по телефону. Мы ответим на все ваши вопросы, дадим предварительную оценку стоимости и сроков. Бесплатная консультация — 30 минут.

Не позволяйте цифровой лжи вводить суд в заблуждение. Инженерная правда всегда на нашей стороне. 🔧⚖️