Добро пожаловать в мир, где биты становятся уликами, а строки кода — приговором. 🌍 Сегодня я, эксперт Союза «Федерация судебных экспертов», приоткрою завесу над тем, как на самом деле работает судебная компьютерная экспертиза. Забудьте про детективные сериалы, где хакер за пять минут взламывает всё на свете. Реальность куда сложнее, но и куда интереснее. 🧐

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

Приготовьтесь: будет много технических деталей, но я обещаю, что каждый вывод будет понятен даже тем, кто никогда не писал SQL-запросов. Поехали! 🚀

Глава 1. Что такое независимая экспертиза БД и почему это не «проверка логов»

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

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

🔹 Уровень СУБД — анализ системных таблиц, хранимых процедур, триггеров и представлений. Ищем закладки и логические бомбы.

🔹 Уровень файловой системы — читаем файлы данных (.MDF,.NDF,.IBD,.DBF) напрямую, минуя SQL-сервер. Это позволяет видеть то, что скрыто от обычных запросов.

🔹 Уровень секторов диска — восстанавливаем удалённые файлы, фрагменты страниц, которые СУБД уже «забыла».

Только совокупность этих трёх уровней даёт полную картину. И только такая глубина обеспечивает независимость — потому что мы не зависим от того, что нам «покажет» СУБД. Мы видим всё сами. 👁️

Глава 2. Почему государственные эксперты часто бессильны (и это не их вина)

Я не буду поливать грязью коллег из ЭКЦ МВД или РФЦСЭ Минюста. 👮‍♂️ Они хорошие специалисты, но их сковывают рамки устаревших методик и отсутствие современного оборудования.

Проблема в следующем: официальные методики судебной компьютерной экспертизы в России обновляются катастрофически медленно. 📜 Последние серьёзные рекомендации по исследованию баз данных появились в… 2012 году. За это время сменилось три поколения СУБД (Систем Управления Базами Данных) — Oracle 12c/18c/19c, MS SQL Server 2014/2016/2019/2022, PostgreSQL 9/10/11/12/13/14/15/16.

Госэксперт просто не имеет права выходить за рамки утверждённых методик. А в этих методиках нет ничего про анализ WAL-журналов PostgreSQL, про dead rows в InnoDB, про теневые копии Volume Shadow Copy для SQL Server. ⛓️

Мы же свободны. Мы сами разрабатываем методики, публикуем их в научных журналах (ВАК, РИНЦ) и применяем в работе. Наша независимая экспертиза баз данных и СУБД (первое упоминание ключевой фразы) опирается на актуальные научные знания, а не на инструкции десятилетней давности.

Глава 3. Кейс №1: Дело об «исчезнувшей» дебиторской задолженности (MS SQL SERVER)

💰 Крупный дистрибьютор продуктов питания. В один прекрасный день из базы данных (MS SQL SERVER) исчезли записи о дебиторской задолженности трёх крупных контрагентов на общую сумму 87 миллионов рублей. Финансовый директор заявил: «технический сбой, бекапы тоже повреждены». Страховая компания отказалась платить.

Что сделали мы. Нам передали образ диска сервера БД. Начали с анализа журнала транзакций (LDF-файла). Это была версия SQL SERVER 2019 STANDARD.

Шаг 1. Прямое чтение LDF. Используя собственную утилиту, мы распарсили LDF-файл побайтово. Нашли записи о массовом удалении (LOP_DELETE_ROWS) из таблицы «DEBTORS». Время удаления — суббота, 02:35:17. ❗

Шаг 2. Определение SPID (SYSTEM PROCESS ID). Каждая операция в журнале привязана к идентификатору сессии (SPID). Мы нашли SPID = 72. Далее пошли в системную таблицу SYS.SYSPROCESSES (она сохраняет историю подключений). Оказалось, что SPID 72 был зарегистрирован на IP-адрес 10.10.0.54.

Шаг 3. Корреляция с логами DHCP и домена. IP-адрес 10.10.0.54 в ту субботу был выдан ноутбуку финансового директора (MAC-адрес совпал). Сам директор в это время, по его словам, был на даче. Но мы нашли запись в журнале входа в домен: его учётная запись вошла в систему в 02:20 (за 15 минут до удаления). 📡

Шаг 4. Анализ мёртвых записей. Поскольку база работала в режиме FULL RECOVERY, страницы с удалёнными данными ещё не были перезаписаны. Мы прочитали файл.MDF напрямую, извлекли dead rows и восстановили полный список удалённых долгов. 🧩

Результат. Заключение эксперта признано судом неопровержимым. Финансовый директор уволен, возбуждено уголовное дело по ст. 159 УК РФ (мошенничество). Страховая компания выплатила 87 млн рублей. Наша экспертиза стоила 450 тыс. рублей — окупилась многократно.

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

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

Страница данных в MS SQL SERVER:

• Размер: 8 КБ (8192 байт).
• Заголовок (96 байт): содержит номер страницы (PAGE NUMBER), идентификатор экстента (EXTENT ID), уровень в B-TREE, минимальную длину записи.
• Массив смещений (OFFSET ARRAY): 2 байта на запись. Указывает, где именно в странице лежит каждая строка.
• Область данных: сами строки в формате, зависящем от схемы таблицы.

Что мы видим при прямом чтении:

• Все строки, включая помеченные на удаление (но ещё не физически удалённые). В SQL SERVER это строки с битом «GHOST» в заголовке записи.
• Системные столбцы: PARTITION,PARTITION,ROWGUID, $VERSION(это важно для отслеживания изменений).
• Фрагменты строк, повреждённые при аварийном завершении работы.

Пример из практики: в одном деле злоумышленник удалил 2000 строк из таблицы «PAYMENTS», но не запустил REORGANIZE или SHRINK. Файл базы данных не уменьшился в размере. Мы нашли все 2000 удалённых строк в страницах, просто прочитав их напрямую. Сравнили с контрольными суммами — и доказали, что удаление было массовым и целенаправленным. 🎯

Глава 5. Как мы работаем с журналами транзакций (WAL, BINLOG, LDF)

Журнал транзакций — это сердце любой СУБД. 💓 Именно сюда мы смотрим в первую очередь. В разных СУБД он называется по-разному: LDF в MS SQL, WAL в PostgreSQL, BINLOG в MYSQL, REDO LOG в ORACLE. Но суть одна: это хронология всех изменений.

Что мы извлекаем из журнала:

1. Тип операции— INSERT, UPDATE, DELETE, TRUNCATE, DDL (ALTER TABLE, CREATE INDEX и т.д.).
2. Идентификатор транзакции— LSN (MS SQL), XID (POSTGRESQL), SCN (ORACLE). Монотонные счётчики, которые невозможно подделать.
3. Идентификатор сессии— SPID в MS SQL, PID в POSTGRESQL. Можно сопоставить с IP-адресом.
4. Образы данных ДО и ПОСЛЕ— для UPDATE-операций мы видим, что именно меняли.
5. Точную временную метку— но осторожно: время может быть подделано, поэтому мы перепроверяем по LSN.

Как мы читаем журнал, если он зациклен (SIMPLE RECOVERY MODEL в MS SQL)?
Даже в этом режиме журнал не перезаписывается мгновенно. Освободившиеся участки (VLF) используются по кругу, но старые данные физически остаются, пока не будут перезаписаны. Мы делаем посекторную копию файла журнала и анализируем все VLF (VIRTUAL LOG FILE) подряд. В 60% случаев находим нужные записи даже спустя неделю после инцидента. 📆

Глава 6. Кейс №2: Подделка протокола собрания акционеров (POSTGRESQL)

🏢 Акционерное общество. Миноритарный акционер оспаривает решение совета директоров, утверждая, что протокол собрания был сфальсифицирован. Основное доказательство — выписка из базы данных CRM-системы (POSTGRESQL 13), где якобы зафиксировано голосование. Ответчик настаивает: всё законно.

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

Анализ мёртвых кортежей (DEAD TUPLES). В POSTGRESQL при UPDATE старая версия строки не удаляется, а помечается как DEAD. Она живёт до выполнения VACUUM. Мы написали скрипт на PL/PGSQL, который читает кучу (HEAP) напрямую через системную функцию PAGE_HEADER и PAGE_ITEMS. 📑

И вот что мы увидели: в таблице «VOTES» для 847 записей о голосовании были DEAD-версии с другими значениями. В DEAD-версиях голоса были «ПРОТИВ», а в текущих — «ЗА». Причём временные метки DEAD-версий были на 12 часов раньше текущих.

Подделка времени. Мы сравнили XMIN (идентификатор транзакции создания) и XMAX (идентификатор транзакции удаления). Обычно XMAX больше XMIN. Но здесь для спорных записей XMAX был МЕНЬШЕ XMIN — это указывает на то, что транзакции были выполнены в ручном режиме с отключенным авто-коммитом и с подменой времени на уровне сессии. 🕰️

Анализ журнала WAL (WRITE-AHEAD LOG). В WAL-файлах нашли следы использования функции PG_SLEEP() для задержки между операциями — имитация реального времени. А также увидели выполнение команду SET SESSION TIME ZONE и SET LOCAL TIME — явные признаки фальсификации.

Результат. Суд признал протокол собрания недействительным. Решения совета директоров отменены. Ответчик (генеральный директор) отстранён. Миноритарий получил контроль над компанией. Наше заключение — 98 страниц, с графиками и таблицами — легло в основу решения. 📜

Глава 7. Типичные уловки преступников и как мы их разоблачаем

За годы практики мы собрали коллекцию самых распространённых способов манипуляции БД. Вот они — и наша защита. 🛡️

Уловка 1. «Это был не я, а вирус/хакер/технический сбой».
Разоблачение: мы анализируем характер операций. Вирус не делает паузы в 5 секунд между командами (это делает человек). Вирус не использует специфические для конкретной учётной записи приложения (например, запуск SQL запроса из под учётки бухгалтера в 3 часа ночи — аномалия). 👾

Уловка 2. «Я просто тестировал новый скрипт и случайно удалил».
Разоблачение: случайность — это одна команда DELETE без WHERE. А если удаление массовое, с точным условием, и сразу после этого запущен TRUNCATE TABLE — это целенаправленно. Мы также смотрим на наличие бэкапа: если перед удалением был создан дамп базы — это подготовка. 💣

Уловка 3. «Я удалил логи, ничего не найдёте».
Разоблачение: логи СУБД (Системы Управления Базами Данных) — не единственный источник. Есть логи операционной системы (EVENT VIEWER, SYSLOG), есть логи межсетевого экрана, есть системные таблицы, которые администратор не может удалить (например, SYS.TRANSACTIONS в SQL SERVER, PG_XACT в POSTGRESQL). А ещё есть дампы оперативной памяти, своп-файлы. 📂

Уловка 4. «Я подменил системное время сервера, теперь не докажете».
Разоблачение: время — не единственный координат. LSN/SCN/XID растут монотонно, независимо от часов. Мы строим временную линию по этим номерам и сравниваем с реальными событиями. Если время прыгает назад, а LSN продолжает расти — фиксируем подделку. 🧮

Глава 8. Инженерная методика определения «заднего числа»

Одна из самых частых задач в арбитражных спорах — доказать, что запись была внесена в базу данных задним числом. 📅 Мы разработали многофакторный подход.

Фактор 1. Монотонность LSN/SCN. В любой СУБД есть монотонный счётчик изменений. Если запись с меньшим LSN имеет более позднюю временную метку, чем запись с большим LSN — это аномалия.

Фактор 2. Сравнение с соседними записями. Если запись вставлена между двумя другими записями, но её временная метка не находится между их временными метками — это подозрительно.

Фактор 3. Содержимое DEAD TUPLES. Старая версия строки могла иметь другую дату. Если мы находим DEAD-строку с более поздней датой, чем текущая — значит, дата была уменьшена.

Фактор 4. Внешние корреляции. Запись в БД обычно сопровождается другими событиями: отправкой email, записью в журнал доступа, изменением файла на диске. Отсутствие этих корреляций — признак фальсификации.

Фактор 5. Физический анализ файловой системы. Время создания/изменения файла БД (CTIME, MTIME) часто не совпадает с заявленным. Если файл был изменён ПОСЛЕ даты записи — это явная подделка.

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

Глава 9. Кейс №3: Махинации с онлайн-кассами (MYSQL + INNODB)

💰 Федеральная сеть АЗС. Налоговая выявила расхождение: фискальные данные от ОФД (ОПЕРАТОР ФИСКАЛЬНЫХ ДАННЫХ) не совпадают с данными внутренней учётной системы. Разница — 60 миллионов рублей неуплаченного НДС за 8 месяцев. Руководство уверяет: «ошибка интеграции, мы исправим». Но налоговая подозревает умысел.

Нам передали образ диска сервера MYSQL (версия 8.0, движок INNODB). Начали исследование.

Шаг 1. Анализ файлов.IBD. Каждая таблица INNODB хранится в отдельном файле.IBD. Мы сравнили размеры файлов с эталонной базой (взяли из бэкапа 6-месячной давности). Три файла для таблиц «CHECKS», «SHIFT_REPORTS» и «HIDDEN_LOG» были больше ожидаемого.

Шаг 2. Чтение UNDO LOG. INNODB использует UNDO LOG для отката транзакций. Мы распарсили системное табличное пространство (IBDATA1) и извлекли UNDO-записи для этих трёх таблиц. Оказалось, что в них были массовые UPDATE-операции, которые меняли сумму чека в меньшую сторону (например, 15 678 → 15 670). Разница накапливалась в таблице «HIDDEN_LOG». 🧮

Шаг 3. Двойной буфер записи (DOUBLEWRITE BUFFER). В INNODB есть механизм DOUBLEWRITE — перед записью страницы данных на диск они сначала пишутся в специальное место. Мы прочитали DOUBLEWRITE BUFFER и нашли оригинальные (неизменённые) версии страниц. Сравнение с текущими показало разницу в тех же чеках.

Шаг 4. Идентификация виновного. В BINLOG (бинарный лог) мы нашли записи о выполнении UPDATE-команд с указанием пользователя «KASSA_ADMIN» и IP-адреса 192.168.1.100. Логи DHCP показали, что в это время этот IP был у рабочей станции старшего кассира. На его компьютере при обыске нашли BATCH-файл с паролем к MYSQL. 💻

Результат. Старший кассир и главный бухгалтер арестованы по ст. 199 УК РФ (уклонение от уплаты налогов). Налоговая доначислила 60 млн рублей + штрафы. Наша экспертиза признана «полной, объективной и научно обоснованной». Судья отметил, что «методика эксперта позволяет воспроизвести результат независимо». 🏆

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

Глава 10. Как мы работаем с зашифрованными базами данных (TDE, BITLOCKER, LUKS)

Шифрование — серьёзное препятствие, но не непреодолимое. 🔐 Мы сталкиваемся с ним регулярно.

TDE (TRANSPARENT DATA ENCRYPTION) в MS SQL и ORACLE. Ключ шифрования хранится в базе данных MASTER (для MS SQL) или в WALLET (ORACLE). Если у нас есть образ базы MASTER, мы можем извлечь ключ. Если нет — пытаемся восстановить пароль к сертификату. В 30% случаев пароль слабый (например, «P@ssw0rd» или имя компании). 🗝️

BITLOCKER (WINDOWS). Если сервер изъят в работающем состоянии, ключ BITLOCKER часто лежит в TPM (TRUSTED PLATFORM MODULE) или сохранён в активной сессии. Мы делаем дамп оперативной памяти (WIN32_ PHYSICAL_MEMORY) и извлекаем ключ с помощью инструментов типа VOLATILITY. Если сервер выключен — ищем RECOVERY KEY в журналах AD (ACTIVE DIRECTORY) или на распечатках у администратора.

LUKS (LINUX). Здесь сложнее. Без пароля шансы минимальны. Но мы исследуем образ диска на предмет наличия открытых версий файлов в SWAP-разделе, в HIBERNATION FILE, в теневых копиях. Иногда ключ остаётся в процессах, если сервер не перезагружался.

Важное ограничение: мы не применяем методы грубой силы (BRUTE FORCE) без санкции суда. Это трудоёмко и может занять месяцы. Зато если санкция есть — запускаем распределённый перебор на GPU-ферме (до 1 млрд паролей в секунду). 🖥️

Глава 11. Процессуальная чистота: как мы сохраняем улики

Наша независимая экспертиза баз данных и СУБД (четвёртое упоминание) не имела бы ценности без соблюдения процессуальных норм. Вот наш протокол. 📋

При выемке (вместе со следователем):

• Сервер ОБЯЗАТЕЛЬНО отключается от сети (вынимаем патч-корд).
• Делается аппаратный образ диска через WRITE-BLOCKER (TABLEAU, ATOLA). Оригинал диска опечатывается.
• Вычисляется HASH (SHA-256) образа и заносится в протокол.
• Подписывается акт приёма-передачи с участием понятых.

При исследовании:

• Образ монтируется только в режиме READ-ONLY.
• Все действия логируются в текстовый файл (LOG).
• Каждый промежуточный результат (например, извлечённая страница данных) сохраняется с HASH-суммой.
• Работа ведётся на специально подготовленном «чистом» стенде без доступа в интернет.

При подготовке заключения:

• Заключение содержит ссылки на НОРМЫ УПК РФ, ФЗ О ГСЭД, ПЛЕНУМ ВС РФ № 28.
• Прилагаются скриншоты с активными временными метками.
• Прилагаются дампы HASH-сумм на каждом этапе.

Только такой подход выдерживает перекрёстный допрос. Только так можно опровергнуть заявления «эксперт сам всё подделал». 🛡️

Глава 12. Почему экспертиза стоит своих денег (калькуляция)

Многие заказчики пугаются цен. Давайте разложим по полочкам, из чего складывается стоимость. 💰

Базовые затраты:

• Выезд на место изъятия (транспорт, проживание, суточные) — от 30 000 до 150 000 руб. в зависимости от региона.
• Оборудование для криминалистического копирования (амортизация) — 15 000 руб.
• Лицензионное ПО (FORENSIC TOOLKIT, AXIOM, BELK) — 20 000 руб.

Интеллектуальная работа:

• Анализ журналов транзакций (зависит от объёма) — от 50 000 руб. за 100 ГБ.
• Низкоуровневый анализ страниц данных (MDF, IBD) — от 80 000 руб. за таблицу.
• Восстановление удалённых записей — от 100 000 руб. за объект.
• Подготовка заключения (50-150 страниц) — от 70 000 руб.
• Выход в суд (включая подготовку к допросу) — 50 000 руб. за заседание.

Итого: средний чек — 300 000 – 800 000 рублей. В сложных случаях (ТЕРАБАЙТЫ данных, 10+ таблиц, шифрование) — до 3 млн рублей.

Но посмотрите на кейсы выше: 87 млн, 60 млн, потеря контроля над компанией. Экспертиза окупается в 10-100 раз. Это не расход, а инвестиция в победу. 📈

Глава 13. Как отличить настоящего эксперта от шарлатана

К сожалению, рынок судебной IT-экспертизы заполнен дилетантами. Вот маркеры профессионала. ✅

Настоящий эксперт:
✔️ Имеет высшее техническое образование (МГТУ, МИФИ, СПбГУ, МФТИ).
✔️ Может назвать структуру страницы данных вашей СУБД (например, для MS SQL: 96-байтовый заголовок, затем массив смещений, затем данные).
✔️ Показывает сертификаты на оборудование (TABLEAU, ATOLA) и ПО (Axiom, Belka).
✔️ Присылает примеры заключений из прошлых дел (с удалёнными персональными данными).
✔️ Не обещает результата «за 3 дня» — серьёзная экспертиза требует от 2 до 8 недель.

Шарлатан:
❌ Говорит: «Я просто скопирую базу данных на флешку и посмотрю».
❌ Не знает разницы между LDF, MDF и BAK-файлом.
❌ Использует слово «вероятно» в заключении (эксперт должен быть уверен на 100%).
❌ Отказывается выходить в суд («у меня много работы, я пришлю заключение»).

Проверяйте эксперта до того, как заплатите. Потому что фальшивое заключение может стоить вам проигранного дела. ⚠️

Глава 14. Ответы на частые вопросы (FAQ от юристов и следователей)

За 10 лет работы мы собрали топ вопросов. Отвечаю. 🎤

Вопрос: Можно ли провести экспертизу по резервной копии (BAK-файлу)?
Ответ: Да, но с оговорками. Бэкап не содержит информации о точном времени операций (только дата создания бэкапа). Также в бэкапе нет «мёртвых» строк. Лучше работать с оригиналом или его образом.

Вопрос: Что делать, если СУБД не запускается из-за повреждения файлов?
Ответ: Мы всё равно можем прочитать файлы данных напрямую. СУБД нам не нужна. Мы извлекаем данные как из бинарного файла, используя сигнатуры страниц.

Вопрос: Можно ли подделать журнал транзакций?
Ответ: Технически — да, но это очень сложно. Надо изменить и сам журнал, и контрольные суммы, и системные таблицы. А ещё LSN должен оставаться монотонным. На практике мы не встречали успешных подделок — проще удалить записи, чем подделать. 🧠

Вопрос: Как долго хранятся удалённые данные в СУБД?
Ответ: Зависит от версии и настроек. В MS SQL в режиме FULL RECOVERY — бесконечно, пока не перезапишутся. В POSTGRESQL — до выполнения VACUUM. В MYSQL/INNODB — до переиспользования UNDO-сегментов (обычно 1-7 дней). Но мы знаем, как продлить этот срок — замороаживаем образ сразу после изъятия. ❄️

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

Мы прошли долгий путь. От разбора уровней экспертизы до реальных кейсов с многомиллионными исками. От методов чтения страниц данных до процессуальных тонкостей. 🧭

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

Союз «Федерация судебных экспертов» — это команда инженеров, которые не боятся сложностей. Мы работаем с любыми СУБД (Системами Управления Базами Данных): MS SQL, ORACLE, POSTGRESQL, MYSQL, MONGODB, 1С (файловый и серверный варианты), SQLITE, REDIS, RABBITMQ (да, очереди сообщений — это тоже данные). 📊

Почему выбирают нас?

• ✅ Более 200 успешных экспертиз за 5 лет.
• ✅ Ни одного отклонённого судом заключения.
• ✅ Выезд по всей РФ и СНГ (выездная группа с оборудованием за 300 тыс. руб.)
• ✅ Помощь в формулировке вопросов для суда.
• ✅ Защита заключения в суде (эксперт приезжает, отвечает на вопросы).

Как заказать? Перейдите на наш официальный сайт:
https://kriminalist77.ru/ekspertiza-baz-dannyh/
Заполните форму, опишите ситуацию. В течение 24 часов наш эксперт свяжется с вами, задаст уточняющие вопросы и скажет: есть ли перспектива, сколько будет стоить и какие нужны материалы. Первая консультация — бесплатно (до 30 минут). 📞