Здравствуйте, коллеги. Я инженер-программист с 15-летним стажем. Начинал как разработчик на C++ и Java, потом дорос до техлида, а потом переквалифицировался в эксперта по компьютерным программам. За моими плечами — сотни экспертиз: от маленьких скриптов до огромных корпоративных систем.
В этой статье я расскажу о технической экспертизе компьютерных программ так, как это видит инженер. Без заумных юридических терминов. Простым, рабочим языком. О том, как я анализирую код, ищу баги, тестирую производительность и пишу заключения.
- Что такое техническая экспертиза компьютерных программ (моё определение)
Техническая экспертиза компьютерных программ — это комплексное исследование программного обеспечения, включающее:
- анализ документации (техзадание, спецификации);
- статический анализ исходного кода;
- динамическое тестирование (функциональное, нагрузочное);
- анализ безопасности (уязвимости);
- сравнительный анализ (плагиат).
Цель: определить, соответствует ли программа требованиям, работает ли она стабильно и безопасно, нет ли в ней критических ошибок.
- Какие задачи я решаю (мой хит-парад)
2.1. Проверка соответствия техническому заданию (ТЗ)
Суть: Заказчик дал ТЗ, разработчик написал программу. Заказчик недоволен. Я проверяю, реализованы ли все пункты ТЗ.
Как проверяю: Беру ТЗ, запускаю программу, проверяю каждый пункт. Если функция не работает или работает не так, как указано — фиксирую.
2.2. Поиск плагиата (копирования кода)
Суть: Истец утверждает, что ответчик скопировал его код. Я сравниваю исходные коды.
Как проверяю: Использую инструменты статического анализа (Moss, JPlag, ASTDiff). Сравниваю структуру (AST), строки кода, алгоритмы.
2.3. Выявление дефектов (багов)
Суть: Программа вылетает, зависает, теряет данные. Я ищу причины.
Как проверяю: Статический анализ (SonarQube) + динамический анализ (запуск в изолированной среде, стресс-тесты).
2.4. Анализ безопасности (пентест)
Суть: Программа имеет уязвимости (SQL-инъекции, XSS, переполнение буфера).
Как проверяю: Использую OWASP ZAP, Burp Suite, Metasploit. Проверяю, можно ли взломать программу.
2.5. Установление авторства (служебное произведение)
Суть: Бывший сотрудник утверждает, что он автор программы. Работодатель — что программа создана в рабочее время.
Как проверяю: Сравниваю стиль кодирования, проверяю метаданные Git (дата коммита, автор), ищу уникальные комментарии.
- Что я исследую (объекты)
| Объект | Формат | Инструменты |
| Исходный код | .java, .py, .cpp, .cs, .js, .php | VS Code, IntelliJ IDEA |
| Исполняемый код | .exe, .dll, .jar, .apk | IDA Pro, Ghidra, dnSpy |
| Техническое задание | .doc, .pdf | Adobe Reader |
| Логи работы | .log | grep, awk, Notepad++ |
- Как я провожу экспертизу (пошаговый алгоритм)
Шаг 1. Изучаю документацию
Я не лезу в код, пока не прочитаю техническое задание (ТЗ). Что должно быть сделано? Какие функции? Какая производительность? Если ТЗ нет — экспертиза невозможна.
Шаг 2. Получаю исходный код
Если исходный код есть — хорошо. Если нет — я декомпилирую исполняемые файлы (IDA Pro, Ghidra).
Красный флаг: Если исходного кода нет, я предупреждаю заказчика: «Выводы будут неполными».
Шаг 3. Статический анализ (копаюсь в коде)
Я открываю код в IDE и смотрю:
- Структуру — классы, функции, модули. Хорошо ли спроектировано?
- Стиль — именование переменных, форматирование. Есть ли «плохой» код?
- Алгоритмы — как реализованы ключевые функции. Оптимально ли?
Инструменты:
- SonarQube — ищет «запахи кода» (code smells), баги, уязвимости.
- PVS-Studio — ищет ошибки в C++ и C#.
- Understand — строит графы зависимостей.
Шаг 4. Ищу плагиат (сравнительный анализ)
Если подозреваю плагиат, я сравниваю код истца и ответчика.
Инструменты:
- Moss (Measure of Software Similarity) — от Стэнфорда. Выдаёт процент схожести.
- JPlag — для Java, C#, Python.
- ASTDiff — сравнивает абстрактные синтаксические деревья.
Мои пороги:
- <10% — случайность.
- 10–30% — возможно, заимствование отдельных фрагментов.
- 30–60% — вероятный плагиат.
- 60% — почти наверняка плагиат.
Шаг 5. Тестирую программу (динамический анализ)
Я запускаю программу в изолированной среде (виртуальная машина).
5.1. Функциональное тестирование
Проверяю, работает ли программа так, как указано в ТЗ.
Инструменты: JUnit (Java), PyTest (Python), Selenium (веб-тесты).
5.2. Нагрузочное тестирование
Проверяю, как программа ведёт себя под нагрузкой.
Инструменты: JMeter, LoadRunner, Gatling.
5.3. Тестирование безопасности (пентест)
Проверяю уязвимости:
- SQL-инъекции (можно ли внедрить вредоносный код в запрос к БД?).
- XSS (межсайтовый скриптинг).
- Переполнение буфера.
Инструменты: OWASP ZAP, Burp Suite, Metasploit.
5.4. Анализ утечек памяти
Проверяю, не «жрёт» ли программа память.
Инструменты: Valgrind (Linux), Dr. Memory (Windows).
Шаг 6. Оформляю заключение
Моё заключение — это не просто «программа хорошая». Это структурированный документ:
Вводная часть:
- Кто я (ФИО, образование, стаж).
- Что я исследовал (программа, версия).
- Какие материалы получил.
Исследовательская часть:
- Результаты статического анализа (таблица багов, фото фрагментов кода).
- Результаты сравнения (Moss, JPlag).
- Результаты тестирования (скриншоты ошибок, графики производительности).
Выводы:
- Соответствует ли программа ТЗ (да, нет, частично).
- Является ли код производным (плагиат) (да, нет, частично).
- Есть ли дефекты (критические, значительные, незначительные).
- Три кейса из моей практики
Кейс № 1. Плагиат в мобильном приложении (Android)
Ситуация: Компания А разработала мобильное приложение для доставки еды. Компания Б выпустила приложение с аналогичным функционалом через 3 месяца.
Мои действия:
- Получил исходный код компании А и APK компании Б.
- Декомпилировал APK в Java (JADX).
- Сравнил структуру пакетов (package names). У компании Б они были переименованы, но иерархия совпадала.
- Использовал Moss: совпадение строк — 58%.
- Обнаружил одинаковые строковые константы (URL сервера, API-ключи).
Вывод: Плагиат. Суд взыскал с компании Б 3 млн руб.
Кейс № 2. Несоответствие ТЗ при разработке CRM-системы
Ситуация: Заказчик заказал CRM-систему за 4 млн руб. Разработчик сдал продукт, но программа зависала и теряла данные.
Мои действия:
- Установил CRM на тестовый сервер (Ubuntu 20.04, PHP 7.4, MySQL 8.0).
- Провёл функциональное тестирование: при попытке создать счёт программа выдавала ошибку «500 Internal Server Error».
- Заглянул в логи сервера (/var/log/apache2/error.log) — нашёл неопределённую переменную $user_id.
- Нагрузочное тестирование (JMeter, 10 потоков, 1000 запросов) показало, что при 10 пользователях система падала.
Вывод: Не соответствует ТЗ. Суд взыскал 2,5 млн руб.
Кейс № 3. Спор о служебном произведении
Ситуация: Бывший сотрудник зарегистрировал авторские права на модуль шифрования. Компания утверждала, что модуль создан в рабочее время.
Мои действия:
- Запросил метаданные из Git. Дата первого коммита — 15.03.2023. Сотрудник уволился 20.04.2023.
- Сравнил стиль кодирования (именование переменных, форматирование, комментарии) с личными проектами сотрудника. Стиль отличался.
- В модуле были комментарии на русском, содержащие имена других сотрудников компании.
Вывод: Служебное произведение. Суд признал права за компанией.
- Оборудование и инструменты, которые я использую
| Инструмент | Для чего | Лицензия |
| SonarQube | Статический анализ (баги, уязвимости) | Open Source |
| PVS-Studio | Статический анализ C++/C# | Коммерческая |
| Moss | Детектирование плагиата | Бесплатно (Стэнфорд) |
| JPlag | Детектирование плагиата | Бесплатно |
| JMeter | Нагрузочное тестирование | Open Source |
| OWASP ZAP | Анализ безопасности | Open Source |
| IDA Pro | Дизассемблирование | Коммерческая |
| Ghidra | Дизассемблирование | Open Source (NSA) |
| Valgrind | Анализ утечек памяти | Open Source |
- Частые ошибки заказчиков (и как их избежать)
Ошибка № 1. Нет технического задания
Пример: «Сделайте удобную программу». Экспертиза невозможна.
Как избежать: Техническое задание — обязательно. Прописывайте каждый пункт.
Ошибка № 2. Нет исходного кода
Пример: Заказчик потерял исходный код. Придётся декомпилировать, что сложнее и дороже.
Как избежать: Храните исходный код в Git (GitHub, GitLab, Bitbucket).
Ошибка № 3. Нет системы контроля версий
Пример: Заказчик не может доказать, когда была создана программа.
Как избежать: Используйте Git. Он хранит историю изменений и авторство.
- Как я оформляю заключение
Вводная часть:
- Кто я (ФИО, образование, стаж).
- Что я исследовал.
- Какие материалы получил.
Исследовательская часть:
- Таблица: пункт ТЗ vs реализация.
- Скриншоты ошибок.
- Графики производительности.
- Фрагменты кода.
Выводы:
- Соответствует ТЗ? (да/нет/частично).
- Есть ли плагиат? (да/нет/частично).
- Есть ли критические дефекты? (да/нет).
- Рекомендации по выбору экспертной организации
На что смотреть:
- Опыт. Эксперт должен знать разные языки программирования (Java, Python, C++, C#, JavaScript, PHP).
- Инструменты. Должны быть лицензионные версии.
- Судебная практика. Поищите упоминания в ГАС «Правосудие».
Где заказать: Я работаю в Центре Криминалистических Экспертиз. У нас есть опытные инженеры, лицензионные инструменты и аккредитация.
Заказать экспертизу можно на сайте https://krimexpert.ru.
- Заключение (инженерам на заметку)
Коллеги, запомните главное: техническая экспертиза компьютерных программ — это не бюрократия, а инженерия. Анализируйте код, тестируйте, ищите баги. Только цифры и факты.
Центр Криминалистических Экспертиз — ваш надёжный партнёр. Звоните, приезжайте, я покажу вам, как выглядит настоящая экспертиза программного обеспечения.
© Центр Криминалистических Экспертиз. При использовании материалов ссылка на источник обязательна.
Задавайте любые вопросы