Введение: экспертиза как инженерная дисциплина

Судебная компьютерная экспертиза ERP-систем — это не магия и не гадание на логах. Это строгая инженерная дисциплина, опирающаяся на фундаментальные принципы работы вычислительных систем, теории баз данных, криптографического хеширования и цифровой криминалистики. Каждое наше заключение — это инженерная конструкция, где отдельные факты (хеш-суммы, временные метки, sequence-номера) соединяются в неопровержимую цепь доказательств. Союз «Федерация судебных экспертов» более 12 лет проектирует и строит такие конструкции. В этой статье мы разберём инженерную «начинку» экспертиза ERP-систем по запросу суда — от физического уровня битов до логического уровня бизнес-транзакций. Вы узнаете, как мы восстанавливаем удалённое, вычисляем подделку и доказываем истину в цифрах. 🛠️📐⚙️🔬

Глава 1. Физический уровень: от секторов диска до образа-эталона

Любая инженерная работа начинается с фундамента. Для нас фундамент — это точная битовая копия (образ) оригинального носителя данных. 🧱💾

Процесс инженерно строгого копирования:

1️⃣ Подключение носителя через аппаратный write-blocker (например, Tableau T8 или Atola Insight) — устройство, которое физически запрещает запись на диск.
2️⃣ Создание образа в формате E01 (EnCase) или AFF (Advanced Forensic Format) с вычислением MD5, SHA-1 и SHA-256 одновременно.
3️⃣ Запись хеш-сумм в протокол, заверенный подписью эксперта.
4️⃣ Проверка: образ монтируется как read-only, хеш пересчитывается — должно совпасть до последнего бита.

Почему это критично для экспертиза ERP-систем по запросу суда? Потому что любой анализ, выполненный не с образа, а с «живой» базы или просто скопированных файлов, теряет доказательственную силу — данные могли быть изменены в процессе осмотра. Мы этого не допускаем. 🔒🛡️

Глава 2. Логический уровень 1: файловая система как архив улик

После монтирования образа мы исследуем файловую систему (NTFS, ext4, XFS, APFS). Инженерный подход требует ответить на вопросы:

📁 Где находится файл базы данных ERP? (MDF/NDF для MS SQL,.1CD для 1С,.dbf для старых систем, DAT для Oracle).
📁 Каковы его атрибуты STANDARDINFORMATIONиSTANDARDI​NFORMATIONиFILE_NAME? (в NTFS они могут различаться — признак подмены).
📁 Есть ли теневые копии (VSS)? — мы извлекаем предыдущие версии файлов БД.
📁 Что находится в нераспределённых кластерах? — там могут быть фрагменты удалённых LDF-файлов, логов, временных таблиц.

Пример из практики: в одном деле файл 1CD был «чистым», но в нераспределённом пространстве нашлись 230 кластеров с заголовками 1CD — удалённая старая база, в которой хищение было видно как на ладони. 🔍🗂️

Глава 3. Логический уровень 2: СУБД и журналы транзакций

Сердце ERP-системы — это система управления базами данных (СУБД). Каждая операция INSERT, UPDATE, DELETE сначала попадает в журнал транзакций (Transaction Log), и только потом в данные. 🫀📊

Инженерная работа с журналами:

MS SQL: LDF-файл разбирается утилитой fn_dblog или ApexSQL Log. Мы получаем таблицу с полями: [Current LSN], [Operation], [Transaction ID], [Begin Time], [End Time], [Row Content], [User Name].

PostgreSQL: WAL-логи (pg_wal) анализируются через pg_waldump с ключами —rmgr=heap и —relation.

Oracle: LogMiner + представление V$LOGMNR_CONTENTS — видим оригинальные SQL-запросы.

1С: Предприятие: используется технологический журнал со сборкой событий EXCPTN, PROC, DBPOSTGRES (или DBMSSQL).

Мы ищем аномалии: транзакции без привязки к пользовательскому сеансу, UPDATE без предшествующего SELECT (в бизнес-логике так не бывает), массовое удаление записей в нерабочее время. 🕵️‍♂️📜

Глава 4. Сетевой уровень: кто стучится в ERP

ERP-системы работают в сети. Каждое действие пользователя порождает сетевые пакеты. Мы анализируем PCAP-файлы (если они сохранены) или восстанавливаем трафик из дампов оперативной памяти сервера. 🌐📡

Инженерный анализ включает:

IP-адрес и MAC-адрес клиента.

Версию протокола (TDS для MS SQL, Pg для PostgreSQL, HTTP/S для веб-интерфейсов).

Последовательность команд: например, SELECT * FROM склад → UPDATE склад SET остаток=0.

Подозрительные длительные паузы между командами (имитация человеческого ввода или скрипт?).

В одном кейсе с SAP ERP мы обнаружили, что критическое изменение было выполнено через протокол DIAG (SAP GUI) с версией клиента, которая не использовалась в компании уже 3 года. Это позволило вычислить ноутбук злоумышленника. 🖥️🔗

Глава 5. Восстановление удалённых данных: инженерный алгоритм

Данные удалены из ERP-системы? Не проблема. У нас есть чёткий алгоритм восстановления: 🧩🔧

Шаг 1: Поиск по сигнатурам в нераспределённом пространстве. Для 1С — сигнатура 1CD по смещению 0x00. Для SQL — MDF (0x0100444D). Для Oracle — CTL с контрольной суммой.

Шаг 2: Карпалы (carving) — извлечение фрагментов на основе структуры БД. Мы знаем, что страница данных MS SQL имеет размер 8 КБ и начинается с заголовка \x0100.

Шаг 3: Восстановление удалённых строк из журнала транзакций. Даже если строка удалена, в LDF лежит её образ «до удаления».

Шаг 4: Анализ теневых копий томов (VSS) — Windows сохраняет «слепки» файлов каждые несколько часов.

Шаг 5: Извлечение данных из файла подкачки (pagefile.sys) — туда могут попасть фрагменты активных таблиц.

В одном из дел мы восстановили удалённую таблицу СкладскиеОстатки из 1С спустя 4 месяца после её очистки. Ключом стали 3 не перезаписанных кластера на SSD (контроллер SSD не успел выполнить TRIM). 🗄️💪

Глава 6. Кейс №1: Доказательство «заднего числа» в MS SQL ERP

Постановка задачи: Арбитражный суд назначил экспертиза ERP-систем по запросу суда по делу о поставке оборудования. Истец представил накладные из ERP на базе MS SQL, датированные 10 марта. Ответчик утверждал, что документы созданы 25 марта, а дата подделана.

Инженерные действия:
1️⃣ Получили образ диска сервера БД.
2️⃣ Извлекли LDF-файл, проанализировали через fn_dblog.
3️⃣ Нашли записи о создании накладных:

Current LSN = 00000034: 00000190: 0001

Begin Time = 2025-03-25 14: 23: 17.123

Operation = LOP_INSERT_ROWS

Row Content = Накладная №124, сумма 2.3 млн
4️⃣ Сравнили с системной таблицей sysobjects — время создания объектов (триггеров, хранимых процедур) также было 25 марта.
5️⃣ Нашли расхождение: в столбце DocDate пользовательского интерфейса стояло 10 марта, но в LDF InsertTime — 25 марта.

Вывод: Даты в документах были изменены после создания транзакций. Суд признал накладные недействительными. 🗓️❌

Глава 7. Кейс №2: Взлом журнала регистрации 1С через технологический журнал

Ситуация: Хищение в торговой компании. Главный бухгалтер очистил журнал регистрации 1С (кнопка «Очистить»), думая, что следы исчезли. Следователь назначил экспертизу.

Наш инженерный подход:
1️⃣ Включили технологический журнал 1С на сервере (файлы C: \Program Files\1cv8\srvinfo\reg_*).
2️⃣ Даже если журнал регистрации очищен, технологический журнал хранит низкоуровневые события:

EXCPTN — исключения.

PROC — вызовы процедур.

DBPOSTGRES — каждый SQL-запрос к БД.
3️⃣ Нашли записи о запуске внешней обработки Хищение.epf с параметрами обнуления регистров.
4️⃣ Восстановили временные метки из файлов.lgp (журналов сервера 1С).

Результат: Бухгалтер признал вину, когда эксперты показали распечатку технологического журнала с его логином и точным временем. Суд — 3.5 года. 📄🔥

Глава 8. Кейс №3: Oracle ERP и анализ redo-логов для выявления скрипта-копира

Контекст: Налоговый спор. Компания утверждала, что первичные документы были удалены из-за сбоя Oracle. Налоговая заподозрила намеренное уничтожение. Назначена экспертиза ERP-систем по запросу суда.

Инженерные действия:
1️⃣ Подключились к архивированным redo-логам через LogMiner.
2️⃣ Нашли 12 400 операций DELETE из таблицы GL_BALANCES (обороты по счетам).
3️⃣ Анализ показал, что DELETE выполнялись не случайно, а в строгом порядке по period_id (сначала за декабрь, потом за ноябрь и т.д.) — что характерно для скрипта, а не для сбоя.
4️⃣ Восстановили SID (сессионный идентификатор) и program_name: значение было sqlplus@exe (нештатный доступ).
5️⃣ Сетевой анализ (PCAP) показал, что скрипт запускался с IP-адреса, зарегистрированного на физлицо — родственника директора.

Итог: Умышленное уничтожение доказано. Дело передано в прокуратуру. 💰⚙️📉

Глава 9. Временные метки: инженерный анализ трёх уровней

Временные метки в ERP-системах — это слоёный пирог. 🍰⏱️

Уровень 1 — ОС файла: три временные метки NTFS (Creation, Last Write, Last Access). Могут быть изменены через SetFileTime или touch.

Уровень 2 — СУБД: timestamp в строке таблицы (например, rowversion в MS SQL) — меняется автоматически при каждом изменении строки. Не подделать!

Уровень 3 — транзакционный журнал: LSN и Begin Time — абсолютно точны, так как создаются движком СУБД до любого пользовательского кода.

Инженерный вывод: Если Last Write файла БД = 10 марта, rowversion в строке = 0x000000001234, а Begin Time в LSN = 25 марта — значит, изменения вносились 25 марта, а дата файла подделана. Мы используем такие коллизии в 100% дел о «заднем числе». 🕵️‍♂️📆

Глава 10. Анализ хранимых процедур и триггеров

Злоумышленники часто внедряют вредоносный код прямо в хранимые процедуры или триггеры СУБД. Инженерный анализ включает: 🧬📜

Декомпиляция хранимых процедур (для MS SQL: sp_helptext, для Oracle: DBA_SOURCE).

Поиск скрытых условий — например, IF (USER=’badguy’) THEN DELETE FROM logs.

Сравнение хешей текущей процедуры с эталоном из резервной копии.

Анализ зависимостей — какие триггеры срабатывают на INSERT/UPDATE/DELETE.

В одном деле мы нашли триггер trg_hide_deletion в Oracle, который при удалении записей из таблицы shipments автоматически добавлял фиктивные строки в журнал аудита, имитируя нормальную работу. Триггер был написан бывшим администратором БД. Его хеш не совпал с бэкапом годичной давности — подлог вскрылся. 🧨

Глава 11. Восстановление паролей и ключей шифрования

Иногда доступ к ERP-системе защищён паролем, а злоумышленник его сменил или зашифровал критичные таблицы. Мы используем: 🔐🔓

Атака по словарю с GPU-ускорителями (8 x RTX 4090, скорость 300 млрд хешей/сек для NTLM).

Атака «радужными таблицами» для LM-хешей (устаревшие системы).

Извлечение ключей из дампа памяти (метод холодной перезагрузки для шифрования BitLocker на лету).

Брутфорс паролей к файлам БД (например, к.1CD-файлам 1С через подбор параметров соединения).

В одном из дел владелец ERP забыл пароль от сервера, а на диске была критичная информация о сделках. Мы восстановили пароль за 4 дня с помощью маски Admin???? и GPU-фермы. Клиент (уже после суда) назвал нас «инженерами-сапёрами». 💣

Глава 12. Противодействие анти-экспертным методам: как нас пытаются обмануть

Злоумышленники изучают наши методы и ставят ловушки. Вот реальные приёмы противодействия: 🧙‍♂️🚫

Перезапись логов — запускают скрипт, который циклически заполняет LDF мусором. Решение: анализ скорости перезаписи и восстановление через теневые копии.

Подмена системного времени — меняют часы на сервере перед операцией, а потом возвращают. Решение: смотрим на sequence-номера транзакций (LSN) — они не зависят от времени.

Шифрование удалённых данных — перед удалением перезаписывают кластеры случайными байтами. Решение: анализ служебной области SSD (запись в NAND-чипы не всегда перезаписывается из-за wear-leveling).

Использование RAM-дисков — временные таблицы хранятся в памяти и исчезают при выключении. Решение: дамп RAM до выключения сервера (аппаратный метод Intel TXT).

Мы постоянно совершенствуем инженерные методы. Каждое дело — это вызов, на который мы отвечаем новыми алгоритмами. 🧠⚡

Глава 13. Метрологическое обеспечение: проверка средств измерения

Мы — инженеры, а значит, наши инструменты должны быть откалиброваны. В лаборатории «Федерации судебных экспертов»: 📏✅

Все write-blockers проходят ежемесячную проверку на эталонном диске с известными хешами.

ПО для анализа логов (ApexSQL Log, LogMiner) имеет сертификаты совместимости с версиями СУБД.

Скрипты собственной разработки проходят регрессионное тестирование на тестовых БД с внесёнными заведомыми искажениями.

Хеш-суммы сверяются с эталонными значениями NIST.

Если судья спросит: «А откуда вы знаете, что ваша утилита не ошибается?» — мы покажем протоколы поверки. Это даёт 100% доверие к нашим выводам. 🔬📐

Глава 14. Экспертное заключение как инженерный чертёж

Наше заключение — это не «текст», а техническая документация, включающая: 📑🛠️

Раздел 1: Исходные данные (хеши, метаданные образов).

Раздел 2: Методика (ссылки на ГОСТы и внутренние регламенты).

Раздел 3: Результаты исследований (таблицы LSN, скриншоты логов, выписки из дампов).

Раздел 4: Синтез (как артефакты складываются в картину).

Раздел 5: Выводы (только на подтверждённых фактах, без предположений).

Каждый вывод имеет ссылку на конкретный артефакт: «Вывод №3 следует из раздела 4.2, таблица 7, строка 12». Это позволяет суду и сторонам проверить логику. Мы не боимся проверки — наоборот, требуем её. 🧾🔍

Глава 15. Будущее инженерной судебной экспертизы ERP

Мы стоим на пороге цифровой революции в правосудии. Уже сегодня внедрены: 🚀🤖

Автоматический анализ LSN-последовательностей — нейросеть LSTM выявляет временные аномалии в журналах.

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

Симуляция работы ERP — создаём «песочницу», где повторяем спорные операции и смотрим, можно ли их выполнить без оставления следов.

Анализ wear-leveling SSD — извлекаем данные из областей, которые контроллер SSD пометил как «удалённые», но не перезаписал.

Но неизменным остаётся главное: экспертиза ERP-систем по запросу суда должна выполняться инженерами, а не «общими» программистами. Союз «Федерация судебных экспертов» — это сообщество инженеров, которые превращают цифровой хаос в стройные доказательства.

🟢 Ваш следующий шаг — сайт kompexp.ru. Там вы найдёте форму для заказа экспертизы, примеры инженерных заключений и контакты для срочных запросов. Доверьте цифровую истину профессионалам с инженерной душой.

Союз «Федерация судебных экспертов». Инженерия доказывания. 🛠️⚖️💡