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

1. Техническое введение: программный код как объект экспертизы

В современной судебной и арбитражной практике всё чаще возникают споры, объектом которых является программное обеспечение. 🔧 Для разрешения таких споров требуется специальное знание — техническая экспертиза программ для ЭВМ. Данный вид экспертизы представляет собой совокупность инструментальных и аналитических методов, направленных на установление фактических данных о свойствах, происхождении, структуре и функциональности программного кода. В настоящей статье мы рассмотрим техническую сторону вопроса: от низкоуровневого анализа бинарных файлов до построения формальных верификационных моделей.

2. Архитектура экспертного исследования: уровни абстракции

Техническая экспертиза программ для ЭВМ оперирует на нескольких уровнях абстракции программного продукта:

Уровень исходного кода (Source Code Level) — анализ текстов программ на языках высокого уровня (C, C++, Java, Python, C#, Go, Rust и других). 🟦

Уровень промежуточного представления (Intermediate Representation Level) — работа с байт-кодом (Java bytecode, CIL для.NET, LLVM IR) и абстрактным синтаксическим деревом (AST). 🟩

Уровень ассемблерного кода (Assembly Level) — дизассемблирование машинного кода в мнемоники (x86/x64, ARM, MIPS, RISC-V). 🟪

Уровень машинных инструкций (Machine Code Level) — анализ непосредственно опкодов и их последовательностей без восстановления ассемблера. ⬛

Каждый уровень требует своих инструментов и методик, а выбор уровня определяется поставленными вопросами и доступностью исходных материалов.

3. Инструментарий технического эксперта: обзор средств

Для проведения качественной экспертизы программ для ЭВМ применяется следующий типовой набор программно-аппаратных средств:

Дизассемблеры и декомпиляторы:

• IDA Pro (Interactive Disassembler) — промышленный стандарт для анализа исполняемых файлов. 🛠️
• Ghidra — открытая платформа от АНБ США с возможностью декомпиляции на C.
• Radare2 — консольный фреймворк для автоматизации анализа.
• dnSpy / ILSpy — для.NET-сборок (C#/NET).
• JD-GUI / CFR — для Java-байткода.

Средства сравнения кода:

• Diff-утилиты (Beyond Compare, WinMerge, Meld).
• Плагиат-детекторы (MOSS, JPlag, Sherlock).
• Собственные скрипты нормализации кода (удаление комментариев, форматирование).

4. Статический анализ: техническая спецификация

Статический анализ — базовый метод экспертизы программ для ЭВМ, не требующий запуска исследуемого ПО. Технически он включает:

• Лексический анализ — выделение токенов (ключевые слова, идентификаторы, операторы, литералы). 📝
• Синтаксический анализ — построение AST (Abstract Syntax Tree) для структурного сравнения.
• Семантический анализ — построение CFG (Control Flow Graph) и DFG (Data Flow Graph).
• Метрический анализ — вычисление метрик сложности (цикломатическая сложность Маккейба, глубина вложенности, количество точек входа/выхода).

Сравнение на уровне AST значительно устойчивее к переименованию переменных и перестановке строк, чем текстовое сравнение.

5. Динамический анализ: технические протоколы

Когда исходный код недоступен или вызывает сомнения, применяется динамический анализ в рамках экспертизы программ для ЭВМ. 🔄 Процесс включает:

• Запуск ПО в изолированной среде (виртуальная машина или контейнер без сетевого доступа). 🖥️
• Мониторинг системных вызовов (через strace/Linux, API Monitor/Windows).
• Анализ работы с реестром, файловой системой, процессами.
• Перехват и анализ сетевого трафика (Wireshark, tcpdump).
• Трассировка вызовов библиотек (LD_PRELOAD, Detours).

Динамический анализ позволяет выявить скрытый функционал (шпионские модули, бэкдоры, майнеры) и задокументировать реальное поведение программы.

6. Кейс №1: Сравнение реализации алгоритма сжатия LZ77

В арбитражный суд поступило дело о нарушении патента на алгоритм сжатия данных. 🗜️ Исходный код ответчика был предоставлен, но с утверждением, что он написан с нуля. Техническая экспертиза программ для ЭВМ включала: построение AST для функции сжатия, сравнение CFG (графов потоков управления) и анализ критических участков (скользящее окно, кодирование длин серий). Выявлено совпадение 94% CFG и идентичная обработка граничного условия (overflow буфера). Эксперт дал заключение о заимствовании с высокой степенью уверенности. Суд удовлетворил иск. ⚖️

7. Реверс-инжиниринг: технические методы

Обратная разработка (reverse engineering) применяется, когда исходный код полностью отсутствует. В рамках экспертизы программ для ЭВМ реверс-инжиниринг включает:

• Дизассемблирование — преобразование машинного кода в ассемблер. 🔬
• Декомпиляция — восстановление псевдокода высокого уровня (Hex-Rays для IDA, декомпилятор Ghidra).
• Распознавание структур — идентификация стандартных алгоритмов (сортировки, хеширования, шифрования) по сигнатурам.
• Восстановление вызовов API — анализ импортов и динамической загрузки библиотек.

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

8. Кейс №2: Восстановление логики пропавшего модуля промышленного ЧПУ

На одном из машиностроительных заводов (г. Саратов) вышел из строя станок с ЧПУ. 🔧 Исходники управляющей программы были утеряны, остался лишь зашифрованный образ прошивки. Специалист по экспертизе программ для ЭВМ провёл: идентификацию криптографического алгоритма (оказался AES-128 с фиксированным ключом, найденным в EEPROM), расшифровку образа, дизассемблирование под архитектуру ARM Cortex-M3, восстановление основных циклов и таблиц интерполяции. На основе восстановленной логики завод смог модернизировать станок без покупки нового ПО. Экономия — более 8 млн рублей. 💰

9. Анализ обфусцированного кода: технические приёмы

Обфускация (запутывание кода) часто применяется для сокрытия истинных алгоритмов. Техническая экспертиза программ для ЭВМ в таких случаях требует специальных подходов:

• Статистический анализ энтропии — выявление упаковщиков и шифрованных секций. 📈
• Распаковка на лету — запуск в отладчике до точки входа (OEP), дамп памяти после распаковки.
• Деобфускация.NET — использование инструментов de4dot, ConfuserEx Unpacker.
• Символьное выполнение — восстановление условий переходов при помощи angr или Triton.
• Динамическая инструментация — подмена инструкций через Pin или DynamoRIO.

Средняя трудоёмкость деобфускации — от 20 до 80 человеко-часов в зависимости от сложности.

10. Кейс №3: Обнаружение скрытого майнера в системной утилите

Крупный системный интегратор обнаружил, что серверное ПО потребляет аномально много CPU. 🖥️ Подозрение пало на обновление одной из утилит. Техническая экспертиза программ для ЭВМ показала: исполняемый файл был упакован UPX (обнаружено сигнатурой), после распаковки в IDA найден вызов функции Cryptonight_hash (алгоритм майнинга Monero). Динамический анализ подтвердил подключение к пулу по IP-адресу 185.xxx.xxx.xxx. Экспертиза помогла инициировать уголовное дело по ст. 272 УК РФ. 🦠

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

Поскольку квалифицированная экспертиза программ для ЭВМ в регионах РФ является редкостью (отсутствие специалистов в 80% субъектов), наша лаборатория организует выездные технические исследования. 🚗 Состав выездной группы:

Инженер по реверс-инжинирингу (работа с бинарными файлами).

Техник-криминалист (создание образов дисков, write-blocker).

Инженер по динамическому анализу (песочницы, трассировка).

Оборудование кейса:

• Ноутбуки с предустановленными IDA Pro, Ghidra, Python-скриптами. 💻
• Write-blocker Tableau (3 интерфейса: SATA, USB, PCIe).
• Док-станции для NVMe-накопителей.
• Защищённый внешний SSD на 4 ТБ для хранения образов.
• Аппаратный генератор случайных чисел для подписей.
• Источник бесперебойного питания на 8 часов.

Выезд возможен в любой регион России — от Крыма до Камчатки, от Калининграда до Сахалина. ✈️ Срок прибытия: 48–72 часа после получения процессуального документа.

12. Этапы выездной экспертизы: технический протокол

Процесс выездной технической экспертизы программ для ЭВМ строго регламентирован:

• Приём материалов — проверка целостности упаковки, фиксация дефектов. 📦
• Создание образов — побитовое копирование (dd, FTK Imager) с контролем хешей SHA-256 (выводятся в протокол).
• Изоляция — отключение всех сетевых интерфейсов на оборудовании эксперта.
• Первичный анализ — сканирование сигнатур (TrID, Detect-It-Easy).
• Статический анализ — загрузка в IDA/Ghidra, построение графов.
• Динамический анализ (при необходимости) — запуск в песочнице Cuckoo.
• Сравнительный анализ — при наличии эталонных образцов.
• Формирование заключения — печать, подпись, приложения (скриншоты, хеши, листинги).
• Передача результата — заказчику или в суд с актом приёма-передачи. 📑

Каждый этап документируется с точностью до минуты.

13. Типовые технические вопросы эксперту

В рамках экспертизы программ для ЭВМ суды и стороны чаще всего запрашивают ответы на следующие технические вопросы:

• Имеются ли в исследуемом коде фрагменты, идентичные или производные от кода, представленного в качестве образца? 🔍
• Содержит ли исполняемый модуль функции, не заявленные в документации (недокументированные возможности)?
• Возможно ли восстановить удалённый или перезаписанный исходный код из объектных файлов?
• Каков алгоритм работы функции X (восстановление по бинарному коду)?
• Идентичны ли алгоритмы сжатия/шифрования/обработки в двух разных программах с технической точки зрения?
• Использовались ли при создании программы открытые библиотеки с лицензиями, обязывающими раскрывать исходный код (GPL, LGPL)?

Формулировка вопросов должна быть технически корректной, избегая правовых оценок («нарушены ли права» — это к суду).

14. Технические критерии эквивалентности кода

Для решения вопроса о заимствовании эксперты используют несколько критериев технической эквивалентности:

• Полное текстовое совпадение (с учётом нормализации пробелов и комментариев) — редко, но встречается при копипасте. 📄
• Совпадение AST (структуры синтаксического дерева) — более надёжно.
• Совпадение CFG (графа потоков управления) — особенно ценно для алгоритмов.
• Совпадение уникальных констант (магические числа, строки ошибок, значения по умолчанию).
• Совпадение порядка вызовов API (последовательность WinAPI/Linux syscalls).
• Совпадение структуры исключений (обработка ошибок, try-catch блоки).

Комбинация 3 и более независимых признаков считается достаточной для вывода о заимствовании.

15. Кейс №4: Техническая экспертиза драйвера ядра Windows

В одном из дел о промышленном шпионаже фигурировал драйвер для перехвата трафика (kernel-mode driver). 🧠 Техническая экспертиза программ для ЭВМ включала: загрузка.sys-файла в IDA, восстановление SSDT-хуков, анализ IRP-диспетчеров. Обнаружено, что таблица мажорных функций совпадает с эталонной на 100% (включая порядок). Дополнительно найдены одинаковые неэкспортированные строки отладки (DBG_PRINT). Эксперт дал заключение о полном копировании драйвера с изменением только названий некоторых переменных. Суд присудил компенсацию 12 млн рублей. 💼

16. Статистические методы в экспертизе ПО

Продвинутая экспертиза программ для ЭВМ применяет машинное обучение и статистику:

Анализ стиля кода — распределение длин идентификаторов, частота использования определённых конструкций (тернарные операторы, ранние return). Сравнение с эталоном через метрику Колмогорова-Смирнова.

Байесовская классификация плагиата — на основе обучающей выборки известных заимствований.

Алгоритм Winnowing — выделение отпечатков строк (fingerprinting) с устойчивостью к мелким правкам.

Анализ энтропии бинарного кода — выявление вставок сжатых/зашифрованных данных.

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

17. Кейс №5: Спор о лицензии GPL в открытом проекте

Разработчик использовал библиотеку под GPL в коммерческом продукте без открытия исходных кодов. 📖 Истец потребовал раскрытия кода. Техническая экспертиза программ для ЭВМ должна была установить факт использования GPL-кода. Эксперт: дезассемблировал продукт, нашёл функции с сигнатурами, полностью совпадающими с функциями GPL-библиотеки (сравнение по контрольным суммам и CFG), проверил наличие статической линковки (обнаружены таблицы импорта). Вывод: использование GPL-кода доказано. Суд обязал разработчика опубликовать исходники под GPL или выплатить компенсацию. ⚖️

18. Техническая документация заключения: требования к формату

Итоговое заключение технической экспертизы программ для ЭВМ должно содержать:

• Титульный лист (наименование экспертной организации, номер дела, дата). 📃
• Вводную часть (основание, вопросы, материалы, предупреждение об ответственности).
• Исследовательскую часть (методики, описание этапов, результаты, скриншоты с подписями).
• Синтез и выводы (прямые и чёткие ответы на каждый вопрос).
• Приложения (распечатки кода, хеш-суммы, графики CFG, листинги ассемблера).
• Электронный носитель (CD/DVD или флешка со всеми материалами в PDF и исходном виде).

Каждый факт, на который ссылается эксперт, должен иметь подтверждение в приложении (скриншот, вывод команды, таблица).

19. Факторы, влияющие на длительность технической экспертизы

Продолжительность экспертизы программ для ЭВМ зависит от следующих технических факторов:

• Объём кода (количество строк, функций, модулей) — экспоненциально влияет на время. 📊
• Наличие и качество исходников (исходники быстрее, объектники — медленнее, только бинарники — очень медленно).
• Сложность алгоритмов (криптография, машинное обучение требуют дополнительного математического анализа).
• Степень обфускации/упаковки (распаковка может занять дни).
• Количество сравниваемых образцов (при сравнении с 10 эталонами время растёт).
• Необходимость выезда в регион (+ транспортное плечо).
• Загруженность эксперта (реальная практика — параллельные дела).

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

20. Мобильная экспертная лаборатория: технические характеристики

Для выездной работы наша организация использует специальный кейс-лабораторию (защищённый Pelican 1650), содержащий:

• Основной ноутбук (Lenovo ThinkPad P17, 128 ГБ RAM, 8 ТБ NVMe, NVIDIA RTX A5000). 💼
• Резервный ноутбук (Dell XPS 15, для полевой документации).
• Write-blocker Tableau Forensic T8-R2 (поддержка SATA, USB 3.2, m.2 NVMe). 🔌
• Док-станция для накопителей (с возможностью горячей замены).
• Аппаратный криптошлюз для шифрования образов (AES-256 XTS).
• Комплект переходников (IDE-to-USB, адаптеры для eMMC, картридеры для флеш-памяти).
• Источник питания (Anker PowerHouse 757, ёмкость 1,2 кВт*ч).
• Фотокамера для фиксации процесса.

Всё оборудование откалибровано и имеет действующие свидетельства о поверке (для судебной допустимости). 🛠️

21. Технические риски и их минимизация

При проведении экспертизы программ для ЭВМ возможны следующие технические риски:

Мы страхуем каждый случай профессиональной ответственностью.

22. Сравнение технической экспертизы с формальной верификацией

Не следует путать экспертизу программ для ЭВМ с формальной верификацией (метод из теории программирования, доказывающий корректность ПО математически). Отличия:

• Формальная верификация требует полной спецификации и моделей — это дорого и редко применяется в судах. 🧮
• Техническая экспертиза — практический инструмент, работающий с реальным кодом (в том числе с багами, побочными эффектами).
• Экспертиза может применять методы верификации (например, model checking для фрагментов), но не ограничивается ими.

23. Будущее технической экспертизы: автоматизация и нейросети

Технический прогресс влияет и на экспертизу программ для ЭВМ. Уже сейчас разрабатываются:

• Нейросетевые детекторы плагиата кода (Graph Neural Networks на AST) — точность до 98%. 🧠
• Автоматические рекомпиляторы для восстановления исходного кода из байткода с использованием LLM.
• Модели для деобфускации на основе трансформеров (известны экспериментальные работы).
• Динамические символьные исполнители нового поколения (Triton, angr с подключаемыми SMT-решателями).

Однако полная автоматизация невозможна из-за необходимости дачи показаний в суде и интерпретации результатов в юридическом контексте.

24. Технические требования к хранению вещественных доказательств

После завершения экспертизы программ для ЭВМ вещественные доказательства (диски, флешки, образы) должны храниться в условиях, исключающих изменение:

• Температура: +15..+25 °C. 🌡️
• Влажность: 30-50% (без конденсата). 💧
• Защита от магнитных полей: экранированная упаковка.
• Контроль доступа: сейф или опечатанная комната.
• Срок хранения: до истечения срока обжалования решения суда (обычно 1 год, далее по определению).

Нарушение режима хранения делает доказательства недопустимыми (ст. 75 УПК РФ).

25. Техническое резюме и приглашение к сотрудничеству

Подводя технический итог, подчеркнём ключевые положения:

• Экспертиза программ для ЭВМ— это многоуровневый инженерный процесс, требующий глубокого знания компиляторов, архитектур процессоров, алгоритмов и инструментов анализа. 🏗️
• Из-за крайней редкости таких специалистов в регионах России (отсутствие в 80% субъектов) наша лаборатория организует выезд в любой регион в течение 48-72 часов с полным набором оборудования. 🚗
• Мы применяем формальные методики статического, динамического, символьного анализа и реверс-инжиниринга с обязательной документацией каждого шага.
• Заключения принимаются судами всех уровней и могут быть положены в основу приговора или решения.

Более подробные технические спецификации, примеры заключений и формы документов:
https://sud-expertiza.ru/ekspertiza-programm-dlya-elektronnyh-vychislitelnyh-mashin-evm/

🟩 Техническая экспертиза — последний бастион объективности в цифровом споре. Доверьтесь инженерам, которые читают код как открытую книгу.