Судебная экспертиза исходного кода на Java

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

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

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

Когда нужна экспертиза системы на Java

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

Исследование помогает в таких случаях:

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

Если ваш вопрос звучит иначе, лучше начать с соседнего исследования: о качестве кода — экспертиза качества исходного кода, о заимствовании — сравнение исходного кода, о деньгах и объёме — экспертиза объёма и стоимости выполненных работ. Если спорная система написана на другом языке, начните с экспертизы исходного кода на Python; если спор о браузерной части сайта или о сервере на Node.js — с экспертизы исходного кода на JavaScript.

Чем это отличается от аудита кода и от общей компьютерной экспертизы

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

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

Из чего состоит корпоративная система на Java

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

В типичной системе отдельно исследуют:

• Прикладной каркас — чаще всего Spring и Spring Boot; встречаются также приложения Jakarta EE на WildFly и веб-приложения в контейнере сервлетов Tomcat. Значительная часть поведения задаётся не строками кода, а конфигурацией: профилями окружений, файлами настроек, условиями включения отдельных механизмов. Одна и та же сборка на двух стендах — то есть на двух отдельных площадках, где система развёрнута, — может работать по-разному, поэтому конфигурацию исследуют вместе с кодом.
• Работа с базой данных — Hibernate или другая реализация JPA, отображающая объекты программы на таблицы, и пул соединений вроде HikariCP. Часть дефектов видна уже при чтении отображений и на небольшом стенде: лишние обращения к базе при обходе связанных объектов, неверные границы транзакций, каскадные удаления, расхождение схемы и отображения. На промышленных объёмах последствия становятся серьёзнее: то, что незаметно на сотне записей, останавливает работу на миллионах.
• Изменения структуры базы данных — сценарии миграций Liquibase или Flyway и служебная таблица, в которой инструмент отмечает применённые изменения: DATABASECHANGELOG или flyway_schema_history. По ним восстанавливают, что и когда меняли в схеме.
• Обмен сообщениями — Kafka, RabbitMQ и подобные. Исследуют устройство очередей, работу потребителей и значения смещений — отметок о том, до какого места потребитель дочитал поток сообщений. Проверяют также повторную обработку и очередь недоставленных сообщений — отдельное место, куда складывают то, что обработать не удалось, если такая очередь предусмотрена.
• Обмен с другими системами — бухгалтерскими, банковскими, государственными, партнёрскими. Проверяют соответствие фактического обмена описанному контракту, обработку повторов и ошибок, согласование версий.
• Среда выполнения — сервер приложений или контейнеры Docker под управлением Kubernetes, ограничения по памяти и процессору, параметры виртуальной машины Java. Несогласованность ограничений среды и настроек виртуальной машины — обычная причина перезапусков, которую ошибочно приписывают коду.
• Наблюдаемость — журналы приложения через Logback или Log4j, измеряемые показатели работы, сквозные идентификаторы запросов, журналы сборки мусора, записи Java Flight Recorder, дампы потоков и кучи. Это основные материалы для исследования сбоев и деградации.

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

Что может установить эксперт

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

Задачи обычно распадаются на три группы:

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

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

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

Как проверяют соответствие техническому заданию

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

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

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

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

Если исходный код вам не передали или он неполон

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

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

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

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

Какие объекты исследуются

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

Исходный код и история репозитория

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

Исследуются такие материалы:

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

Сборка, артефакты и байт-код

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

К этой группе относятся:

• файлы описания сборки для Maven или Gradle — pom.xml и build.gradle, — включая многомодульные проекты и общее управление версиями библиотек через BOM;
• архивы JAR, WAR, EAR, служебные записи внутри них, образы контейнеров и установочные комплекты;
• class-файлы и их разбор штатной утилитой javap: по номеру формата видно, для какой версии платформы предназначен каждый класс;
• отладочная информация — таблицы номеров строк и имён переменных, от которых зависит, насколько подробно можно прочитать восстановленный текст;
• сведения из внутреннего хранилища артефактов — Nexus или Artifactory: что и когда публиковалось и загружалось.

Номера формата оценивают с оговорками. В одном архиве обычно лежат классы разных версий, потому что каждая вложенная библиотека может быть собрана под свою версию Java. Поэтому исследуют классы самого приложения. Номер формата показывает минимальную версию JVM, которая распознаёт такой class-файл. Сам по себе он не доказывает, что приложение запустится, и не определяет, каким JDK его собирали. Отсутствие имён переменных тоже само по себе ни на что не указывает: так бывает и при определённой настройке сборки, и после обработки средством запутывания кода, и когда класс создан на этапе сборки.

Конфигурация, база данных и данные

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

Сюда входят:

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

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

Журналы, сообщения, показатели и дампы

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

Сюда входят:

• журналы приложения и сервера, сообщения об ошибках вместе с цепочкой вызовов, сквозные идентификаторы запросов;
• выгрузки сообщений, сведения о смещениях потребителей и об очереди недоставленных сообщений, если она настроена;
• измеряемые показатели работы, записи сквозной трассировки, то есть прослеживания запроса через все сервисы, и журналы сборки мусора;
• дамп потоков, снятый через jstack, — снимок того, чем были заняты потоки программы, и дамп кучи из jmap — снимок объектов, которые программа держала в памяти;
• отчёты тестов JUnit и интеграционных прогонов на Testcontainers, данные об охвате кода из JaCoCo, отчёты анализаторов — SonarQube, Checkstyle, SpotBugs, PMD, Error Prone — и результаты нагрузочных испытаний;
• журналы сборочной системы, отметки о развёртывании и результаты приёмочных проверок.

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

Как сохранить материалы для исследования

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

До передачи материалов эксперту сделайте следующее:

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

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

Что передавать и как защитить данные

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

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

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

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

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

Как проводится исследование

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

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

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

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

Java-код мобильных приложений исследуют с учётом их формата; подробнее об этом — на странице экспертизы мобильных приложений.

Примеры вопросов на экспертизу

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

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

1. Каковы состав и структура представленной системы: модули и сервисы, использованные платформы и библиотеки, схема базы данных, точки обмена с другими системами?
2. Реализована ли в представленной версии системы функция, описанная в указанном пункте технического задания, и в каком объёме?
3. Достаточен ли переданный комплект исходных текстов, настроек и документации для самостоятельной сборки и развёртывания системы, и чего в нём не хватает?
4. Воспроизводится ли представленная сборка из представленных исходных текстов с указанными инструментами, зависимостями и параметрами; если нет, какие расхождения обнаруживаются?
5. Какие технические причины отказа или замедления работы системы в указанный период подтверждаются представленными журналами, показателями и дампами?
6. Каковы показатели работы представленной версии системы при выполнении указанной операции на представленных данных и соответствуют ли они требованиям, названным в указанном пункте технического задания или соглашения об уровне обслуживания?
7. Отражено ли в представленных источниках прохождение указанных документов между системами? Если да, на каком этапе отражено прекращение их обработки?
8. Какие изменения структуры базы данных выполнялись в указанный период согласно представленным сценариям и журналам, и как они соотносятся с состоянием данных?
9. Имеются ли в исходных текстах двух представленных систем совпадающие фрагменты и каковы их объём и характер после исключения сторонних библиотек и сгенерированного кода?
10. Какие изменения в указанных модулях отражены в истории представленного репозитория за заданный период?

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

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

Форматы работы

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

Доступны такие форматы:

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

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

Что вы получите и как использовать результат

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

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

От чего зависят стоимость и срок

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

При первом обращении опишите спор, наметьте вопросы и перечислите, что у вас есть: репозитории, сборки, настройки стендов, журналы, договор и техническое задание. Небольшой доступный вам документ, например договор или задание, можно приложить к заявке. Код, журналы и доступы передают после согласования безопасного канала. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — мы проверим, относится ли задача к нашей компетенции, предложим безопасный порядок передачи материалов и скажем, каких данных не хватает для расчёта.