Здравствуйте. Я эксперт по компьютерно-технической экспертизе, специализируюсь на программном обеспечении. Мой стаж — 15 лет. За моими плечами — более 300 экспертиз: от маленьких интернет-магазинов до крупных государственных информационных систем.

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

1. Что такое судебная экспертиза компьютерных программ (моё определение)

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

Ключевое отличие от «независимой экспертизы»: я предупреждаюсь об уголовной ответственности по ст. 307 УК РФ за дачу заведомо ложного заключения. Это не просто формальность — это означает, что я не могу «подогнать» выводы под заказчика. Моя задача — научная истина.

2. Какие споры чаще всего требуют моей экспертизы (мой опыт)

2.1. Споры о плагиате (нарушении авторских прав) — 40% дел

Ситуация: Истец утверждает, что ответчик скопировал исходный код его программы. Ответчик говорит, что написал всё сам. Без экспертизы суд не может различить правду.

Как я это проверяю: Сравниваю исходные коды. Если структура (AST) совпадает на 30–40% — плагиат.

2.2. Споры о несоответствии техническому заданию — 30% дел

Ситуация: Заказчик заплатил за разработку ПО, но получил «сырой» продукт, который не работает или работает плохо.

Как я это проверяю: Беру техзадание, запускаю программу, проверяю каждый пункт. Если функция не работает или работает не так, как указано — фиксирую.

2.3. Споры о служебном произведении — 15% дел

Ситуация: Бывший сотрудник унёс код, созданный в рабочее время, и продаёт его конкурентам.

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

2.4. Дела о вредоносном ПО — 10% дел

Ситуация: Программа удаляет, блокирует или модифицирует информацию без согласия пользователя.

Как я это проверяю: Статический анализ + динамический анализ (запуск в изолированной среде).

3. Что я исследую при экспертизе (объекты)

4. Как я провожу экспертизу (пошаговый алгоритм)

Шаг 1. Получаю определение суда

Суд выносит определение, в котором указаны вопросы, поставленные перед экспертом. Я обязан строго следовать этим вопросам.

Шаг 2. Получаю материалы

Суд направляет мне:

• Исходный код (если есть)
• Исполняемые файлы
• Техническое задание (если есть)
• Документацию

Красный флаг: Если исходного кода нет, я могу работать только с исполняемыми файлами (декомпиляция). Это сложнее и дольше.

Шаг 3. Изучаю документацию

Первым делом я читаю техническое задание (ТЗ). Что должно быть сделано? Какие функции? Какая производительность?

Шаг 4. Анализирую исходный код (статический анализ)

Я открываю код в IDE (IntelliJ IDEA или VS Code) и смотрю:

• Структуру — классы, функции, модули.
• Стиль — именование переменных, форматирование.
• Алгоритмы — как реализованы ключевые функции.

Инструменты: SonarQube, PVS-Studio, Understand.

Шаг 5. Ищу плагиат (сравнительный анализ)

Если подозреваю плагиат, я сравниваю код истца и ответчика.

Инструменты:

• Moss (Measure of Software Similarity) — от Стэнфорда. Выдаёт процент схожести.
• JPlag — для Java, C#, Python.
• ASTDiff — сравнивает абстрактные синтаксические деревья.

Мои пороги:

• <10% — случайность.
• 10–30% — возможно, заимствование отдельных фрагментов.
• 30–60% — вероятный плагиат.
• 60% — почти наверняка плагиат.

Шаг 6. Тестирую программу (динамический анализ)

Запускаю программу в изолированной среде (виртуальная машина). Проверяю:

• Функциональность — работает ли так, как указано в ТЗ?
• Производительность — не тормозит ли?
• Ошибки — вылетает ли?

Инструменты: JUnit (Java), PyTest (Python), Selenium (веб-тесты), JMeter (нагрузка).

Шаг 7. Оформляю заключение

Моё заключение должно соответствовать ст. 86 ГПК РФ (или ст. 86 АПК РФ). Оно содержит:

Вводная часть:

• Кто я (ФИО, образование, стаж, предупреждение по ст. 307 УК РФ).
• На основании чего (определение суда).
• Какие материалы получил.

Исследовательская часть:

• Какие методы и инструменты использовал.
• Что обнаружил (с конкретными ссылками на файлы, строки кода).

Выводы: Чёткие, однозначные ответы на вопросы суда.

5. Три кейса из моей практики

Кейс № 1. Плагиат в мобильном приложении (Москва)

Ситуация: Компания А разработала мобильное приложение для доставки еды. Компания Б выпустила приложение с аналогичным функционалом через 3 месяца. Компания А заявила о нарушении авторских прав.

Мои действия:

1. Получил исходный код компании А и декомпилированный APK компании Б (исходного кода у компании Б не было).
2. Сравнил структуру пакетов (package names). У компании Б они были переименованы, но иерархия совпадала.
3. Использовал Moss: совпадение строк — 58%.
4. Обнаружил одинаковые строковые константы (URL сервера, API-ключи), которые не могли быть одинаковыми случайно.

Вывод: Плагиат. Суд взыскал с компании Б 3 млн руб. компенсации.

Кейс № 2. Несоответствие ТЗ при разработке CRM-системы (Екатеринбург)

Ситуация: Заказчик (завод) заказал CRM-систему за 4 млн руб. Разработчик сдал продукт, но программа зависала и теряла данные.

Мои действия:

1. Установил CRM на тестовый сервер.
2. Провёл функциональное тестирование: при попытке создать счёт программа выдавала ошибку «500 Internal Server Error».
3. Заглянул в логи сервера — нашёл неопределённую переменную $user_id. Ошибка программиста.
4. Нагрузочное тестирование (JMeter) показало, что при 10 пользователях система падала (требовалось 1000).

Вывод: Программа не соответствует ТЗ, имеет критические дефекты. Суд взыскал с разработчика 2,5 млн руб.

Кейс № 3. Спор о служебном произведении (Санкт-Петербург)

Ситуация: Бывший сотрудник IT-компании зарегистрировал авторские права на модуль шифрования. Компания утверждала, что модуль создан в рабочее время.

Мои действия:

1. Запросил метаданные файлов из Git-репозитория компании. Дата первого коммита модуля — 15.03.2023. Сотрудник уволился 20.04.2023. Значит, создал в период работы.
2. Сравнил стиль кодирования модуля с личными проектами сотрудника (которые он вёл вне работы). Стиль отличался: в модуле использовались корпоративные библиотеки, уникальные для компании.
3. В модуле были комментарии на русском, содержащие имена других сотрудников компании.

Вывод: Модуль является служебным произведением (ст. 1295 ГК РФ). Суд признал права за компанией.

6. Типичные ошибки заказчиков (и как их избежать)

Ошибка № 1. Нет технического задания

Пример: Заказчик сказал разработчику «сделай удобную программу». Разработчик сделал. Заказчик недоволен. А доказательств нет.

Как избежать: Техническое задание — обязательно. Без него экспертиза невозможна.

Ошибка № 2. Нет исходного кода

Пример: Заказчик потерял исходный код. Эксперт может работать только с исполняемыми файлами, но это сложнее и дороже.

Как избежать: Храните исходный код в Git (GitHub, GitLab, Bitbucket).

Ошибка № 3. Нет системы контроля версий

Пример: Заказчик не может доказать, когда была создана программа.

Как избежать: Используйте Git. Он хранит историю изменений и авторство.

7. Как я оформляю заключение (что судья увидит)

Моё заключение — это не просто «программа хорошая». Это структурированный документ:

Вводная часть:

• Кто я (ФИО, образование, стаж, аттестация).
• Что я исследовал (программа, версия).
• Какие материалы получил.

Исследовательская часть:

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

Выводы:

• Соответствует ли программа ТЗ (да, нет, частично).
• Является ли код производным (плагиат) (да, нет, частично).
• Есть ли дефекты (критические, значительные, незначительные).

8. Рекомендации по выбору экспертной организации (мой совет)

8.1. На что обратить внимание

8.2. Где заказать

Я работаю в Центре Криминалистических Экспертиз. У нас есть:

• опытные эксперты (Java, Python, C++, C#, JavaScript, PHP);
• лицензионные инструменты;
• аккредитация.

Заказать экспертизу можно на сайте https://krimexpert.ru.

9. Заключение эксперта

Судебная экспертиза компьютерных программ — это не магия. Это строгая наука, подчиняющаяся формальным методам. Я, как эксперт, гарантирую объективность, но я не могу гарантировать победу. Моё дело — дать факты.

Мой совет заказчикам: не экономьте на экспертизе. 50–150 тысяч рублей на экспертизу — это копейки по сравнению с миллионами на разработку заново.

Центр Криминалистических Экспертиз — ваш надёжный партнёр. Звоните, приезжайте, я покажу вам, как выглядит настоящая экспертиза программного обеспечения.

© Центр Криминалистических Экспертиз. При использовании материалов ссылка на источник обязательна.