Технические протоколы, инструментарий, восстановление данных

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

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

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

Инженерная экспертиза 1с по запросу суда решает следующие типовые задачи:

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

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

• восстановление удаленных или поврежденных учетных записей;

• выявление недокументированных модификаций конфигурации;

• анализ корректности работы алгоритмов (расчет себестоимости, формирование проводок, закрытие периода);

• исследование аппаратной части (состояние дисков, RAID-массивов, наличие следов несанкционированного доступа).

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

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

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

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

• Определение типа системы: файловый режим (файл .1CD на сетевой папке) или клиент-сервер (сервер СУБД + сервер 1С).

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

• Отключение сервера от сети (graceful shutdown).

• Подключение write-blocker к каждому диску (Tableau T8, Atola Insight).

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

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

• Фиксация в протоколе chain of custody.

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

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

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

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

Методы анализа:

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

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

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

• Чтение записей: для таблиц с фиксированной длиной записи — прямая адресация, для переменной — анализ указателей.

• Обработка сжатых страниц (версии 1С поддерживают сжатие).

Инструменты: собственный фреймворк на C++/Python, скрипты для анализа бинарных данных, а также легальные утилиты с открытым исходным кодом (например, 1C Raw File Reader). Инженер должен понимать, что даже при повреждении заголовка возможно восстановление фрагментов данных через сканирование всего файла и поиск сигнатур записей.

Глава 4. Инженерный анализ технологического журнала 1С (techlog)

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

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

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

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

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

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

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

• Парсинг файлов (обычно больших, до десятков гигабайт). Используются скрипты на Python с асинхронным чтением, либо специализированные утилиты (например, TechLog Parser от фирмы 1С).

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

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

• Анализ аномалий: например, выполнение 10000 SQL-запросов за секунду в нерабочее время.

• Сопоставление с IP-адресами и учетными записями.

• Верификация: сравнение данных techlog с журналом регистрации 1С и транзакционными логами СУБД. Расхождения указывают на вмешательство.

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

Техническая фабула: В рамках расследования уголовного дела о мошенничестве (ст. 159 УК РФ) был изъят сервер, на котором находилась база 1С:Бухгалтерия. При попытке открытия база выдавала ошибку «Файл базы данных поврежден». Сторона защиты утверждала, что данные нечитаемы, а значит, не могут быть доказательством. Эксперты Союза «Федерация судебных экспертов» провели инженерную экспертизу.

Методология:

• Создан образ файла 1Cv8.1CD (размер 120 ГБ).

• Анализ заголовка показал, что сигнатура «1CDB» сохранена, но поврежден указатель на корневую страницу метаданных.

• С помощью разработанного сканера (поиск сигнатур таблиц и индексов) эксперты идентифицировали 85% таблиц, включая «Документ.ПлатежноеПоручение», «РегистрБухгалтерии.Хозрасчетный».

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

• Восстановлено 1287 документов о перечислении денежных средств на общую сумму 94 млн руб.

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

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

Глава 6. Инженерная диагностика сервера 1С: анализ RAID, SMART, журналов

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

• Чтение SMART-атрибутов всех дисков (Reallocated Sectors, Current Pending Errors, Power On Hours). Признаки умышленного повреждения — например, внезапный сброс SMART после удаления данных.

• Анализ RAID-контроллера: состояние массива (Optimal, Degraded, Failed), журнал событий (BBU learn cycles, disk failures).

• Восстановление данных из деградировавшего RAID: определение порядка дисков, stripe size, parity layout. Используются R-Studio, UFS Explorer.

• Анализ системных журналов Windows (EventLog) или Linux (syslog) на предмет ошибок диска, отключений питания, принудительных перезагрузок.

• Анализ журналов службы 1С: сервер 1С (ras), агент сервера (ragent), которые фиксируют запуски, ошибки подключения, завершения сеансов.

• Проверка соответствия аппаратной конфигурации системным требованиям 1С. Например, недостаток оперативной памяти может приводить к ошибкам записи и потере данных.

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

Глава 7. Анализ сетевого трафика между клиентом 1С и сервером

В клиент-серверной архитектуре 1С обмен между клиентским приложением и сервером происходит через протокол TCP (порты 1540–1541, 1560–1561). Инженерный анализ сетевого трафика может выявить:

• факт подключения несанкционированных клиентов;

• выполнение операций с необычных IP-адресов;

• попытки перехвата или модификации данных (если трафик не шифрован).

Методы:

• Если захват трафика производится в реальном времени (например, по определению суда), используются TAP-устройства (сетевые разветвители) и ПО Wireshark.

• При ретроспективном анализе — исследование дампов трафика, сохраненных на сервере (если велся лог).

• Анализ заголовков пакетов: IP-адреса, MAC-адреса (если на одном сегменте сети), порты, последовательности TCP-сессий.

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

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

Сетевой анализ особенно важен при подозрении на использование удаленного доступа (RDP, VPN) для фальсификации.

Глава 8. Кейс № 2: Инженерная экспертиза сервера 1С с поврежденным RAID-5

Техническая фабула: ООО «ПромТех» обратилось в суд с иском к своему системному администратору о взыскании ущерба, возникшего из-за «случайного» удаления двух дисков из RAID-5 массива, на котором хранилась база 1С:ERP. Администратор утверждал, что это была ошибка. Экспертам предстояло установить, был ли инцидент умышленным.

Инженерное исследование:

• Созданы образы двух оставшихся дисков (третий был физически уничтожен).

• Анализ SMART третьего диска (по сохранившимся логам RAID-контроллера) показал, что диск был в идеальном состоянии, без битых секторов.

• Анализ журнала контроллера (LSI MegaRAID) выявил: первый диск был отключен командой «prepare for removal» (штатная процедура, требующая ввода пароля). Второй диск отключен через 2 минуты командой «force offline».

• Временные метки этих событий совпадают с временем входа администратора в систему управления сервером по RDP (зафиксировано в журнале Windows).

• Эксперты также восстановили из кэша RAID-контроллера фрагменты последних записей БД 1С.

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

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

Глава 9. Восстановление удаленных записей из транзакционного лога СУБД для 1С

При клиент-серверном варианте 1С на MS SQL Server или PostgreSQL журнал транзакций является наиболее полным источником информации о всех изменениях данных. Инженерный метод восстановления:

Для MS SQL Server:

• Проверка режима восстановления базы (FULL — полное восстановление, сохраняет все транзакции).

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

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

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

• Преобразование сырых данных в читаемый вид (с учетом форматов полей 1С: строки, числа, даты, ссылочные типы).

Для PostgreSQL:

• Анализ WAL-логов (pg_waldump).

• Исследование «мертвых кортежей» (dead tuples) в таблицах с помощью pg_filedump.

• Извлечение истории изменений через расширение pg_audit, если оно было включено.

Инженерная сложность: восстановление ссылочной целостности (например, документ ссылается на справочник, который был удален). Эксперт должен восстанавливать все связанные объекты.

Глава 10. Анализ временных меток файлов 1С и ОС

Инженерная экспертиза включает анализ временных меток на уровне файловой системы. Для файлового режима 1С: файл .1CD имеет атрибуты: время создания, время последнего изменения, время последнего доступа. В NTFS эти метки хранятся в двух местах: в STANDARD_INFORMATION (SI) и в FILE_NAME (FN). Расхождение между SI и FN часто указывает на попытку подделки времени.

Методы:

• Использование утилиты GetFileInfo или скриптов на PowerShell для вывода всех меток.

• Анализ USN Journal — журнала изменений файловой системы, который фиксирует каждое изменение файла (даже если изменялись метки).

• Поиск временных файлов 1С (расширения .tmp, .tmpl), которые создаются при работе и удаляются при штатном завершении. Их наличие и метки могут указать на аварийное завершение работы или намеренное отключение.

• Для клиент-серверного режима: анализ временных меток файлов базы данных СУБД (.mdf, .ndf, .ldf). Время последней записи в лог-файле должно соответствовать времени последней транзакции. Расхождение указывает на подмену файлов.

• Сопоставление с журналами синхронизации времени (NTP-логи, системные Event ID 1). Если системное время на сервере изменялось, это фиксируется.

Инженер должен уметь отличать легитимные изменения (переход на зимнее/летнее время) от аномальных.

Глава 11. Кейс № 3: Инженерная экспертиза по спору о недостоверности отчета о движении товаров в 1С

Техническая фабула: ООО «Логист-М» подало иск к контрагенту о взыскании 34 млн руб. за поставленный товар. В качестве доказательства истец представил отчет о движении товаров из 1С:Управление торговлей, согласно которому товар был отгружен. Ответчик утверждал, что отчет сфальсифицирован. Суд назначил инженерную экспертизу.

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

• Анализ файла .1CD методом низкоуровневого чтения. Обнаружено, что записи в регистре накопления «ТоварыНаСкладах» для спорной поставки имеют временные метки создания на 3 дня позже заявленной даты отгрузки.

• Анализ технологического журнала (techlog) сервера 1С: найдены SQL-запросы INSERT в таблицу регистра, выполненные в 02:15 ночи, с IP-адреса, не входящего в список разрешенных.

• Анализ журнала событий Windows: зафиксировано изменение системного времени сервера на 3 дня назад за 30 минут до этих INSERT и последующее восстановление.

• Эксперты также проанализировали MAC-адрес сетевой карты, с которой выполнялись операции, — он принадлежал рабочей станции бухгалтера истца.

• Вывод: отчет о движении товаров содержит записи, внесенные задним числом, с подменой даты.

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

Глава 12. Инженерная метрология: поверка измерительных инструментов в экспертизе 1С

Инженерная экспертиза требует, чтобы используемые инструменты были метрологически аттестованы. В экспертизе 1С это означает:

• ПО для создания образов (FTK Imager, dd) должно иметь версию с известной контрольной суммой и использоваться строго по инструкции.

• Аппаратные write-blockers должны иметь действующие сертификаты поверки (подтверждение, что они действительно блокируют запись).

• Утилиты для анализа .1CD (включая собственные разработки) должны быть валидированы на тестовых наборах данных с известными свойствами. Например, берется тестовая база 1С, вносятся известные изменения, затем эксперт применяет свой инструмент и проверяет, что результаты совпадают.

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

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

Все это фиксируется в протоколе. Отсутствие метрологического обоснования может быть основанием для исключения заключения. Союз «Федерация судебных экспертов» строго соблюдает эти требования.

Глава 13. Инженерные методы противодействия умышленному уничтожению данных 1С

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

• Низкоуровневое форматирование дисков (перезапись нулями). Контрмера: если диск был отформатирован быстро (quick format), метаданные файловой системы уничтожены, но данные физически остаются — возможно восстановление через анализ остаточных магнитных доменов (требуется лаборатория).

• Использование программ типа CCleaner с перезаписью свободного пространства 7 проходами (Gutmann). Контрмера: анализ оставшихся служебных областей (например, область замены дефектных секторов HDD).

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

• Шифрование дисков BitLocker с уничтожением ключа. Контрмера: если сервер был включен — дамп памяти (см. главу 14).

• Перезапись файла .1CD через открытие платформой 1С и запуск тестирования/исправления. Контрмера: анализ теневых копий VSS, если они были включены.

Инженер должен всегда действовать на опережение: изымать носители как можно быстрее, создавать образы, использовать write-blockers. Скорость реакции — ключ к успеху.

Глава 14. Специфика экспертизы 1С по запросу суда: процессуальные аспекты

Инженерная экспертиза 1с по запросу суда имеет процессуальные особенности. Суд выносит определение, в котором указывает:

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

• перечень вопросов, требующих инженерного разрешения;

• объекты, подлежащие исследованию (конкретные диски, файлы, серверы);

• сроки проведения;

• порядок предоставления объектов (например, с участием сторон или в отсутствие, с применением видеозаписи).

Эксперт не вправе самостоятельно собирать доказательства — только исследовать предоставленные объекты. Однако он может заявить ходатайство о предоставлении дополнительных материалов (логи контроллера, документация на RAID). Суд обязан рассмотреть ходатайство.

Эксперт предупреждается об уголовной ответственности по ст. 307 УК РФ. При проведении экспертизы эксперт должен избегать выхода за пределы своей компетенции (например, не давать правовую оценку действиям лиц). Заключение представляется в суд в бумажном и электронном виде (с подписью и печатью). Допрос эксперта в суде возможен для разъяснения выводов.

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

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

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