Введение: инженерный взгляд на проблему

🔧 Уважаемые коллеги — инженеры, разработчики, технические специалисты и судебные эксперты! В отличие от гуманитарных или юридических описаний, данная статья написана с позиции практикующего инженера-программиста, специализирующегося на низкоуровневом анализе, реверс-инжиниринге и исследовании сложных вычислительных систем. 📐 Экспертиза программ для ЭВМ с инженерной точки зрения — это процесс, включающий аппаратный и программный анализ, метрологический контроль, применение формальных методов верификации и количественных метрик. 🛠️ Мы рассмотрим реальные технические кейсы, схемы, алгоритмы действий и нюансы, о которых молчат учебники. Поехали.

Раздел 1. Инженерное определение объекта экспертизы

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

• бинарные исполняемые файлы (PE, ELF, Mach-O, файлы прошивок);
• объектные модули (.obj,.o) и библиотеки (.lib,.a,.so,.dll);
• исходные тексты на языках высокого уровня;
• промежуточное представление (LLVM IR, Java bytecode,.NET CIL);
• скрипты и макросы (PowerShell, VBA, JavaScript, Lua);
• конфигурационные файлы, определяющие логику (XML, JSON, YAML, DSL).
  Каждый тип требует собственного инструментария и методологии. ⚙️

Раздел 2. Технические средства и инструментарий эксперта

🧰 Инженерная лаборатория эксперта включает:

Аппаратное обеспечение: рабочие станции с многопроцессорностью (от 32 ГБ ОЗУ), аппаратные отладчики (JTAG-адаптеры, логические анализаторы), программаторы ПЗУ, устройства для создания образов дисков (Tableau, Atola).

Программное обеспечение: дизассемблеры (IDA Pro, Ghidra, Binary Ninja, Radare2), отладчики (x64dbg, WinDbg, GDB, LLDB), декомпиляторы (Hex-Rays, Ghidra decompiler, dnSpy, JD-GUI), статические анализаторы (SonarQube, PVS-Studio), снифферы трафика (Wireshark, tcpdump, mitmproxy), средства для работы с дампами памяти (Volatility, Rekall).

Средства метрологии: хеш-калькуляторы (SHA-256, SHA-3, BLAKE2) для обеспечения неизменности объектов.
Все инструменты должны быть лицензионными, с задокументированными версиями. 📀

Раздел 3. Кейс №1: Инженерный анализ плагиата через метрики Холстеда и Маккейба

👨‍💻 Задача: две программы на C++ для управления промышленным роботом. Истец утверждает, что ответчик скопировал алгоритмы траекторного планирования. Исходный код предоставлен обеими сторонами.
⚙️ Методика: Эксперт (я) выполнил:

Нормализацию кода (удаление комментариев, стандартизация отступов).

Вычисление метрик Холстеда для каждого модуля:

• n1 (уникальные операторы), n2 (уникальные операнды);
• N1 (общее число операторов), N2 (общее число операндов);
• Объем программы V = N * log2(n), где N = N1+N2, n = n1+n2.
• Уровень программы L = (2 * n2) / (N1 * n1).

Вычисление цикломатической сложности Маккейба: M = E — N + 2P (E — количество ребер графа потока управления, N — узлов, P — компонент связности).
📊 Результат: Для модуля планирования сплайнов у истца: V = 1874 бит, M = 58; у ответчика: V = 1812 бит (разница 3.3%), M = 56 (разница 3.4%). Коэффициент корреляции Пирсона между последовательностями инструкций составил 0.96. Это технически доказывает производность кода. Суд принял заключение. 📈

Раздел 4. Кейс №2: Выявление недекларированной функции с помощью трассировки системных вызовов

🔍 Ситуация: В закрытом медицинском ПО для хранения карт пациентов обнаружена утечка данных. Исходный код отсутствует, только исполняемый файл. Задача: определить, передает ли программа данные на внешние серверы.
🛠️ Инженерные действия:

• Развернул ПО на изолированной виртуальной машине (Windows 10 LTSC) без выхода в интернет, но с эмуляцией DNS через локальный сервер.
• Запустил Process Monitor с фильтрацией событий TCP/UDP, WriteFile, RegSetValue.
• Дополнительно использовал API Monitor для перехвата вызовов WinSock (send, recv, connect, WSASend).
• Обратил внимание на подозрительную библиотеку «crypt_net.dll», которая не входила в официальную документацию.
• Провел дизассемблирование этой DLL: обнаружил вызов InternetOpenUrlA с параметром «https://med-data-collector.ru/upload«.
  📡 Вывод: Программа содержит модуль, отправляющий на удаленный сервер обезличенные (но реальные) данные ЭКГ. Экспертиза легла в основу уголовного дела. 🔐

Раздел 5. Кейс №3: Нагрузочное тестирование и профилирование для оценки соответствия ТЗ

🏭 Контекст: Госконтракт на разработку системы мониторинга 5000 датчиков промышленного оборудования. Исполнитель сдал ПО, но заказчик жалуется на зависания при >500 датчиках.
🧪 Инженерная процедура:

• Собрал стенд: 3 сервера (CPU 8 ядер, 32 ГБ ОЗУ), эмуляторы датчиков на Python (каждый генерирует трафик Modbus/TCP).
• Настроил нагрузочное тестирование с помощью Apache JMeter: сценарии с 1000, 2000, 3000, 5000 одновременных датчиков.
• Провел профилирование памяти и CPU с помощью Visual Studio Diagnostic Tools и Intel VTune Profiler.
• Анализ показал: при >800 датчиках происходит активный garbage collection в.NET (приложение на C#) с паузами до 5 секунд. В исходном коде обнаружил, что разработчик использовал блокирующую коллекцию (BlockingCollection<T>) без ограничения емкости, что вызывало утечку памяти.
  📉 Заключение: ПО не соответствует ТЗ по производительности, дефект носит архитектурный характер. Суд расторг контракт. 📄

Раздел 6. Инженерная схема взаимодействия с судом и сторонами

📋 Для эффективной работы эксперта-инженера необходимо:

• Получение определения суда с точным перечнем вопросов и объектов.
• Запрос технических материалов: исходные коды (при наличии), документацию (схемы БД, описание API), доступ к среде исполнения (логи, дампы).
• Проведение входного контроля объектов: вычисление хешей, проверка целостности, составление акта осмотра.
• Выбор методики в зависимости от вопросов (статический/динамический анализ, нагрузочное тестирование, обратная разработка).
• Проведение эксперимента (с записью всех действий в лабораторном журнале).
• Оформление заключения с количественными показателями, таблицами, графиками, схемами алгоритмов.
• Участие в судебных заседаниях для дачи пояснений (часто требуется демонстрация работы программы на проекторе). 🖥️

Раздел 7. Типы исследований: статический анализ исходного кода

🔬 Статический анализ — исследование без запуска. Инженерный процесс:

L отчета с цветовой индикацией (красный — подозрительные участки, зеленый — соответствующие эталону).
Статический анализ эффективен, когда доступен полный исходный код. 🟩

Раздел 8. Типы исследований: динамический анализ и отладка

🐞 Динамический анализ — исследование в процессе исполнения. Этапы:

• Подготовка изолированной среды (виртуальная машина с восстановлением до «чистого» состояния после каждого запуска).
• Установка точек останова (breakpoints) на критических функциях: CreateFile, WriteFile, RegSetValue, connect, send, socket.
• Трассировка исполнения по шагам с записью регистров и стека.
• Анализ дампов памяти (core dumps) с помощью Volatility: извлечение строк, сетевых соединений, открытых дескрипторов.
• Сравнение поведения с эталонным образцом (если есть).
  Динамический анализ незаменим, когда исходный код отсутствует или когда нужно проверить поведение в реальном времени. ⏱️

Раздел 9. Сравнительный анализ бинарных файлов (биндиффинг)

📊 Биндиффинг — метод сравнения двух исполняемых файлов для выявления заимствований. Инженерный алгоритм:

• Загрузить оба файла в IDA Pro, выполнить автоанализ (создать функции, определить сигнатуры библиотек).
• Экспортировать базы данных IDB в формат, совместимый с BinDiff.
• Запустить BinDiff: алгоритм сопоставляет функции по графам потока управления (CFG) и вычисляет коэффициент сходства.
• Вручную проверить функции с высоким процентом совпадения (>85%).
• Обратить внимание на «редкие» константы и строки, которые не могут быть случайно одинаковыми.
• Оформить таблицу сравнения с указанием адресов в коде.
  Этот метод позволяет доказывать плагиат даже без исходного кода. 🧬

Раздел 10. Метрики и количественные критерии, используемые в выводах

📐 Инженерное заключение оперирует числами:

• Коэффициент подобия строк кода (строка считается совпадающей, если различается не более чем 2 символа после нормализации): порог >40% для нетривиального кода.
• Совпадение AST-узлов по Жаккару: >0.7 — сильное сходство.
• Показатель энтропии Шеннона: если код скопирован, энтропия распределения токенов будет близкой (разница <10%).
• Цикломатическая сложность Маккейба: расхождение >30% указывает на разные архитектуры; совпадение с точностью до 5% — на копирование.
• Число идентичных ошибок (common bugs): если баг повторяется в одном и том же месте — это практически стопроцентное доказательство заимствования.
  Все эти метрики я привожу в приложении к заключению. 📈

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

🗺️ По данным на 2026 год, в России насчитывается менее 100 инженеров, способных провести полную экспертизу программ для ЭВМ с использованием всех перечисленных методов, при этом имеющих судебную практику и аттестацию. 📉 В Москве и Санкт-Петербурге сосредоточено около 80% таких специалистов. 💡 Именно поэтому мы готовы вылетать для проведения данной экспертизы в любой регион России — от Калининграда до Камчатки, от Архангельска до Махачкалы. ✈️ Выезд необходим для:

• осмотра и клонирования жестких дисков с программным обеспечением на месте изъятия (следственные действия);
• исследования встроенного ПО промышленных контроллеров, которое невозможно вывезти;
• проведения экспериментов на оборудовании заказчика без передачи данных по сети.
  Технология выезда: мобильная лаборатория (ноутбук с лицензионным ПО, внешние накопители, криминалистические клонеры). 🧳

Раздел 12. Процесс выездной экспертизы: инженерный регламент

📅 При выезде в регион я следую регламенту:

• За 3 рабочих дня получаю копию определения суда и согласовываю время доступа с ответственным лицом (следователь, судья, представитель организации).
• Прибываю на место с мобильным кейсом: ноутбук (не менее 32 ГБ ОЗУ, SSD 1 ТБ), внешние диски (для копирования), write-blocker (аппаратный блокиратор записи для работы с подозрительными накопителями), хеш-калькулятор.
• В присутствии понятых (или сторон) фиксирую состояние ЭВМ: операционная система, дата/время, установленное ПО, открытые соединения.
• Производу копирование объектов с вычислением хешей SHA-256 (два файла: оригинал и копия, хеши сверяются).
• При необходимости произвожу осмотр работающей программы: запускаю, фиксирую поведение (через экранную запись).
• Составляю акт осмотра, который подписывается всеми участниками.
• Возвращаюсь в лабораторию для углубленного анализа. Все действия записываются в журнал. 📝

Раздел 13. Техническая документация, которую я запрашиваю

📑 Для полноценного анализа мне необходимы:

• Техническое задание (ТЗ) — точное описание требований к ПО.
• Спецификация API (если программа взаимодействует с другими системами).
• Схема базы данных (ER-диаграмма, описание таблиц и связей).
• Архитектурная документация (диаграммы компонентов, классов, последовательностей).
• Руководства администратора и пользователя.
• Исходные коды (в виде архива или ссылки на Git-репозиторий с фиксированным коммитом).
• Логи сборки (build logs) для определения версий компиляторов и флагов оптимизации.
  Без этих материалов эксперт может дать лишь ограниченные выводы. 📚

Раздел 14. Ошибки, которые я вижу в ходатайствах юристов

❌ Наиболее частые технические ошибки при назначении:

• Нет хеш-сумм файлов — после изъятия нельзя доказать, что файлы не менялись.
• Вопросы с правовыми терминами («нарушены ли авторские права?») — эксперт не юрист.
• Не указана версия программы (например, «программа 1С» без номера релиза) — можно исследовать не ту версию.
• Нет эталона для сравнения — если нет образца «оригинальной» программы, сравнение провести нельзя.
• Слишком короткие сроки (например, 5 дней на анализ миллиона строк кода) — физически невозможно.
  Рекомендую консультироваться с экспертом до подачи ходатайства. 🔧

Раздел 15. Экспертиза прошивок (firmware) встраиваемых систем

🔌 Встраиваемые системы (медицинское оборудование, автомобильные блоки управления, станки ЧПУ) содержат прошивки в ПЗУ. Инженерный процесс:

• Извлечение прошивки через программатор (CH341A, TL866, или JTAG/SWD-отладчик).
• Получение дампа памяти в виде HEX-файла.
• Определение архитектуры процессора (ARM, AVR, MIPS, x86, RISC-V) по вектору сброса и таблице прерываний.
• Дизассемблирование прошивки в IDA Pro с выбором соответствующей архитектуры.
• Поиск строковых констант, таблиц векторов, криптографических ключей.
• Анализ алгоритмов (например, проверки подлинности, протокола обмена с внешними устройствами).
  В одном из кейсов я обнаружил в прошивке газоанализатора «кнопку» (последовательность Modbus-команд), отключающую звуковую сигнализацию превышения ПДК — это было критично для уголовного дела о фальсификации показаний. ⚠️

Раздел 16. Экспертиза смарт-контрактов и блокчейн-приложений

⛓️ Новое направление: смарт-контракты на блокчейнах Ethereum, Solana, BSC. Экспертиза программ для ЭВМ здесь включает:

• Декомпиляцию байт-кода смарт-контракта (например, в онлайн-декодере Etherscan или через инструменты типа Panoramix).
• Анализ логики на предмет уязвимостей (reentrancy, integer overflow, timestamp dependence).
• Сравнение исходного кода (если предоставлен) с развернутым байт-кодом на предмет соответствия.
• Восстановление потока средств (flow of funds) по транзакциям.
• Доказательство наличия «черного хода» (backdoor) — функции, доступной только разработчику.
  Пример: в споре о крипто-инвестиционном фонде смарт-контракт имел функцию «withdrawTo(address)», не описанную в документации. Экспертиза подтвердила наличие недекларированной возможности. 📉

Раздел 17. Инженерный расчет стоимости разработки как часть экспертизы

💰 При спорах о компенсации необходимо определить стоимость создания аналогичного ПО. Я использую:

Метод трудозатрат: количество строк кода (SLOC, Logical SLOC) × норматив времени на строку (например, 0.5 человеко-часа на строку для сложного алгоритмического кода). Корректировка на сложность (метрика Холстеда).

Метод COCOMO II (Constructive Cost Model): учитывает размер кода, требуемую надежность, сложность продукта, опыт команды.

Сравнительный метод: анализ рыночных цен на аналогичное ПО (например, корпоративные CRM, ERP, SCADA-системы).

Анализ фактических затрат (если доступны данные о зарплатах разработчиков и времени разработки).
Результат — диапазон стоимости (например, от 5 до 8 млн рублей) — суд использует для определения размера взыскания. 📊

Раздел 18. Технические средства для обеспечения целостности объектов (хеширование)

🔒 Контроль неизменности — критически важен. Алгоритм:

• Для каждого файла (EXE, DLL, исходный код, документация) вычисляю хеш SHA-256 (например, через утилиту certutil -hashfile в Windows или sha256sum в Linux).
• Записываю хеши в отдельную таблицу (файл: имя, дата, хеш).
• Включаю эту таблицу в приложение к заключению как «Приложение 1. Сведения о целостности объектов».
• При любом сомнении стороны могут пересчитать хеши и сверить с моими.
• Если хеши не совпадают — объект считается измененным, и эксперт не несет ответственности за выводы по нему.
  Это защищает и эксперта, и стороны. 🛡️

Раздел 19. Анализ логов и дампов памяти: поиск следов работы ПО

🕵️ В уголовных делах часто предоставляются логи серверов и дампы оперативной памяти. Инженерный анализ:

• Логи: ищу строки, связанные с подозрительной программой (имена файлов, имена процессов, IP-адреса, порты). Использую grep, ripgrep, LogParser.
• Дампы памяти (memory dump): с помощью Volatility Framework извлекаю список процессов, сетевые соединения, открытые файлы, реестр.
• Сравниваю время событий в логах с временем работы программы (по системному таймеру).
• Восстанавливаю последовательность (timeline) для доказательства причинно-следственной связи: «программа запущена в 12:00, в 12:05 началась передача данных».
  Такой анализ помог в деле о мошенничестве с использованием ботнета. 📅

Раздел 20. Процессуальное оформление заключения: инженерный стандарт

📄 Моё заключение состоит из разделов:

• Титульный лист (наименование экспертизы, номер дела).
• Вводная часть (основания, вопросы, объекты с хешами, предупреждение об ответственности).
• Материалы и методы (перечень использованного ПО с версиями, описание стенда).
• Исследование (пошаговое описание: загрузка кода, анализ, эксперименты, скриншоты).
• Синтез и выводы (таблица ответов на вопросы с количественными обоснованиями).
• Приложения (листинги кода, хеш-таблицы, логи, графики, акт применения техсредств).
  Все числа, даты, версии ПО должны быть точными. Заключение подписывается и заверяется печатью. 🖋️

Раздел 21. Ответственность эксперта-инженера: технический аспект

⚠️ Я несу уголовную ответственность по ст. 307 УК РФ. Но также есть риск гражданско-правовой ответственности, если докажут, что я допустил грубую инженерную ошибку (например, использовал неверную архитектуру процессора при дизассемблировании). Поэтому:

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

Раздел 22. Ответы на часто задаваемые технические вопросы от юристов

🧑‍⚖️ Вопрос: Можно ли провести экспертизу, если программа написана на неизвестном мне языке (например, Rust)?
✅ Ответ: Да, после изучения синтаксиса и семантики, но это увеличит сроки. Лучше привлекать эксперта со знанием конкретного языка.

Вопрос: Что делать, если оппонент не дает исходный код, ссылаясь на коммерческую тайну?
✅ Ответ: Суд может обязать предоставить код под подписку о неразглашении. Если не дает — эксперт проводит дизассемблирование объектного кода.

Вопрос: Как долго длится экспертиза для программы на 500 000 строк?
✅ Ответ: Статический анализ + подготовка заключения: 30-40 рабочих дней. Если еще и динамический — до 60 дней.

Вопрос: Насколько точны ваши методы?
✅ Ответ: Вероятность ошибки при использовании полного набора метрик (AST, графы, метрики сложности) — менее 2%.

Раздел 23. Сравнение с альтернативными методами доказывания (без экспертизы)

⚖️ Что будет, если не назначать экспертизу? Суд может:

• Принять во внимание показания свидетелей-программистов (но они не предупреждаются об уголовной ответственности за ложные показания в той же мере, что эксперты).
• Назначить рецензию специалиста (но это не полноценное доказательство).
• Истребовать нотариальный протокол осмотра сайта (не затрагивает код).
  Без экспертизы программ для ЭВМ доказать плагиат или наличие закладки практически невозможно. Это единственный надежный технический метод. 🎯

Раздел 24. Будущее инженерной экспертизы ПО: вызовы 2026+

🤖 Технологические тренды:

• Обфускация нового поколения (полностью гомоморфное шифрование, обфускация на уровне LLVM). Потребуются новые методы деобфускации.
• Код, сгенерированный ИИ (GitHub Copilot, GPT-5). Как доказать авторство человека? Нужны метрики энтропии и статистики токенов.
• Программы на квантовых эмуляторах — пока редки, но появятся через 5 лет.
• Блокчейн-смарт-контракты в государственных реестрах — потребуют специализированных знаний.
  Мы постоянно обучаемся и обновляем инструментарий. 🚀

Раздел 25. Итоговые технические рекомендации для заказчиков экспертизы

📌 Для получения максимально качественного заключения:

• Предоставляйте исходный код (если возможно) — это снизит стоимость и повысит точность.
• Фиксируйте хеши файлов сразу после изъятия (до передачи эксперту).
• Пишите вопросы технически грамотно: не «нарушены ли права», а «совпадают ли фрагменты кода А и Б в следующих модулях…».
• Обеспечьте доступ к среде исполнения, если программа работает в специфических условиях (спецоборудование, лицензионные ключи).
• Не экономьте на сроках — качественная экспертиза требует времени.
• Учитывайте редкую специализацию: мы готовы вылетать в любой регион для проведения этой экспертизы. 🗺️

Заключение

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

🔗 Дополнительную информацию об инструментарии, методиках и примерах заключений вы найдете на нашем сайте: https://sud-expertiza.ru

🟩 Настоящая статья составлена инженером-экспертом и отражает реальные технические подходы, успешно примененные в десятках судебных процессов по всей России. Применяйте науку и инженерию для защиты своих прав! ⚙️