Инженерные методы, анализ данных, доказательная база

Система программ «1С:Предприятие» является доминирующей платформой для автоматизации бухгалтерского, налогового, управленческого и производственного учета в Российской Федерации. Миллионы предприятий — от малого бизнеса до крупнейших государственных корпораций — используют различные конфигурации 1С. В силу этого обстоятельства базы данных 1С стали важнейшим хранилищем юридически значимой информации. Судебные споры о хищениях, неисполнении договоров, фальсификации отчетности, недобросовестной конкуренции, а также корпоративные конфликты и дела о банкротстве все чаще разрешаются на основе анализа данных из 1С. Однако суд не может принять распечатку из 1С как безусловное доказательство — необходима независимая, научно и инженерно обоснованная верификация. Именно эту задачу решает IT экспертиза 1с для подачи в суд, выполняемая экспертами Союза «Федерация судебных экспертов». Настоящая статья, написанная в инженерном стиле, детально рассматривает методы и инструменты такой экспертизы: от низкоуровневого анализа файлов .1CD и работы с технологическим журналом до восстановления удаленных записей и выявления модификаций конфигурации. Приведены три реальных кейса из практики.

Глава 1. IT-экспертиза 1С: предмет, объекты, инженерные задачи

IT-экспертиза 1С — это специализированный вид судебной экспертизы, объектами которой являются информационные системы на базе платформы «1С:Предприятие» в их аппаратном, системном и прикладном окружении. Предметом выступают фактические данные, имеющие значение для дела, извлекаемые из этих объектов:

• содержание и хронология учетных операций (документы, проводки, движения регистров);

• факты и время создания, модификации, удаления записей;

• идентификация пользователей, совершавших действия;

• наличие и характер изменений в конфигурации (алгоритмах учета);

• обстоятельства технических сбоев и потери данных;

• соответствие данных 1С первичным документам и требованиям законодательства.

IT экспертиза 1с для подачи в суд отличается от других видов экспертиз акцентом на программно-аппаратную составляющую и использование специализированного IT-инструментария. Инженерный подход подразумевает измеримость результатов, воспроизводимость экспериментов и метрологическое обеспечение всех этапов. Ключевые задачи эксперта: восстановление удаленного, выявление скрытого, анализ аномалий и формирование технически обоснованного заключения, понятного суду.

Глава 2. Инженерный протокол изъятия и консервации объектов 1С

Первый и важнейший этап любой экспертизы — правильное изъятие и консервация объектов. Инженерный протокол Союза «Федерация судебных экспертов» включает следующие обязательные шаги:

• Документирование места изъятия: фото- и видеофиксация серверной стойки, подключенных кабелей, серийных номеров оборудования.

• Определение режима работы 1С: файловый (база в виде файла .1CD на сетевом диске) или клиент-сервер (MS SQL Server, PostgreSQL).

• Приоритетное создание образа работающей системы: если сервер включен, эксперты используют специальные утилиты для создания «горячего» образа (например, Volume Shadow Copy для Windows) или подключаются к СУБД для создания логического дампа (выгрузка dt).

• Затем следует отключение сервера (graceful shutdown) и подключение аппаратных write-blocker-ов (Tableau T8, Atola Insight).

• Создание побитовых образов всех дисков и SSD: системных, дисков с файлами .1CD, дисков с журналами транзакций СУБД, дисков с технологическим журналом. Инструменты: FTK Imager, dd под Linux.

• Вычисление хеш-сумм (SHA-256) для каждого образа и оригинального носителя — они должны совпадать.

• Заполнение протокола chain of custody (цепочка хранения) с подписями всех участвующих лиц.

• Для облачных решений 1С (1С:Фреш, 1С:ГРМ в облаке) — запрос через суд к провайдеру выгрузки базы в формате dt, подписанной УКЭП.

Без соблюдения этого протокола заключение рискует быть признанным недопустимым доказательством.

Глава 3. Низкоуровневый анализ файла .1CD: архитектура и методы чтения

Файл базы данных 1С (.1CD) имеет внутреннюю страничную структуру, знание которой критически важно для IT экспертизы 1с для подачи в суд. Файл состоит из заголовка (первые 512 байт — сигнатура «1CDB», версия формата, размер страницы), карты распределения страниц (bitmap), страниц данных, страниц индексов и свободных страниц. Размер страницы обычно 4 КБ (реже 8 или 16 КБ).

Инженерный метод низкоуровневого чтения:

• Анализ заголовка для определения параметров.

• Чтение карты страниц для идентификации всех страниц, включая помеченные как свободные (deleted).

• Извлечение метаданных (структура таблиц) из системных таблиц внутри .1CD. Если база повреждена, метаданные могут быть восстановлены из типовой конфигурации (если известна).

• Прямое чтение страниц данных с интерпретацией записей на основе метаданных. Для записей фиксированной структуры — простое смещение, для переменной — анализ указателей.

• Обработка сжатых страниц (алгоритм LZ) при необходимости.

• Сборка записей в таблицы и экспорт в структурированный формат (например, JSON или CSV).

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

Глава 4. Технологический журнал (techlog) как источник объективной информации

Технологический журнал (techlog) — это механизм платформы 1С, обеспечивающий детальное логирование работы сервера. По своей сути это инженерный «черный ящик», фиксирующий: каждый SQL-запрос, его план выполнения, время выполнения, количество обработанных строк, ошибки, блокировки, вызовы внешних компонент, информацию о сеансах пользователей. Techlog настраивается через файл конфигурации (logcfg.xml) и может записывать события в реальном времени.

Для IT-экспертизы techlog ценен тем, что:

• он работает на низком уровне, независимо от прикладной логики;

• его сложнее отключить или очистить, чем журнал регистрации 1С;

• он содержит миллисекундные временные метки;

• он фиксирует даже операции, выполненные через прямой SQL-доступ (минуя платформу).

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

• Локализацию файлов techlog (обычно на сервере 1С в папке C:\Program Files\1cv8\srvinfo или в каталоге базы).

• Парсинг файлов (которые могут достигать десятков гигабайт) с помощью скриптов на Python или специализированных утилит.

• Фильтрацию по временному диапазону, типам событий, пользователям, именам таблиц.

• Построение временных линий (timeline) операций.

• Выявление аномалий: например, массовое выполнение DELETE запросов в нерабочее время.

• Сопоставление данных techlog с журналом регистрации и данными из файла .1CD. Расхождения указывают на попытки фальсификации.

Techlog может быть единственным источником, если журнал регистрации был очищен.

Глава 5. Кейс № 1: Восстановление удаленной базы 1С из теневых копий и технологического журнала

Техническая фабула: ООО «СтройКомплект» подало иск к бывшему техническому директору о взыскании 67 млн руб., которые, по версии истца, были перечислены на счета аффилированных фирм. За день до выемки сервера неизвестные удалили файл 1Cv8.1CD (база 1С:Бухгалтерия) и очистили журнал регистрации.

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

• Анализ диска сервера показал, что на нем была включена служба Volume Shadow Copy (VSS).

• Из теневой копии за 2 дня до удаления извлечен файл 1Cv8.1CD (рабочая база).

• Однако в теневой копии отсутствовали последние изменения за день до удаления.

• Анализ технологического журнала (techlog), который сохранился на отдельном диске, позволил восстановить все SQL-запросы за день удаления.

• Эксперты разработали скрипт для реконструкции операций INSERT и UPDATE в базу данных на основе записей techlog.

• Восстановлены 147 документов о перечислении средств на сумму 67 млн руб. с указанием IP-адреса, времени и имени пользователя.

• Сопоставление с логами доступа к серверу подтвердило, что операции проводились с рабочей станции технического директора.

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

Глава 6. Анализ журналов транзакций СУБД при клиент-серверном варианте 1С

В клиент-серверном варианте 1С (на Microsoft SQL Server или PostgreSQL) данные хранятся в СУБД, а файл .1CD содержит лишь метаданные и кэш. Журнал транзакций СУБД является наиболее надежным источником для IT экспертизы 1с для подачи в суд.

Для MS SQL Server:

• Определение режима восстановления базы данных (FULL — полное восстановление, сохраняет все транзакции; BULK_LOGGED — частичное; SIMPLE — минимальное, обрезает лог).

• Анализ LSN-цепочки (Log Sequence Number) с помощью системной функции fn_dblog(NULL, NULL).

• Извлечение всех операций (INSERT, UPDATE, DELETE) над таблицами 1С (имена таблиц имеют вид _ReferenceXX, _DocumentXX, _AccumulationXX).

• Восстановление удаленных записей: чтение страниц данных до момента их перезаписи сборщиком мусора.

• Идентификация пользователя через контекст соединения (SPID, hostname, program_name).

Для PostgreSQL:

• Анализ WAL-логов (Write-Ahead Log) с помощью pg_waldump.

• Исследование мертвых кортежей (dead tuples) в таблицах — в PostgreSQL старые версии записей не удаляются сразу, что позволяет восстановить историю изменений.

• Использование расширений pg_audit, pg_stat_statements для дополнительной информации.

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

Глава 7. Исследование конфигурации 1С: выявление изменений и оценка их влияния

В спорах о некачественном внедрении или о хищениях через модификацию алгоритмов (например, изменение формул расчета себестоимости) необходимо исследование конфигурации 1С. Конфигурация — это описание структуры метаданных (справочники, документы, регистры, отчеты) и программный код на встроенном языке.

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

• Получение эталонной конфигурации — из резервной копии, из типовой поставки или из предыдущей версии.

• Сравнение конфигураций с помощью штатного механизма 1С: «Сравнение, объединение конфигураций» в конфигураторе.

• Документирование каждого различия: изменение модуля, добавление реквизита, модификация формы.

• Анализ временных меток изменений: если ведется журнал регистрации изменений (хранится в конфигурации), можно определить автора и дату.

• Оценка функционального влияния: приводит ли изменение к искажению учета, к возможности обойти контрольные механизмы, к недокументированному поведению.

• Проверка кода на наличие «закладок»: например, условный оператор, который при определенном значении реквизита изменяет сумму документа.

• При необходимости — декомпиляция скомпилированных модулей (файлы .cf, .cfs) с помощью специализированных утилит.

Вывод эксперта должен содержать техническое описание изменения и его потенциальные последствия для учетных данных.

Глава 8. Кейс № 2: Выявление модификации алгоритма формирования проводок в 1С:Бухгалтерия

Техническая фабула: Аудиторская проверка выявила, что в 1С:Бухгалтерия государственного учреждения счета-фактуры на крупные суммы (всего 89 млн руб.) проводились с некорректными проводками: вместо дебета счета учета расчетов с поставщиками (302.34) использовался дебет счета 401.20 (расходы текущего финансового года). Это привело к искажению кредиторской задолженности и завышению расходов. Было возбуждено уголовное дело по ст. 159 УК РФ.

Эксперты Союза «Федерация судебных экспертов» провели IT-экспертизу. Методология:

• Сравнение текущей конфигурации (на момент проверки) с эталонной (типовая конфигурация «Бухгалтерия государственного учреждения» версии 2.0).

• Обнаружено изменение в модуле документа «Счет-фактура полученный»: в процедуре формирования проводок был добавлен условный оператор, который при совпадении ИНН поставщика с заданным списком из 5 ИНН заменял счет дебета с 302.34 на 401.20.

• Анализ журнала изменений конфигурации показал, что изменение внес пользователь с правами администратора за 3 дня до первой некорректной проводки.

• Технологический журнал зафиксировал все случаи срабатывания этого условия — 234 документа.

• Эксперты восстановили суммы и контрагентов из techlog.

Суд признал наличие состава преступления. Кейс демонстрирует важность анализа не только данных, но и программного кода конфигурации 1С.

Глава 9. Анализ временных меток и выявление аномалий (backdating)

Фальсификация дат документов (backdating) — одна из самых частых манипуляций в 1С. Инженерные методы обнаружения:

• Сравнение даты документа (поле Date) с временем создания записи в базе данных (системное поле Created или временные метки файловой системы). Для файлового режима 1С: анализ атрибутов файла .1CD (время последнего изменения должно быть согласовано с датой последнего документа).

• Анализ последовательности номеров документов — если документ с более поздним номером имеет более раннюю дату — аномалия.

• Для клиент-серверного режима: анализ LSN (Log Sequence Number) в SQL Server — строго возрастающая последовательность. Если документ с датой 01.01.2023 имеет LSN выше, чем документ с датой 02.01.2023, это указывает на вставку задним числом.

• Анализ системного журнала событий Windows (Event ID 1 — изменение времени) или логов ntpd в Linux.

• Анализ технологического журнала: techlog фиксирует время выполнения операции на сервере. Если в techlog указано, что документ создан в 14:35 02.02.2023, а в поле Date документа стоит 01.02.2023 — расхождение.

• Использование внешних источников времени: логи Active Directory (время входа пользователя), логи почтового сервера (отправка уведомлений).

Эксперт строит многомерную временную линию и вычисляет вероятность случайного совпадения аномалий. При выявлении устойчивых паттернов подделки делается категорический вывод.

Глава 10. Восстановление данных из поврежденных носителей и RAID-массивов

Аппаратные сбои или умышленное повреждение носителей — частое явление в судебной практике. Инженерная задача: максимально восстановить данные 1С. Типовые сценарии:

• Поврежден файл .1CD (заголовок или отдельные страницы). Решение: низкоуровневое чтение с пропуском битых участков, восстановление метаданных из резервных страниц, если они существуют.

• RAID-массив в состоянии Failed или Degraded. Решение: создание образов всех дисков (даже вышедших из строя — с помощью ddrescue), определение параметров RAID (порядок дисков, stripe size, parity layout), виртуальная сборка в R-Studio или UFS Explorer, извлечение данных.

• Физически неисправный HDD (стук, битые сектора). Решение: чтение в режиме «карового сканирования» с настройкой таймаутов, использование оборудования PC-3000 для обхода неисправной электроники.

• Перезаписанный диск (после форматирования). Решение: анализ остаточных магнитных доменов (требует лаборатории), поиск сигнатур файлов 1С («1CDB», «1Cv8»).

• SSD с технологией TRIM. Решение: если TRIM уже сработал, восстановление невозможно; если нет — немедленное отключение питания и создание образа с помощью специализированного оборудования.

Эксперт должен оценить вероятность успешного восстановления (0% — 100%) и указать ее в заключении.

Глава 11. Кейс № 3: Инженерная экспертиза сервера 1С с поврежденным SSD и восстановление из кэша СУБД

Техническая фабула: ООО «ЭнергоСбыт» обратилось в суд с иском к своему бывшему IT-специалисту, который перед увольнением якобы инициировал программу низкоуровневого форматирования SSD-дисков с базой 1С:ERP. В результате база была утрачена.

Эксперты Союза «Федерация судебных экспертов» (https://kompexp.ru/ekspertiza-programmnyh-produktov-na-baze-sistemy-1s/) провели исследование. Методология:

• Образы SSD созданы с помощью специализированного оборудования (Tableau с адаптером для NVMe). Обнаружено, что TRIM уже сработал, данные нечитаемы.

• Однако на сервере также был установлен MS SQL Server для работы 1С в клиент-серверном режиме.

• Эксперты проанализировали системные базы данных SQL Server (master, model, msdb) и обнаружили, что планировалось резервное копирование на внешний диск, которое не было выполнено.

• Критически: эксперты извлекли из кэша буферного пула SQL Server (файл SQL Server Buffer Pool Extension) фрагменты страниц базы данных 1С, которые остались в памяти и были сброшены на диск при аварийном завершении работы.

• Из этих фрагментов удалось восстановить 75% таблиц, включая справочники «Контрагенты» и документы «Реализация товаров» за последние 6 месяцев.

• Восстановленные данные позволили суду установить факт хищений на сумму 43 млн руб.

Иск удовлетворен. Кейс показывает, что даже при повреждении основных данных могут сохраниться их фрагменты в неожиданных местах.

Глава 12. Инженерная метрология и верификация результатов

Научная обоснованность IT экспертизы 1с для подачи в суд требует метрологического подхода. Это означает:

• Все используемые программные и аппаратные средства должны быть валидированы. Для write-blocker-ов — действующий сертификат калибровки; для ПО для создания образов — известная контрольная сумма и проверка на тестовых данных.

• Хеш-суммы (SHA-256) должны вычисляться с использованием сертифицированных криптографических библиотек.

• Временные измерения (длительность операций, временные метки) должны быть привязаны к эталонному времени (NTP-сервер с точностью до 1 мс).

• Методы восстановления данных должны быть проверены на контрольной выборке: берется тестовая база 1С с известным содержимым, удаляются документы, эксперт восстанавливает их и сравнивает результат с оригиналом. Коэффициент восстановления (процент успешно восстановленных записей) должен быть указан в заключении.

• Для выявленных аномалий (например, расхождение временных меток) вычисляется статистическая вероятность случайного возникновения. При вероятности менее 0,001% вывод считается категорическим.

• Эксперт должен документировать все этапы, включая команды, версии ПО, даты. Это позволяет другому эксперту воспроизвести результат.

Только при соблюдении метрологических принципов заключение может быть признано научно обоснованным.

Глава 13. Противодействие IT-экспертизе 1С: типовые методы и контрмеры

Недобросовестные стороны могут активно противодействовать экспертизе. Знание этих методов позволяет эксперту подготовиться. Типовые методы противодействия:

• Очистка журнала регистрации 1С через интерфейс «Настройка журнала регистрации — Очистить». Контрмера: анализ технологического журнала (techlog) и транзакционных логов СУБД.

• Удаление документов с последующей перезаписью свободных страниц через «Тестирование и исправление» базы. Контрмера: низкоуровневое чтение до запуска тестирования; если тестирование уже проведено — анализ резервных копий.

• Модификация конфигурации с последующим удалением истории изменений. Контрмера: анализ временных меток файлов конфигурации (.cf, .cfs), анализ журналов обновлений 1С (файлы .cf.update).

• Шифрование файла .1CD (нештатными средствами). Контрмера: запрос пароля через суд; анализ дампа памяти работающего сервера.

• Физическое уничтожение носителя (дробление, кислотное травление). Контрмера: анализ резервных копий (облачных, на LTO-лентах), анализ систем, интегрированных с 1С (банк-клиент, ККМ, складские терминалы).

• Использование удаленного доступа (RDP, TeamViewer) для выполнения действий с подменой IP. Контрмера: анализ журналов доступа на сервере терминалов; анализ временных меток и сопоставление с данными провайдера.

Скорость реагирования — ключевой фактор: чем быстрее эксперты получают доступ к носителям, тем больше данных удается сохранить.

Глава 14. Подготовка инженерного заключения для суда

Заключение IT-эксперта — это технический документ, который должен быть понятен суду, но при этом содержать все инженерные детали. Структура, принятая Союзом «Федерация судебных экспертов»:

• Вводная часть: основание (определение суда), сведения об эксперте (образование, стаж), предупреждение об ответственности по ст. 307 УК РФ.

• Список объектов с указанием типов, размеров, хеш-сумм (SHA-256).

• Методика: перечень использованных методов и инструментов (с версиями, контрольными суммами).

• Ход исследования: пошаговое описание всех действий с указанием временных меток и полученных промежуточных результатов.

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

• Синтез: интерпретация результатов применительно к вопросам суда.

• Выводы: четкие, однозначные ответы на каждый поставленный вопрос. Если вывод вероятностный — указать степень вероятности (например, «с вероятностью 95%»).

• Приложения: компакт-диск с электронными версиями таблиц, скриптами, дампами.

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

Глава 15. Заключение: роль IT-экспертизы 1С в судебной практике

Подводя итог, можно с уверенностью утверждать, что IT экспертиза 1с для подачи в суд является критически важным инструментом для установления истины в судебных спорах, связанных с учетными данными. В данной статье мы рассмотрели инженерные аспекты такой экспертизы: от низкоуровневого анализа файлов .1CD и технологического журнала до восстановления данных из поврежденных RAID и противодействия умышленному уничтожению. Три кейса (восстановление из теневых копий и techlog, выявление модификации алгоритма проводок, восстановление из кэша СУБД при поврежденном SSD) демонстрируют практическую применимость методов.

Повторим ключевую фразу, которая должна быть ориентиром для всех участников судебного процесса: IT экспертиза 1с для подачи в суд — это единственный способ получить объективное, научно обоснованное, инженерно верифицированное заключение о состоянии данных в системе 1С. Союз «Федерация судебных экспертов» (сайт: https://kompexp.ru/ekspertiza-programmnyh-produktov-na-baze-sistemy-1s/) предлагает свои услуги по проведению таких экспертиз на высшем профессиональном уровне. Доверяя нам, вы выбираете точность, независимость и инженерную строгость. Пусть цифровая истина всегда будет на вашей стороне! 🟩