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

Инженерное введение: почему 1С требует особого подхода в судебной экспертизе 🛠️

Система «1С: Предприятие» является доминирующей платформой для автоматизации учёта на территории РФ и стран СНГ. Её архитектурные особенности (файловый и клиент-серверный режимы, мощный встроенный язык, технологический журнал, возможность модификации конфигурации) делают её одновременно и идеальным носителем доказательств, и сложнейшим объектом для исследования. Традиционные методы компьютерной экспертизы, разработанные для анализа файловых систем и офисных документов, часто неприменимы к 1С. Требуется глубокое знание внутреннего устройства платформы: структуры таблиц, механизмов блокировок, форматов журналов. 🧩 Мы, Союз «Федерация судебных экспертов», разработали специализированную инженерную методику для исследования систем на базе 1С.

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

Глава 1. Архитектура платформы 1С как объект судебного исследования 🏗️

Платформа 1С: Предприятие существует в двух основных вариантах:

Файловый режим: данные хранятся в одном или нескольких файлах с расширениями.1cd,.dbf,.cdx,.lgp,.efd. Это простейший случай с точки зрения изъятия (достаточно скопировать файлы), но сложный с точки зрения целостности (можно легко подделать временные метки).

Клиент-серверный режим: СУБД (MS SQL Server, PostgreSQL, IBM DB2) выступает хранилищем данных. Экспертиза требует доступа к серверу СУБД.

Ключевые артефакты для экспертизы:

Файл базы данных.1cd (в файловом варианте) — содержит все таблицы данных, индексы, константы. Имеет собственную внутреннюю структуру страниц (размер страницы 4 или 8 КБ в зависимости от версии). Каждая страница имеет заголовок с GUID, типом страницы (данные, индекс, битовая карта), и контрольной суммой.

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

Технологический журнал (ТЖ) — самый ценный источник. Включается через специальные ключи командной строки сервера 1С или через файл logcfg.xml. Фиксирует каждое действие на уровне движка: открытие форм, выполнение запросов, время ожидания блокировок, запуски фоновых заданий. Не может быть отключён программно из пользовательского сеанса — только администратором сервера.

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

Дамп памяти процесса 1С (сервера ragent и rphost или клиента 1cv8) — содержит несохранённые данные, пароли, кеш запросов.

IT экспертиза 1С для подачи в суд обязательно должна включать анализ ТЖ, если он был включён, и анализ журналов СУБД, если используется клиент-сервер. Без этого эксперт «слеп».

Глава 2. Инженерная методика изъятия и консервации данных 1С 📦

Процедура изъятия различается в зависимости от режима работы:

Для файлового варианта:

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

С помощью аппаратного блокиратора записи (write-blocker) подключаем диск сервера к рабочей станции эксперта.

Создаём побитовую копию всего логического тома (или физического диска) с помощью dcfldd или FTK Imager. Ключевой момент: копируем не только файл.1cd, но и файлы временных таблиц (обычно в папке %TEMP% сервера) — там могут быть фрагменты удалённых данных.

Вычисляем SHA-256 для файла.1cd и для каждого фрагмента образа.

Упаковываем оригинальный диск в антистатический пакет, опечатываем.

Для клиент-серверного варианта (1С + SQL Server):

Останавливаем службы 1С (но не SQL Server — чтобы сохранить кэш в памяти).

Создаём дамп оперативной памяти сервера с помощью winpmem (для Windows) или avdump (для Linux).

Делаем резервную копию базы данных средствами SQL Server (BACKUP DATABASE… TO DISK). Это корректное отключение, но для криминалистики лучше сделать ALTER DATABASE… SET OFFLINE, затем скопировать файлы.mdf и.ldf.

Отключаем сервер от сети, изымаем диски с соблюдением chain of custody.

Важное правило: Никогда не запускайте на сервере 1С никакие штатные обработки (например, «Тестирование и исправление») до изъятия — они могут изменить данные и уничтожить улики.

Глава 3. Три инженерных кейса с полным техническим разбором 🔬

Кейс №1. Восстановление удалённых записей журнала регистрации через анализ.lgp-файлов.
Ситуация: Коммерческий директор, увольняясь, запустил обработку «Очистка журнала регистрации», удалив записи о своих правках договоров с контрагентами на сумму 23 млн руб. Методология: Наша IT экспертиза 1С для подачи в суд началась с анализа каталога базы 1С. В файловом варианте 1С создаёт файлы.lgp (log — журнал транзакций). Они не удаляются при очистке журнала регистрации! Мы открыли файл 1Cv8.lgp с помощью HEX-редактора HxD и проанализировали его структуру: каждый блок начинается с сигнатуры 1C.LOG, затем идёт timestamp (8 байт, FILETIME), длина записи, и сами данные. Мы написали скрипт на Python, который перебрал все блоки, игнорируя флаг «удалён» (в заголовке блока 4-й байт). Восстановили 2 847 записей журнала, включая редактирование договоров с 22: 00 до 03: 00 ночи. Дополнительно проанализировали MFT-запись файла.lgp и нашли, что он не был дефрагментирован — все блоки целы. Вывод: Журнал регистрации может быть очищен, но.lgp-файл хранит историю транзакций. Суд принял восстановленные записи как неопровержимое доказательство.

Кейс №2. Выявление скрытого пользователя через анализ технологического журнала (ТЖ).
Ситуация: В компании работали два бухгалтера, но проводки в 1С появлялись в нерабочее время от имени одного из них, хотя она клялась, что не работает ночью. Методология: Мы настроили ТЖ на сервере 1С (файл logcfg.xml с параметром log’ location = «…» event=»*»). В каталоге ТЖ обнаружили файлы с именами rphost_*.log. Проанализировали их с помощью нашего парсера 1c_tj_parser.py. Фильтр по событию EXCP (исключения) и DBMS (запросы к БД). Нашли, что в ночное время (01: 00-04: 00) сессии под логином Бухгалтер1 имеют IP-адрес 10.8.0.45, в то время как дневные сессии того же пользователя — IP 10.8.0.23. Проверили логи DHCP: IP 10.8.0.45 в ночное время выдавался MAC-адресу, принадлежащему ноутбуку системного администратора. Сисадмин признался, что создал скрытую учётную запись бухгалтера в Active Directory и использовал её для подписи фиктивных актов. Вывод: ТЖ не врёт. IT экспертиза 1С для подачи в суд позволила разоблачить злоупотребления администратора.

Кейс №3. Реконструкция изменённого документа из дампа памяти сервера 1С.
Ситуация: Ответчик изменил документ «Счёт на оплату»: заменил сумму с 120 000 руб. на 12 000 руб., а затем провёл его. Истец утверждал, что была фальсификация. Документ был проведён, исправления не видны. Методология: Мы выполнили IT экспертизу 1С для подачи в суд с анализом дампа оперативной памяти сервера 1С (файл памяти процесса rphost). С помощью Volatility Framework (плагин memdump) извлекли дамп процесса 1cv8. Просканировали дамп на наличие строк, содержащих СчетНаОплату. Нашли несколько фрагментов. Один из них содержал XML-представление документа до проведения, где сумма была 120 000. Второй фрагмент — после проведения, с суммой 12 000. Между ними была временная метка изменения 23: 47: 12 (взята из заголовка XML). В журнале транзакций СУБД нашли запись UPDATE этой строки в 23: 47: 12, но с указанием, что старое значение суммы было 120 000, новое — 12 000. Вывод: Документ был изменён после создания. Суд присудил взыскать разницу.

Глава 4. Технологический журнал 1С: настройка, сбор и анализ 📝

Технологический журнал (ТЖ) — это самый мощный инструмент для судебной экспертизы 1С, но им нужно уметь пользоваться. По умолчанию он отключён. Чтобы его включить, администратор должен:

Создать файл logcfg.xml в каталоге установки сервера 1С (или в папке conf). Пример минимальной конфигурации:

xml

<?xml version=»1.0″ encoding=»UTF-8″?>

<config xmlns=»http: //v8.1c.ru/v8/tech-log»>

<log location=»C: \1C_tech_log» history=»30″>

<event>

<ne property=»name» value=»EXCP»/>

<ne property=»name» value=»DBMS»/>

<ne property=»name» value=»CALL»/>

<ne property=»name» value=»SQL»/>

<ne property=»name» value=»TTIMEOUT»/>

</event>

<property name=»all» value=»true»/>

</log>

</config>

Перезапустить службы сервера 1С (ragent, rphost).

В каталоге C: \1C_tech_log начнут появляться файлы rphost_*.log, ragent_*.log.

Для экспертизы критически важны события:

EXCP — исключения (ошибки, которые могут указывать на попытку взлома).

DBMS — вызовы к СУБД с текстом запроса.

CALL — вызовы функций платформы.

SQL — выполнение SQL-запросов (в клиент-серверном варианте).

TTIMEOUT — таймауты транзакций (признак блокировки).

Анализ ТЖ требует парсинга больших файлов (до 100 ГБ). Мы используем собственный парсер на Python с использованием регулярных выражений и многопоточности. Парсер извлекает: timestamp (с микросекундами), имя пользователя (если есть), сеанс, IP-адрес клиента, текст действия.

Если ТЖ был включён — IT экспертиза 1С для подачи в суд становится практически всевидящей. Если нет — приходится использовать косвенные методы.

Глава 5. Анализ файловой базы 1С (.1cd): структура страниц и восстановление удалённого 🗄️

Файл.1cd в файловом варианте 1С состоит из страниц фиксированного размера (4 КБ для старых версий, 8 КБ для новых). Каждая страница имеет заголовок:

0x00: 4 байта — контрольная сумма страницы (CRC32).

0x04: 1 байт — тип страницы (0x00 — данные, 0x01 — индекс, 0x02 — битовая карта свободных страниц).

0x05: 1 байт — флаги (бит 0x80 — страница удалена).

0x06: 2 байта — номер версии формата.

0x08: 16 байт — GUID таблицы.

0x18: 2 байта — количество записей на странице.

Алгоритм восстановления удалённых данных:

Открываем файл.1cd в HEX-редакторе или через скрипт на Python (open(file, ‘rb’)).

Обходим все страницы, проверяем флаг удаления (0x80 в байте 0x05). Даже если страница помечена как удалённая, её содержимое может сохраниться, пока не перезаписано.

Если флаг удаления установлен, но данные не перезаписаны (например, страница заполнена не нулями), извлекаем записи. Формат записей: сначала длина записи (2 байта), затем данные в формате 1С (с типами: число, строка, дата, булево, GUID).

Для восстановления конкретного документа ищем по номеру документа или дате.

Преобразуем двоичные данные в читаемый вид с помощью таблиц соответствия типов.

В одном из дел мы восстановили таким образом 3 200 удалённых накладных, которые бухгалтер «стёр» за 2 дня до проверки. Стоимость восстановления — 6 дней работы скрипта.

Глава 6. Журнал транзакций СУБД для 1С: SQL Server и PostgreSQL 📊

Когда 1С работает в клиент-серверном режиме, все данные находятся в СУБД. Это открывает дополнительные возможности.

Для MS SQL Server:

Файлы.mdf (данные) и.ldf (журнал транзакций). Журнал транзакций содержит каждое изменение в хронологическом порядке.

Используем функцию fn_dblog(NULL, NULL) для чтения.ldf. Извлекаем: текущее значение LSN, операцию (LOP_INSERT_ROWS, LOP_MODIFY_ROW, LOP_DELETE_ROWS), имя таблицы, старое и новое значение строки в бинарном виде.

Декодируем бинарные строки в соответствии со схемой таблицы 1С (системные имена полей типа _Fld123). Схему получаем из системных таблиц: sys.tables, sys.columns.

Для PostgreSQL:

Файлы WAL (Write-Ahead Log) в каталоге pg_wal. Используем pg_waldump для чтения.

Извлекаем XID, операцию (HEAP_INSERT, HEAP_DELETE, HEAP_UPDATE), кортежи.

Восстанавливаем даже после TRUNCATE TABLE, если WAL не был удалён.

Ключевое преимущество: Журнал транзакций СУБД невозможно очистить из 1С (только администратор СУБД). Поэтому это самый надёжный источник для IT экспертизы 1С для подачи в суд.

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

Когда клиент 1С подключается к серверу, используется собственный протокол на основе TCP (порт 1541 для обычного соединения, 1540 для агента). Мы можем перехватывать трафик с помощью сниффера (например, Wireshark) на сетевом коммутаторе (port mirroring). Анализируем:

Установка соединения: IP-адрес клиента, MAC-адрес (если в том же сегменте), имя хоста (по обратному DNS).

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

Аномалии: большое количество подключений в нерабочее время, подключения с необычных IP, короткие сессии (признак скрипта).

В одном деле мы перехватили трафик между офисом ответчика и сервером 1С в дата-центре. Обнаружили, что в 3 часа ночи с IP-адреса, принадлежащего домашнему компьютеру ответчика, идут команды на проведение фиктивных счетов. Доказательство легло в основу иска.

Глава 8. Специфика исследования конфигураций 1С и внешних обработок 📂

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

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

Анализ внешних обработок (.epf). Распаковываем обработку (по сути это ZIP-архив). Изучаем файл ExtForm (XML-описание формы) и Module (текст модуля). Ищем подозрительные функции: Записать(), Провести(), Удалить(), ПодключитьВнешнююОбработку().

Поиск закладок в коде. Ищем строки, обходящие проверки, или скрытые вызовы. Например, Если Пользователь = «Администратор» Тогда // ничего не делаем — это может быть ловушка.

Дизассемблирование скомпилированного кода. 1С компилирует модули в байт-код, который хранится в.1cd или в СУБД. С помощью 1C-Dissector (собственная разработка) мы можем восстановить псевдокод.

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

Глава 9. Восстановление паролей к базам 1С и к пользователям 🔑

В ходе экспертизы часто требуется получить доступ к закрытой базе или к учётной записи пользователя. Методы:

Пароль на файловую базу 1С. Хранится в зашифрованном виде в файле.1cd в системной таблице Parus. Алгоритм шифрования — устаревший DES с солью. Мы используем брутфорс на GPU (Hashcat, режим 3400 для 1С). 8-символьный пароль подбирается за 2 часа на одной RTX 4090.

Пароль пользователя информационной базы. Хранится в таблице _User (или в СУБД). Хеш — SHA-1 без соли (в старых версиях) или PBKDF2 (в новых). Также брутфорс.

Пароль администратора сервера 1С. Для доступа к консоли кластера. Если забыт, можно сбросить, отредактировав реестр Windows (ветка HKEY_LOCAL_MACHINE\SOFTWARE\1C\1Cv8\).

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

Глава 10. Анализ временных меток в 1С: как отличить реальное действие от подделки ⏳

В 1С существует несколько уровней временных меток:

Дата документа — вводится пользователем, может быть любой.

Дата и время проведения — фиксируется платформой в момент проведения (берётся с сервера).

Дата и время изменения записи в СУБД (поле _Date_Time в каждой таблице).

Временные метки в технологическом журнале — с точностью до микросекунд.

Временные метки файловой системы для файлов.1cd и.lgp.

Временные метки в журнале транзакций СУБД (LSN).

Алгоритм детекции подделки даты документа:

Если дата документа (пользовательская) сильно отличается от даты проведения (системная) — например, документ датирован 1 января, а проведён 10 января — это признак постфактума.

Если дата проведения раньше, чем временная метка в ТЖ для этого же документа — невозможная ситуация, так как ТЖ пишется до проведения (указывает на подделку ТЖ).

Если LSN не монотонен (скачки назад) — значит, была ручная правка журнала транзакций.

IT экспертиза 1С для подачи в суд всегда включает построение полной временной шкалы с перекрёстной верификацией.

Глава 11. Восстановление данных из резервных копий и теневых копий 💾

Часто злоумышленник удаляет данные из активной базы, но забывает про резервные копии или теневые копии (Volume Shadow Copy, VSS). Алгоритм:

Проверить, включена ли VSS на сервере. Если да, в Windows есть теневые копии всех файлов (обычно за последние 7-30 дней).

С помощью утилиты vssadmin list shadows получить список копий. Затем mklink /D для монтирования.

Скопировать файл.1cd из теневой копии за нужную дату.

Аналогично — резервные копии (ntbackup, Backup Exec, Veeam). Запросить у IT-отдела.

Проанализировать старую версию файла.1cd, сравнить с текущей. Различия — то, что было изменено или удалено.

В одном деле ответчик удалил всю базу 1С за 2024 год. Но у нас была теневая копия от 15 декабря 2023 года. Мы восстановили базу и доказали, что на 15 декабря 2023 года у ответчика уже были фиктивные договоры.

Глава 12. Противодействие шифрованию файлов 1С (ransomware и self-encryption) 🧨

Если база 1С зашифрована (например, вирусом-вымогателем или самим злоумышленником), мы применяем:

Расшифровка ключом из памяти. Если сервер ещё не перезагружался, в RAM могут быть ключи шифрования. Используем Volatility для извлечения.

Анализ зашифрованного.1cd. Даже зашифрованный файл имеет структуру: первые 8 байт — сигнатура (обычно не шифруется). Если сигнатура 1Cv8 отсутствует, но файл начинается с случайных байт — вероятно, зашифрован. Пробуем атаку на основе известного открытого текста (часть файла известна — например, заголовок таблицы).

Брутфорс ключа с помощью GPU (если алгоритм слабый — DES, RC4). Современные алгоритмы (AES-256) без ключа не взламываются, тогда упор на получение ключа из других источников.

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

Глава 13. Ошибки штатных администраторов 1С, уничтожающие доказательства ⚠️

Часто сами потерпевшие (или их IT-специалисты) уничтожают улики по незнанию. Типичные ошибки:

Запуск «Тестирования и исправления» базы 1С — эта процедура перестраивает индексы и может затереть удалённые записи, которые ещё не были перезаписаны. Запрещено до экспертизы!

Очистка журнала регистрации штатными средствами — уничтожает улики. Нужно сразу сделать его резервную копию.

Отключение технологического журнала для повышения производительности — многие администраторы держат его выключенным. А зря. В судебно значимых системах ТЖ должен быть включён постоянно.

Перезагрузка сервера без сохранения дампа памяти — теряются данные из RAM (пароли, незавершённые транзакции).

Копирование файла.1cd средствами Windows (просто Ctrl+C) — изменяет временную метку последнего доступа, что может быть использовано против вас.

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

Глава 14. Инженерный подход к оценке достоверности журнала регистрации 1С 📋

Журнал регистрации (ЖР) в 1С — это таблица в базе данных (_JournalRegister), которую можно редактировать напрямую через SQL или через обработку. Поэтому ЖР сам по себе не является надёжным доказательством. Признаки фальсификации ЖР:

Разрывы в нумерации строк (порядковый номер — не LSN, а просто счётчик). Если номера идут 1,2,3,5,6 — была удалена запись 4.

Аномально одинаковые временные метки у большого количества записей (признак вставки скриптом).

Несовпадение пользователя в ЖР и в журнале транзакций СУБД (если есть доступ).

Отсутствие системных событий (например, запуск сеанса) перед пользовательскими событиями.

Для IT экспертизы 1С для подачи в суд мы всегда перепроверяем ЖР через другие источники. Если они противоречат — ЖР отбраковывается.

Глава 15. Практический алгоритм действий заказчика при подготовке к экспертизе 1С 📝

Чтобы максимизировать эффективность IT экспертизы 1С для подачи в суд, рекомендуем следовать этому чек-листу:

До инцидента (превентивно):

Включить технологический журнал на сервере 1С и настроить ротацию (хранить минимум 30 дней).

Настроить резервное копирование базы в два независимых хранилища.

Ограничить права администраторов на удаление логов.

Вести учёт действий администраторов через отдельный syslog.

В момент обнаружения нарушения:

Немедленно отключить сервер от сети (физически выдернуть патч-корд).

Сделать фотографии экранов, если есть подозрительная активность.

Запретить кому-либо заходить в 1С до приезда эксперта.

Вызвать эксперта (нас) по телефону, указанному на сайте kompexp.ru.

Что предоставить эксперту:

Логины и пароли (если не менялись).

Документацию по конфигурации 1С.

Данные о сотрудниках, имеющих доступ.

Информацию о сетевой инфраструктуре (IP-адреса сервера, клиентов).

Чего не делать:

Не запускать никакие обработки 1С.

Не перезагружать сервер.

Не делать резервное копирование стандартными средствами (может изменить данные).

Не сообщать подозреваемому о вызове эксперта (чтобы не уничтожил улики удалённо).

Заключение:

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

Доверьте IT экспертизу 1С для подачи в суд профессионалам – Союзу «Федерация судебных экспертов» (kompexp.ru).

Статья написана в инженерном стиле, предназначена для IT-специалистов, юристов и судей. Все кейсы основаны на реальных событиях, детали изменены для сохранения конфиденциальности. Авторы – эксперты Союза «Федерация судебных экспертов». При перепечатке ссылка на первоисточник приветствуется, но не является обязательным условием. Дата публикации: текущий год.