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

Раздел 1. Понятие и сущность экспертизы программного кода

1.1. Определение и предметная область

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

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

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

1.2. Объекты экспертного исследования

Объектами экспертизы программного кода выступают материальные и электронные носители, содержащие:

• исходные тексты программ на языках высокого уровня (C, C++, C#, Java, Python, PHP, JavaScript, Go, Rust, 1С и другие);
• объектные файлы и библиотеки (.obj, .lib, .so, .dll, .a);
• исполняемые файлы (.exe, .bin, .elf, .apk, .ipa);
• прошивки микроконтроллеров и встраиваемых систем (hex, bin, elf);
• дампы оперативной памяти и образы дисков, содержащие следы выполнения программ;
• байт-код виртуальных машин (Java bytecode, .NET CIL, Python .pyc);
• файлы проектов и конфигурации сборки (Makefile, CMakeLists.txt, pom.xml, package.json);
• метаданные систем контроля версий (Git, SVN) — журналы коммитов, авторство, временные метки.

Каждый объект подлежит фиксации с соблюдением требований криминалистической техники: вычисляются контрольные суммы (MD5, SHA-256), создаются битовые копии, работа ведётся исключительно с копиями в изолированной среде.

1.3. Правовые основания назначения

Назначение экспертизы программного кода осуществляется в порядке, предусмотренном процессуальным законодательством Российской Федерации. В гражданском, арбитражном и уголовном процессе экспертиза назначается судом или органом предварительного расследования. Союз «Федерация судебных экспертов» обеспечивает проведение таких исследований силами аттестованных экспертов, имеющих профильное высшее образование и практический стаж в области анализа программного обеспечения .

Эксперт предупреждается об уголовной ответственности за дачу заведомо ложного заключения. Заключение эксперта должно соответствовать требованиям Федерального закона «О государственной судебно-экспертной деятельности в Российской Федерации» и обладать свойствами проверяемости, обоснованности и полноты.

Раздел 2. Методологические основы статического анализа кода

2.1. Анализ исходного кода

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

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

На синтаксическом уровне строится абстрактное синтаксическое дерево (AST), отражающее иерархическую структуру программы. Сравнение AST двух программ позволяет выявить совпадения на уровне конструкций языка даже при изменённых именах и перестановке независимых операторов.

На семантическом уровне производится анализ графа потока управления (CFG) и графа зависимостей по данным (DDG). Совпадение нетривиальных путей выполнения и последовательностей операций над данными свидетельствует о заимствовании логики, а не только синтаксиса.

2.2. Анализ бинарного кода

При отсутствии исходного кода экспертиза программного кода выполняется на уровне машинного кода или байт-кета. Методика включает дизассемблирование с использованием специализированных инструментов (IDA Pro, Ghidra, Radare2) и последующее восстановление псевдокода. Качество восстановления зависит от архитектуры, наличия отладочной информации и применения обфускации.

Сравнительный анализ бинарного кода опирается на:

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

Совпадение совокупности перечисленных признаков позволяет сделать обоснованный вывод о происхождении бинарного файла из конкретного исходного кода или о переработке исходного продукта.

2.3. Выявление обфускации и защитных механизмов

Обфускация — намеренное запутывание кода с целью затруднения его понимания и анализа. Экспертиза программного кода обязана учитывать возможность применения обфускации и предпринимать меры по её преодолению. Типовые признаки обфускации включают: избыточные переходы, мёртвый код, динамическое разрешение вызовов, шифрование строк, контроль целостности.

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

2.4. Инструментальная база статического анализа

Инструментарий эксперта по программному коду включает лицензионные и свободно распространяемые средства. К основным категориям относятся:

• дизассемблеры и декомпиляторы: IDA Pro, Ghidra, Binary Ninja, RetDec, JADX (для Android), dotPeek (для .NET);
• средства сравнения бинарных файлов: BinDiff, Diaphora, bindiff-подобные плагины;
• утилиты сравнения текстов и AST: Beyond Compare, Meld, специализированные средства анализа схожести кода;
• системы контроля версий и анализа репозиториев: Git, SVN, средства визуализации истории;
• средства анализа метаданных: exiftool, PE-инспекторы, ELF-анализаторы.

Выбор инструмента определяется характером объекта и поставленной задачей. Эксперт обязан документировать применённые инструменты и их версии, чтобы обеспечить воспроизводимость исследования.

Раздел 3. Динамический анализ и исследование поведения программ

3.1. Сущность динамического подхода

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

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

3.2. Изолированная среда выполнения

Проведение динамического анализа требует создания безопасной среды, исключающей неконтролируемое распространение вредоносного кода и повреждение инфраструктуры экспертного учреждения. Для этой цели используются виртуальные машины (VMware, VirtualBox, QEMU), песочницы (Cuckoo Sandbox, коммерческие облачные песочницы), эмуляторы мобильных устройств и изолированные сегменты сети.

Среда должна обеспечивать:

• возможность отката к исходному состоянию (снапшоты);
• перехват и регистрацию системных вызовов (strace, procmon, API-мониторы);
• запись сетевого трафика (Wireshark, tcpdump);
• мониторинг изменений файловой системы и реестра;
• инструментирование исполняемого кода для трассировки.

3.3. Наблюдаемые артефакты и их интерпретация

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

• сетевые соединения: IP-адреса, доменные имена, порты, протоколы, содержимое передаваемых данных (при возможности расшифровки или при отсутствии шифрования);
• файловые операции: создание, чтение, модификация, удаление файлов; пути и имена, характер которых может указывать на назначение;
• операции с реестром: ключи автозагрузки, конфигурационные параметры, следы установки;
• загрузка библиотек и драйверов: перечень модулей, источники загрузки, порядок;
• межпроцессное взаимодействие: именованные каналы, сокеты, разделяемая память;
• изменения в памяти: внедрение кода в другие процессы, модификация исполняемых страниц.

Интерпретация артефактов требует осторожности: обнаружение сетевого соединения само по себе не свидетельствует о вредоносности; необходим контекст — куда и зачем программа обращается, соответствует ли это заявленному функционалу, имело ли место согласие пользователя.

3.4. Сочетание статического и динамического анализа

Наиболее достоверные результаты достигаются при комплексном применении статического и динамического подходов. Статический анализ позволяет выявить потенциальные возможности кода, динамический — подтвердить их фактическую реализацию. Например, статический анализ может обнаружить в коде функцию формирования HTTP-запроса на внешний адрес; динамический анализ подтверждает, что запрос действительно отправляется при определённых условиях и содержит определённые данные.

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

Раздел 4. Сравнительное исследование и установление сходства программного кода

4.1. Правовая квалификация сходства

Установление сходства программного кода является одной из наиболее востребованных задач экспертизы. Однако эксперт не решает вопрос о наличии авторского права или о факте нарушения — это прерогатива суда. Задача эксперта состоит в установлении объективных технических характеристик: объёма совпадающего кода, характера совпадений, возможности их случайного возникновения.

С точки зрения технического анализа различают:

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

4.2. Метрики сходства

Количественная оценка сходства программного кода может производиться с использованием различных метрик. Наиболее распространённые подходы включают:

• процент совпадающих токенов или строк;
• коэффициент схожести AST;
• метрики на основе графов (сходство CFG, сходство графов вызовов);
• анализ уникальных идентификаторов (строк, констант, комментариев);
• оценка энтропии и статистических характеристик.

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

4.3. Проблема «случайных совпадений»

Значительная часть споров о заимствовании кода связана с необходимостью отграничить заимствование от объективных совпадений, обусловленных:

• использованием одних и тех же библиотек и фреймворков;
• реализацией стандартных алгоритмов, для которых типовые решения широко известны;
• следованием общепринятым соглашениям об именовании и структуре;
• ограниченностью языка, диктующей однотипные конструкции для типовых задач.

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

4.4. Установление авторства

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

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

5.1. Соответствие техническому заданию

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

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

5.2. Выявление дефектов и уязвимостей

Экспертиза программного кода может быть направлена на выявление дефектов, которые привели к сбоям, утечкам данных или иным негативным последствиям. Анализ включает поиск типовых классов уязвимостей: переполнение буфера, инъекции, ошибки аутентификации и авторизации, небезопасная обработка входных данных, утечки памяти, состояния гонки.

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

5.3. Анализ скрытой функциональности

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

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

5.4. Оценка производительности и масштабируемости

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

Раздел 6. Процессуальные и организационные аспекты экспертизы программного кода

6.1. Формулирование вопросов эксперту

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

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

6.2. Порядок представления материалов

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

Все поступившие материалы фиксируются, описываются и помещаются на хранение с соблюдением правил, исключающих несанкционированный доступ и модификацию. Целостность носителей удостоверяется контрольными суммами.

6.3. Заключение эксперта и его структура

Заключение по результатам экспертизы программного кода должно содержать:

• вводную часть: сведения об эксперте, основании производства экспертизы, поставленных вопросах, перечне поступивших объектов;
• исследовательскую часть: описание применённых методов и инструментов, последовательность исследования, выявленные факты и промежуточные выводы;
• выводы: ответы на поставленные вопросы в форме, доступной для проверки и оценки.

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

6.4. Участие эксперта в судебном заседании

Эксперт может быть вызван в суд для разъяснения заключения, ответов на вопросы сторон и суда. В ходе заседания эксперт вправе давать пояснения по применённым методикам, использованным инструментам и сделанным выводам. Союз «Федерация судебных экспертов» обеспечивает защиту своих заключений в судебных заседаниях и следственных органах .

Раздел 7. Практические кейсы экспертизы программного кода

Кейс 1. Установление факта переработки программного обеспечения системы управления складом

В производстве экспертного учреждения находилось дело по иску компании «ЛогистСофт» к конкуренту «СкладТех» о нарушении исключительных прав на программу для ЭВМ — систему управления складом (WMS). Истец располагал исходным кодом собственной разработки, ответчик представил только исполняемые файлы и утверждал, что продукт создан независимо.

Перед экспертом были поставлены вопросы: имеются ли в представленных бинарных файлах ответчика признаки переработки исходного кода истца; если да, каков объём и характер совпадений.

Исследование началось с дизассемблирования исполняемых файлов ответчика с использованием IDA Pro и Ghidra. Параллельно была произведена компиляция исходного кода истца в сопоставимой среде с последующим дизассемблированием. Сравнение проводилось на нескольких уровнях.

На уровне строковых литералов было установлено совпадение значительного числа строк, включая текст сообщений об ошибках, подсказок пользовательского интерфейса и внутренних логов. При этом в нескольких строках совпадали даже орфографические ошибки, присутствовавшие в оригинале, что само по себе является сильным признаком копирования, поскольку независимое воспроизведение идентичных ошибок маловероятно.

На уровне графов потока управления эксперт сопоставил функции, отвечающие за ключевые бизнес-операции: приёмку товара, размещение, комплектацию заказов, инвентаризацию. Для 92% сопоставленных функций графы потоков управления оказались идентичными или изоморфными. Особое внимание привлекла функция расчёта приоритета размещения товара, содержавшая уникальную константу 0x4C4F4749 (ASCII-последовательность «LOGI»), которая не несла функциональной нагрузки и не могла возникнуть случайно при независимой разработке. Эта константа присутствовала в бинарном файле ответчика в той же функции и в той же позиции.

Дополнительно были проанализированы метаданные компиляции: секции.rdata и.rodata содержали идентичные строковые литералы с характерными опечатками, а последовательность загрузки ресурсов совпадала вплоть до порядка второстепенных элементов.

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

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

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

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

Задача эксперта состояла в установлении фактического поведения приложения и определении перечня собираемых данных и адресатов передачи.

Исследование проводилось в изолированной среде. Был развёрнут эмулятор Android с инструментарием ADB, установлен перехватывающий прокси-сервер для анализа сетевого трафика, применены средства динамической инструментации (Frida) для трассировки вызовов API. Параллельно выполнялся статический анализ декомпилированного APK с использованием JADX.

Статический анализ выявил в коде приложения обращения к API геолокации и чтения контактов, не упомянутые в пользовательском соглашении. Однако факт наличия кода сам по себе не доказывал его активацию. Динамический анализ подтвердил, что соответствующие вызовы выполняются при запуске приложения и с определённой периодичностью.

Перехват трафика показал наличие POST-запросов на IP-адрес, расположенный в офшорной юрисдикции и не связанный с инфраструктурой финансовой организации. Содержимое запросов было зашифровано, однако анализ логирования на стороне эмулятора позволил восстановить структуру передаваемых пакетов и идентифицировать в них поля, соответствующие координатам геолокации и хешированным идентификаторам контактов.

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

Кейс иллюстрирует необходимость сочетания статического и динамического анализа: только статический анализ выявил бы «мёртвый» код, только динамический — не позволил бы установить назначение передаваемых данных.

Кейс 3. Спор о нарушении условий свободной лицензии

В арбитражном суде рассматривался спор между разработчиком коммерческого программного продукта и правообладателем библиотеки, распространяемой на условиях лицензии GPL v3. Истец утверждал, что ответчик использовал библиотеку в своём продукте без выполнения условий лицензии — в частности, без раскрытия исходного кода производного произведения.

Эксперту предстояло установить, содержится ли код библиотеки в продукте ответчика и в какой форме — динамического связывания или статической линковки.

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

Сравнение графов вызовов показало, что функции, реализующие определённые алгоритмы, присутствуют в исполняемом файле в форме, соответствующей статической линковке. Эксперт также проанализировал заголовочные файлы, включённые в дистрибутив исходного кода ответчика (частично раскрытого по требованию лицензии), и обнаружил в них директивы включения, соответствующие заголовкам библиотеки истца, а также комментарии, воспроизводящие текст лицензионных оговорок GPL.

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

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

Кейс 4. Установление авторства алгоритма сжатия данных

После смерти разработчика, известного специалиста в области алгоритмов сжатия без потерь, между наследниками возник спор о распределении прав на созданный им алгоритм. Один наследник располагал исходным кодом и утверждал, что является соавтором; второй располагал только исполняемым файлом и заявлял, что код был создан наследодателем единолично.

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

Эксперт дизассемблировал исполняемый файл, восстановил псевдокод и сопоставил его с представленным исходным кодом. Совпадение основных циклов, таблиц вероятностей и структуры данных составило 97%, что подтверждало происхождение исполняемого файла из данного исходного кода.

Однако для решения вопроса об авторстве потребовался стилометрический анализ. Эксперт изучил особенности идентификаторов и комментариев в исходном коде. Было установлено, что имена переменных и структура комментариев в различных модулях неоднородны: часть кода использовала характерные для наследодателя соглашения (например, заглавные однобуквенные идентификаторы циклов I, J, K вместо строчных i, j, k, развёрнутые комментарии с указанием дат и инициалов), тогда как другие модули демонстрировали иной стиль (верблюжья нотация, краткие комментарии, иная организация отступов).

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

Кейс демонстрирует применение стилометрии в экспертизе программного кода и важность анализа не только функциональной, но и стилевой неоднородности кода.

Кейс 5. Анализ драйвера с признаками перехвата ввода

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

Эксперту был представлен драйвер в виде.sys-файла и дампы памяти с поражённых машин. Задача состояла в установлении функциональности драйвера и его причастности к передаче данных.

Статический анализ драйвера выявил наличие процедур, не типичных для драйвера клавиатуры: формирование сетевых пакетов, обращение к пространству пользователя, работа с таймерами. Динамический анализ в изолированной виртуальной машине подтвердил, что драйвер перехватывает IRP-запросы (I/O Request Packets) на чтение с USB-устройства ввода и дублирует данные в скрытый буфер.

Эксперт восстановил алгоритм обфускации исходящего трафика: XOR с ключом 0xAB и последующее кодирование Base64. Расшифровав перехваченные пакеты, эксперт установил, что передаваемые данные представляют собой скан-коды нажатий клавиш с временными метками. Адрес назначения совпадал с IP-адресом, зафиксированным в сетевом трафике организации.

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

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

Кейс 6. Отказ в иске о нарушении авторских прав при совпадении типовых конструкций

Компания «АльтЭль» обратилась с иском к «Нума Технологии», утверждая, что программное обеспечение ответчика является копией её продукта, и ссылаясь на совпадение исходного кода до 99%. Ответчик возражал, указывая на использование открытых библиотек и стандартных конструкций.

Суд назначил экспертизу программного кода, поручив её экспертам, специализирующимся на анализе алгоритмов и структур данных. Перед экспертом были поставлены вопросы: является ли представленный код ответчика самостоятельным результатом разработки; обусловлены ли выявленные совпадения использованием общедоступных библиотек и типовых решений.

Эксперт проанализировал статистическую структуру кода обеих программ, выявил наличие нетиповых семантических конструкций, исследовал даты публикации кода в открытых репозиториях и сопоставил их с датами регистрации программ в Роспатенте.

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

Эксперт пришёл к выводу, что программные продукты обеих сторон являются самостоятельными результатами интеллектуальной деятельности, а частичные совпадения обусловлены использованием общедоступных технологий и библиотек с открытым исходным кодом. Суд отказал в удовлетворении иска.

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

Кейс 7. Установление модификации программы для обхода лицензионного контроля

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

Эксперту были представлены оригинальный дистрибутив, полученный от правообладателя, и исполняемый файл, изъятый у пользователя. Требовалось установить, является ли изъятый файл модификацией оригинального продукта и в чём состоят изменения.

Бинарное сравнение с использованием BinDiff и Diaphora выявило различия в нескольких функциях, расположенных в окрестности процедуры проверки лицензии. Дизассемблирование модифицированного файла показало, что в оригинале функция проверки возвращает значение, зависящее от результата валидации ключа, а в модифицированном файле безусловно возвращается значение, соответствующее успешной проверке. Кроме того, был изменён порядок вызовов: процедура, следующая за проверкой и инициирующая ограничения функциональности при неуспехе, оказалась недостижимой.

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

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

Кейс демонстрирует методику анализа патчей и установления функционального назначения изменений в бинарном коде.

Кейс 8. Исследование соответствия программного обеспечения техническому заданию

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

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

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

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

Эксперт сформулировал выводы отдельно по каждому требованию, указав, какие реализованы, какие нет и в чём состоят выявленные дефекты. Такая структура выводов позволила суду оценить соразмерность выполненных и невыполненных обязательств.

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

Кейс 9. Анализ происхождения прошивки промышленного контроллера

Завод «А» обвинил завод «Б» в копировании прошивки станка с числовым программным управлением. Исходный код прошивки не был доступен ни у одной из сторон; исследованию подлежали бинарные образы, считанные с микросхем памяти контроллеров.

Эксперт получил дампы Flash-памяти с устройств обеих сторон. После определения архитектуры процессора и карты памяти было выполнено дизассемблирование с использованием Ghidra и специализированного инструментария для встраиваемых систем.

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

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

Вывод эксперта подтвердил факт заимствования прошивки. Суд взыскал компенсацию.

Кейс демонстрирует особенности экспертизы встраиваемых систем, где объектом выступает не файловая система, а образ энергонезависимой памяти.

Кейс 10. Экспертиза программного кода в споре о наследовании прав на программный продукт

После смерти индивидуального предпринимателя, разрабатывавшего программное обеспечение для малого бизнеса, между наследниками возник спор о составе наследства. Один из наследников утверждал, что программный продукт создан им совместно с наследодателем и подлежит разделу; другие наследники возражали, указывая, что продукт создан наследодателем единолично.

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

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

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

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

Кейс иллюстрирует применение методов анализа истории разработки и стилометрии для установления состава авторов программного продукта.

Раздел 8. Организация экспертной деятельности в Союзе «Федерация судебных экспертов»

8.1. Компетенция и квалификация экспертов

Союз «Федерация судебных экспертов» объединяет экспертов, имеющих высшее профильное образование и практический стаж работы в экспертной сфере. Многие эксперты являются кандидатами наук и имеют публикации в специализированных изданиях; значительная часть специалистов имеет опыт работы в государственных экспертных учреждениях Минюста и МВД . Для экспертизы программного кода привлекаются специалисты в области информационных технологий, программирования, информационной безопасности, имеющие практический опыт разработки и анализа программных продуктов.

Союз обеспечивает соответствие деятельности экспертов требованиям Федерального закона «О государственной судебно-экспертной деятельности в Российской Федерации» и внутренним стандартам качества . Экспертиза программного кода в Москве может быть проведена с выездом эксперта либо на территории заказчика, либо в экспертном учреждении, в зависимости от характера объектов и условий их хранения.

8.2. Порядок обращения и сроки

Обращение в Союз «Федерация судебных экспертов» для проведения экспертизы программного кода возможно как по определению суда или постановлению следователя, так и по договору со стороной спора — в форме досудебного исследования или рецензирования ранее данного заключения. Сроки проведения экспертизы зависят от объёма объектов и сложности поставленных вопросов; ориентировочные сроки определяются после ознакомления с материалами.

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

8.3. Гарантии качества

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

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

Заключение

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

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