Союз «Федерация судебных экспертов» — крупнейшая сеть негосударственных судебно-экспертных учреждений Российской Федерации, располагающая региональными представительствами во всех федеральных округах страны. Штат организации насчитывает около 145 экспертов различной специализации, а ежегодно члены «Федерации» проводят более 4 000 судебных и независимых экспертиз, из которых свыше 85% выполняются по поручению правоохранительных и судебных органов. Если вам требуется экспертиза программного обеспечения в Москве, специалисты Союза готовы провести исследование любой сложности — от анализа исходного кода до установления фактов неправомерного использования программных продуктов.

Контакты для обращения: Москва, 115114, Кожевнический проезд, д. 3. Телефон: +7 (495) 666-5-666. Круглосуточная поддержка: +7 (995) 100-33-55. Электронная почта: info@fse.ms.

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

Экспертиза программного обеспечения представляет собой самостоятельный род судебных инженерно-компьютерных экспертиз, объектом исследования которого выступают программные продукты во всем многообразии их форм: исходные тексты, объектный код, исполняемые модули, прошивки, а также сопутствующие артефакты разработки и функционирования. Правовую основу данного вида экспертной деятельности составляет Федеральный закон от 31 мая 2001 г. № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации», а также процессуальные кодексы — Гражданский процессуальный, Арбитражный процессуальный и Уголовно-процессуальный кодексы Российской Федерации. В системе судебных экспертиз экспертиза программного обеспечения занимает пограничное положение: она одновременно относится к классу инженерно-технических экспертиз и тесно смыкается с экспертизой компьютерной информации, однако обладает собственным предметом и специфическими методами исследования.

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

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

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

Раздел 2. Объекты и задачи экспертного исследования программного обеспечения

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

К числу типичных объектов экспертизы программного обеспечения относятся:

• исходные тексты программ на различных языках программирования — от компилируемых (C, C++, Java, Go) до интерпретируемых (Python, JavaScript, PHP);

• исполняемые файлы и библиотеки в форматах, соответствующих операционным системам (PE для Windows, ELF для Linux, Mach-O для macOS);

• прошивки встраиваемых систем и микроконтроллеров, включая бинарные образы Flash-памяти;

• дампы оперативной памяти, содержащие следы выполнения программных процессов;

• файлы конфигурации, журналы событий и иные артефакты функционирования программных средств;

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

• носители информации (жесткие диски, твердотельные накопители, USB-флеш-накопители), содержащие программные продукты в их естественной среде.

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

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

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

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

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

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

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

Раздел 3. Методологический аппарат экспертизы программного обеспечения

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

Статический анализ составляет основу большинства экспертных исследований программных продуктов. Он предполагает изучение кода без его исполнения и включает несколько уровней глубины. На уровне исходного текста (при его наличии) экспертом исследуются структура программы, алгоритмические решения, стилистические особенности, наличие и содержание комментариев. При отсутствии исходного кода применяются методы дизассемблирования и декомпиляции — восстановления приближенного исходного текста по машинному коду. Современный инструментарий статического анализа включает дизассемблеры IDA Pro и Ghidra, отладчики x64dbg и WinDbg, а также специализированные средства сравнения бинарных файлов, такие как BinDiff и Diaphora.

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

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

• текстовое сравнение с учетом лексем (token-based comparison), позволяющее нивелировать различия в форматировании и именовании переменных;

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

• анализ совпадений в пользовательских интерфейсах, файлах ресурсов, строках локализации;

• оценку уникальности «отпечатков» компиляции и следов использования сторонних библиотек.

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

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

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

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

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

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

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

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

• отсутствие функций, предусмотренных техническим заданием (неполная реализация);

• некорректная реализация функций — когда функция присутствует, но работает не так, как предусмотрено документацией;

• нестабильность работы — сбои, зависания, ошибки при определенных условиях эксплуатации;

• несоответствие производительности заявленным требованиям;

• отсутствие или недостаточность защиты от несанкционированного доступа;

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

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

Экспертиза качества программного обеспечения может проводиться и по стандартизированным методикам. Национальный стандарт ГОСТ Р ИСО/МЭК 25010-2015 определяет модель качества программного продукта, включающую такие характеристики, как функциональная пригодность, производительность, совместимость, удобство использования, надежность, безопасность, сопровождаемость и переносимость. Эксперт может оценивать программный продукт по каждой из этих характеристик, однако такая оценка требует четких критериев и, как правило, применима в случаях, когда договор содержит прямые ссылки на стандарты качества.

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

Раздел 5. Экспертиза авторства и заимствования в программном обеспечении

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

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

Методика экспертизы по делам о заимствовании кода включает следующие этапы.

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

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

Третий этап — собственно сравнение. Применяются различные метрики:

• процент совпадения лексем (токенов) в нормализованных текстах;

• совпадение графов потока управления для функций и процедур;

• совпадение структур данных и их организации;

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

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

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

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

Раздел 6. Исследование вредоносного программного обеспечения

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

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

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

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

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

• программы-вымогатели — программное обеспечение, блокирующее доступ к данным с требованием выкупа;

• шпионские программы — средства скрытого сбора информации о пользователе и его деятельности;

• ботнеты — сети зараженных компьютеров, управляемые удаленно;

• средства несанкционированного доступа — утилиты обхода аутентификации, кейлоггеры, эксплойты.

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

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

Динамический анализ предполагает исполнение программы в песочнице с фиксацией всех действий. Отслеживаются:

• обращения к файловой системе (создание, модификация, удаление файлов);

• изменения в реестре (особенно в ключах автозагрузки);

• сетевые соединения (адреса, порты, протоколы, содержимое пакетов);

• попытки доступа к процессам других программ (инъекции, перехват API);

• изменения в памяти.

Результатом исследования является экспертное заключение, в котором устанавливаются: тип вредоносной программы, ее функциональные возможности, механизмы распространения и сокрытия, характер потенциального ущерба. В уголовном процессе такое заключение служит доказательством объективной стороны преступления, предусмотренного статьями 272–274 УК РФ.

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

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

Уголовные дела о преступлениях в сфере компьютерной информации (статьи 272, 273, 274 УК РФ) составляют значительную часть дел, по которым назначается экспертиза программного обеспечения. Предмет доказывания по этим делам включает установление факта неправомерного доступа к охраняемой компьютерной информации, факта создания или распространения вредоносных программ, факта нарушения правил эксплуатации средств хранения и обработки информации.

Экспертиза программного обеспечения по уголовным делам имеет ряд процессуальных и методических особенностей. Во-первых, объекты исследования часто поступают в виде образов носителей информации, изъятых в ходе следственных действий. Эксперт должен проверить целостность образа (сравнить хеш-суммы, указанные в протоколе изъятия, с фактическими) и зафиксировать результаты проверки в заключении. Нарушение целостности образа может повлечь недопустимость доказательства. Во-вторых, перед экспертом ставятся вопросы, требующие не только технического, но и правового анализа — например, о том, является ли программа вредоносной по смыслу статьи 273 УК РФ. Эксперт не вправе давать юридические заключения, однако он обязан установить технические признаки, которые позволяют суду сделать правовой вывод: несанкционированное уничтожение, блокирование, модификацию или копирование информации, нарушение работы ЭВМ или сети.

Типовые вопросы, разрешаемые экспертизой программного обеспечения по уголовным делам:

• Является ли представленная программа вредоносной? Каковы ее функциональные возможности и механизм действия?

• Содержит ли программа средства несанкционированного доступа к компьютерной информации?

• Каким образом программа распространяется и какие следы оставляет в системе?

• Соответствует ли время и последовательность действий программы, зафиксированные в логах, обстоятельствам дела?

• Имело ли место удаление или модификация информации в результате действия программы?

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

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

Раздел 8. Процессуальное оформление результатов экспертизы программного обеспечения

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

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

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

• процедура создания копий объектов и проверки их целостности (хеш-суммы);

• условия проведения динамического анализа (параметры виртуальной среды, сетевая изоляция);

• перечень использованного программного обеспечения с указанием версий;

• критерии оценки выявленных совпадений или различий;

• ограничения и допущения, принятые экспертом.

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

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

При производстве экспертизы программного обеспечения в Союзе «Федерация судебных экспертов» заключение оформляется в строгом соответствии с требованиями Федерального закона № 73-ФЗ. Организация гарантирует защиту своих заключений в судебных заседаниях: эксперты, проводившие исследование, готовы явиться в суд для дачи пояснений и ответов на вопросы сторон и суда.

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

Кейс 1. Идентификация плагиата в системе управления складом

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

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

Объектами исследования выступили: исходный код программы истца на языке C# (около 450 тысяч строк), исполняемые файлы и исходный код программы ответчика (около 380 тысяч строк). Обе программы были представлены в сопоставимых версиях, соответствующих датам государственной регистрации.

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

На третьем этапе экспертом был проведен анализ графов потока управления для 1 240 функций, входящих в состав обеих программ. Сравнение показало, что 92% функций имеют идентичные или изоморфные графы потоков управления. Для 47 функций совпадение графов было полным, включая уникальные особенности организации ветвлений и циклов, не обусловленные требованиями алгоритма.

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

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

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

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

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

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

Объектом исследования выступил дистрибутив приложения для платформы Android (APK-файл), полученный из официального магазина приложений, а также его более ранняя версия, предоставленная потерпевшим. Дополнительно были представлены серверные логи, изъятые у провайдера, обслуживающего домен, на который, по утверждению заявителя, поступали данные.

Экспертом был проведен статический анализ APK-файла. После декомпиляции в среде JADX был получен Java-код, подлежащий обзору. В ходе анализа манифеста приложения были выявлены разрешения, не соответствующие заявленному функционалу: помимо ожидаемых разрешений на доступ к интернету и хранилищу, приложение запрашивало разрешения на доступ к точному местоположению, контактам, журналу вызовов и SMS-сообщениям.

Дальнейший анализ кода показал наличие обфусцированных классов, имена которых не соответствовали стандартным соглашениям и не коррелировали с заявленной функциональностью. После деобфускации с использованием инструмента на основе анализа потока данных эксперту удалось восстановить логику работы скрытого модуля. Модуль активировался при запуске приложения, собирал следующие данные: GPS-координаты (с периодичностью каждые 15 минут), список контактов, журнал вызовов (номера и длительность), содержимое входящих SMS (за исключением сообщений от банковских отправителей, которые фильтровались). Собранные данные шифровались алгоритмом AES с ключом, жестко закодированным в приложении, и отправлялись методом POST на домен, не связанный с инфраструктурой банка-партнера.

Для подтверждения статических выводов был проведен динамический анализ. Приложение было запущено на эмуляторе Android с перехватом трафика через прокси-сервер (mitmproxy). Перехваченные пакеты подтвердили наличие зашифрованных POST-запросов на выявленный домен; после извлечения ключа шифрования из кода приложения эксперт расшифровал содержимое пакетов и установил, что передаваемые данные соответствуют структуре, восстановленной при статическом анализе.

Сопоставление с серверными логами, представленными провайдером, показало, что объем переданных данных за трехмесячный период составил approximately 12 мегабайт, включая записи о местоположении (около 8 600 точек), полные списки контактов (в среднем 340 записей на устройство) и журналы вызовов. Получателем данных являлась компания, зарегистрированная в офшорной юрисдикции, не связанная с банком-партнером.

Эксперт пришел к выводу: приложение содержит скрытый модуль, осуществляющий сбор и передачу персональных данных, не предусмотренных пользовательским соглашением и не очевидных для пользователя; функционал модуля не соответствует заявленному назначению приложения. Заключение экспертизы программного обеспечения легло в основу обвинения по статье 137 УК РФ (нарушение неприкосновенности частной жизни) и статьи 272 УК РФ (неправомерный доступ к компьютерной информации).

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

Государственное учреждение заключило контракт с ООО «ИнфоСистемс» на разработку аналитической платформы для обработки данных мониторинга. Стоимость контракта составила 28 миллионов рублей. По завершении работ заказчик отказался от приемки, ссылаясь на то, что программный продукт не соответствует требованиям технического задания. Исполнитель обратился в арбитражный суд с требованием о взыскании оплаты.

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

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

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

Результаты тестирования показали следующее распределение: из 94 требований полностью реализованы 52 (55%), частично реализованы 21 (22%), не реализованы 21 (22%). К числу нереализованных относились, в частности: модуль прогнозирования нагрузки на основе исторических данных, подсистема уведомлений с настраиваемыми правилами, экспорт отчетов в формате, отличном от предусмотренного (требовался формат XLSX, реализован только CSV). Частично реализованные требования включали функцию фильтрации данных (фильтрация работала по меньшему числу полей, чем предусмотрено ТЗ), модуль интеграции с внешней системой (интеграция была односторонней, тогда как ТЗ предусматривало двусторонний обмен).

Отдельно экспертом была проверена работоспособность реализованных функций под нагрузкой. Тестирование показало, что при количестве одновременных пользователей, превышающем 50 (требование ТЗ — не менее 200), платформа становилась неработоспособной: время отклика возрастало с 0,8 секунды до более чем 30 секунд, после чего следовал отказ в обслуживании. Анализ серверной части (исходный код был частично предоставлен) выявил причину: отсутствие индексирования в базе данных для ключевых запросов и неоптимальный алгоритм кэширования.

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

Кейс 4. Установление факта использования open-source кода в коммерческом продукте

Компания «Альфа-Софт» выпустила на рынок коммерческий продукт — систему электронного документооборота. Правообладатель библиотеки для работы с PDF-документами, распространяемой под лицензией GPL v3, обратился в суд с иском о нарушении условий лицензии. Истец утверждал, что ответчик использовал его библиотеку в своем продукте, но не открыл исходный код производного произведения, как того требует GPL.

Перед экспертом были поставлены вопросы: содержит ли программный продукт ответчика код библиотеки истца; каким образом произошло включение библиотеки в продукт (динамическая или статическая линковка); является ли продукт ответчика производным произведением по смыслу GPL v3.

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

Экспертом был проведен анализ состава дистрибутива. Установочный пакет содержал исполняемые файлы (.exe) и библиотеки (.dll), а также файлы ресурсов. Среди библиотек была обнаружена DLL, имя которой не соответствовало соглашениям об именовании, принятым в проекте ответчика, но совпадало с именем библиотеки истца в ее оригинальной сборке.

Сравнительный анализ бинарных файлов показал полное совпадение секции .text (кода) и .rdata (данных только для чтения) исследуемой DLL с библиотекой истца, собранной из оригинального исходного кода версии 2.4.1. Хеш-сумма SHA-256 совпадала полностью. Дополнительно в секции .rdata были обнаружены строки, содержащие копирайт истца и текст лицензионного уведомления GPL v3.

Далее экспертом был исследован вопрос о способе линковки. Анализ таблицы импортов основного исполняемого файла продукта ответчика показал, что он импортирует функции из обнаруженной DLL. При этом DLL присутствовала в дистрибутиве как отдельный файл, что указывало на динамическую линковку. Однако экспертом было установлено, что продукт ответчика не работает без этой DLL: при ее удалении программа завершалась с ошибкой загрузки. Более того, анализ кода показал, что функции библиотеки вызываются из основного исполняемого файла напрямую, без промежуточного слоя абстракции, который мог бы рассматриваться как отдельный модуль.

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

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

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

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

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

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

Статический анализ драйвера начался с изучения его структуры. Драйвер был скомпилирован без отладочных символов; секция .text содержала обфусцированный код, секция .data — данные, часть которых была зашифрована. Анализ таблицы импортов показал наличие функций, типичных для драйверов клавиатур (чтение IRP-запросов), а также функций работы с сетью (WskSocket, WskSendTo), что было аномальным для драйвера клавиатуры.

Для деобфускации и понимания логики работы драйвера экспертом был применен динамический анализ. Драйвер был загружен в изолированную виртуальную машину (Windows 10 x64) с включенным журналированием всех действий. Эксперт инициировал нажатия клавиш на виртуальной клавиатуре и отслеживал поведение драйвера. Перехват IRP-запросов подтвердился: драйвер регистрировал все нажатия и отпускания клавиш, включая служебные комбинации.

Дальнейший анализ показал, что перехваченные данные буферизовались в памяти драйвера, а затем, при накоплении определенного объема, отправлялись через сетевой сокет на IP-адрес, зарегистрированный в одной из стран Юго-Восточной Азии. Трафик был обфусцирован: данные подвергались операции XOR с ключом 0xAB, после чего упаковывались в UDP-пакеты и отправлялись на порт 53 (DNS), что маскировало трафик под легитимные DNS-запросы и затрудняло обнаружение сетевыми средствами мониторинга.

Экспертом был восстановлен алгоритм обфускации и произведена расшифровка перехваченного трафика. Анализ содержимого пакетов показал, что передаваемые данные включают последовательности нажатий клавиш с временными метками. Объем переданных данных за период наблюдения (72 часа) составил около 4,7 мегабайта, что соответствовало approximately 1,2 миллиона нажатий клавиш.

Дополнительно экспертом были исследованы артефакты установки драйвера в системе. Анализ реестра показал, что драйвер был зарегистрирован как служба с именем, имитирующим системный компонент («kbdclass2» вместо стандартного «kbdclass»), и настроен на автоматический запуск. Файл драйвера был размещен в директории C:\Windows\System32\drivers, время создания файла соответствовало периоду, когда подозреваемый имел административный доступ к компьютеру.

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

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

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

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

Объектами исследования выступили: исходный код программного продукта (версия, выпущенная при жизни разработчика, около 120 тысяч строк на C++), исходный код, представленный наследником, претендующим на соавторство (около 15 тысяч строк), а также исполняемый файл продукта, распространявшийся коммерчески.

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

Для создания стилометрического профиля умершего разработчика экспертом были использованы несколько его более ранних проектов с открытым исходным кодом (три проекта, суммарно около 80 тысяч строк), а также фрагменты коммерческого продукта, авторство которых не оспаривалось. Анализ выявил следующие характерные особенности: использование имен переменных в стиле lowerCamelCase с сокращениями до 3–4 символов; предпочтение циклов for перед while; обработка ошибок через возврат кодов вместо исключений; комментарии на русском языке с характерными оборотами; использование типа int для всех целочисленных переменных, включая счетчики циклов (вместо size_t).

Аналогичный профиль был построен для наследника, претендующего на соавторство, на основе его публичных репозиториев (около 30 тысяч строк). Его стиль характеризовался: использованием snake_case для имен переменных; активным применением исключений; комментариями на английском языке; предпочтением auto для вывода типов.

Сравнительный анализ представленного наследником фрагмента (15 тысяч строк) показал, что его стиль полностью соответствует профилю наследника и существенно отличается от профиля умершего разработчика. В частности, все имена переменных соответствовали snake_case, обработка ошибок производилась через исключения, комментарии были на английском. Совпадение стилометрических характеристик с профилем наследника составило 94% по выбранным метрикам.

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

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

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

Кейс 7. Экспертиза программы для ЭВМ по делу о нарушении лицензионного соглашения

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

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

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

Экспертом была произведена проверка целостности файлов программы на каждом из трех объектов. Для этого вычислялись хеш-суммы всех исполняемых файлов и библиотек и сравнивались с эталонными значениями. На объекте №1 (предусмотренном лицензией) все хеш-суммы совпали с эталонными, за исключением файлов конфигурации, что было допустимо. На объектах №2 и №3 были обнаружены расхождения: хеш-суммы основного исполняемого файла и трех библиотек отличались от эталонных.

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

Объем модификаций составил approximately 12% от общего объема кода программы (по оценке на основе дизассемблирования). Модификации носили целенаправленный характер и требовали глубокого понимания архитектуры продукта.

Дополнительно экспертом были исследованы журналы лицензирования, которые программа вела на каждом объекте. Журналы содержали записи о запусках программы с указанием идентификаторов оборудования. Анализ показал, что программа на объектах №2 и №3 запускалась с теми же лицензионными ключами, что и на объекте №1, что нарушало условие лицензии об использовании на одном объекте.

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

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

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

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

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

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

Дизассемблирование и анализ перекрестных ссылок позволили локализовать функцию, инициирующую сетевые соединения. Функция активировалась при наступлении определенного события (запуск программы в определенное время суток) и выполняла следующие действия: собирала информацию о конфигурации системы (версия ОС, имя компьютера, имя пользователя, список установленного программного обеспечения), формировала XML-документ и отправляла его методом POST на домен, зарегистрированный на физическое лицо. Ответ сервера обрабатывался: при получении определенной команды программа могла загрузить и исполнить дополнительный код.

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

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

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

Кейс 9. Экспертиза программы для ЭВМ в споре о качестве разработки

Частная компания заказала у студии разработки мобильное приложение для заказа услуг (аналог агрегатора). Стоимость разработки составила 4,5 миллиона рублей. После сдачи приложения заказчик обнаружил, что оно работает нестабильно на значительной части устройств целевой аудитории, а также содержит уязвимости, позволяющие получить несанкционированный доступ к данным пользователей. Заказчик обратился в суд с требованием о соразмерном уменьшении цены и возмещении убытков.

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

Объектами исследования выступили: дистрибутив приложения (APK для Android, IPA для iOS), исходный код (предоставлен ответчиком по требованию суда), техническое задание, договор, а также отчеты о сбоях, собранные заказчиком в процессе эксплуатации.

Экспертом был проведен анализ стабильности работы приложения. Тестирование проводилось на 15 моделях устройств различных производителей с разными версиями операционных систем (Android 8–14, iOS 14–17). На 6 моделях из 15 (40%) приложение демонстрировало сбои: на трех моделях — при запуске (краш через 2–5 секунд после открытия), на двух моделях — при выполнении операции заказа (потеря данных при переходе между экранами), на одной модели — при работе с картой (утечка памяти, приводящая к замедлению работы устройства).

Анализ исходного кода выявил причины дефектов. Краши при запуске были обусловлены использованием API, не поддерживаемых на старых версиях Android, без проверки версии. Потеря данных происходила из-за отсутствия сохранения состояния активности при повороте экрана. Утечка памяти была вызвана циклическими ссылками в компонентах работы с картой.

Отдельно экспертом была проведена проверка безопасности приложения. Анализ выявил критические уязвимости:

• данные аутентификации (токены) сохранялись в открытом виде в локальном хранилище, доступном другим приложениям на устройстве;

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

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

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

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

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

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

Объектами исследования выступили: база данных истца (SQL-дамп, около 8 миллионов записей о юридических лицах), база данных ответчика (SQL-дамп, около 6 миллионов записей), а также логи доступа к серверу истца и логи веб-сервера ответчика, представленные по запросу суда.

Экспертом был проведен сравнительный анализ баз данных. Сопоставление производилось по ключевому полю (ИНН организации). Было установлено, что 5,8 миллиона записей базы ответчика (97% от ее объема) полностью совпадают с записями базы истца по всем полям, включая не только официальные данные (наименование, адрес, ИНН, ОГРН), но и дополнительные сведения, добавленные истцом в результате собственной обработки: контактные данные (телефоны, email), классификация видов деятельности, комментарии и примечания.

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

Анализ логов сервера истца показал, что в течение трех месяцев, предшествовавших появлению базы ответчика, с IP-адресов, принадлежащих ответчику, производились систематические запросы к серверу истца. Запросы следовали с регулярностью approximately 1 запрос в 2 секунды и охватывали весь диапазон идентификаторов организаций. Характер запросов (последовательный перебор, отсутствие пользовательской сессии, использование скрипта) указывал на автоматизированный сбор данных (парсинг).

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

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

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

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

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

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

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

Контакты Союза «Федерация судебных экспертов»: Москва, 115114, Кожевнический проезд, д. 3. Телефон: +7 (495) 666-5-666. Для звонков из регионов: +7 (800) 555-0-453. Круглосуточная поддержка: +7 (995) 100-33-55. Электронная почта: info@fse.ms.

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