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

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

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

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

С какими спорами приходят по программам на C++

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

Типичные ситуации выглядят так:

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

Если спор идёт не о программе, а об устройстве, на котором она работает, — о его исправности, комплектности или следах вмешательства, — начните с аппаратно-компьютерной экспертизы.

Что сохранить, пока сборочная среда цела

В других языках первым исчезает опубликованный результат. В C++ — сама возможность собрать программу заново: машины разработчиков переустанавливают, сервер сборки перенастраивают, старые версии Visual Studio, GCC и Clang снимают с поддержки — и через полгода воспроизвести спорную сборку уже не из чего.

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

• снимите архивом полную копию репозитория — хранилища исходных текстов, где сохраняется каждая правка, чаще всего это Git, — со всей историей, ветками и метками; если системы контроля версий не было, заберите каталог с исходными текстами целиком;
• сохраните исполняемые файлы спорной версии ровно в том виде, в каком они работают, и, если есть, отладочную информацию к ним — отдельные файлы формата PDB в Windows или встроенные отладочные данные в Linux и macOS;
• запишите сборочную среду: версии компилятора и вспомогательных программ, файлы описания сборки (CMakeLists, Makefile, файлы проекта Visual Studio), состав и версии библиотек. Надёжнее всего сохранить не перечень, а образ машины или контейнера сборки целиком — полную копию диска вместе с установленными программами, — пока он ещё существует;
• заберите записи сервера сборки за спорный период и снимки памяти аварийно завершившихся процессов, если они сохранялись;
• посчитайте контрольную сумму каждого архива и запишите её отдельным документом. Контрольная сумма — это короткая строка, которую вычисляют из содержимого файла: изменится в нём хоть один знак, изменится и она, поэтому записанная сегодня сумма позволяет завтра доказать, что архив не подменяли. В Windows её считает PowerShell командой Get-FileHash архив.zip -Algorithm SHA256, в обычной командной строке — certutil -hashfile архив.zip SHA256; в Linux — sha256sum архив.zip, в macOS — shasum -a 256 архив.zip;
• составьте короткую записку: что именно сохранено, откуда, когда, под какой учётной записью и кто присутствовал.

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

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

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

Почему по C++ спор начинается с того, передан ли исходный код

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

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

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

Что можно установить по готовой программе, когда исходников нет

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

По исполняемому файлу устанавливают:

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

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

Почему один и тот же исходный текст даёт разные исполняемые файлы

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

Причин расхождения много, и почти все — не в содержании кода. Разные версии GCC, Clang или компилятора Visual Studio порождают разный машинный код из одного текста. То же делают настройки оптимизации, разрядность, целевая система, версия компоновщика и порядок, в котором ему подали файлы. Многие сборки записывают внутрь файла дату и время, имя машины и пути к исходникам. Путь попадает не в сам машинный код, а в отладочные данные, в сообщения об ошибках и — в сборках под Windows — в служебную запись о расположении файла отладочной информации внутри самой программы; поэтому удаление отладочных данных пути не убирает. Добавьте языковые настройки системы, служебные сведения внутри библиотек и цифровую подпись, которую ставят уже после сборки. Побайтового совпадения добиться можно — этим занимается отдельное направление, воспроизводимые сборки, — но проект к нему готовят заранее; в обычной разработке на такое не рассчитывают, и на несовпадении файлов ничего не построишь.

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

Отключение отладочных проверок убирает часть строк, и это учитывают отдельно

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

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

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

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

Отладочная информация: что она даёт и почему её обычно нет

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

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

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

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

Неопределённое поведение: программа работает не потому, что она правильная

Это особенность C++, которой нет у большинства других языков, и в спорах о качестве она объясняет больше всего.

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

Для спора это значит две вещи. Первый: «программа работала три года» не доказывает, что она сделана правильно, — правильность и наблюдаемая работоспособность в C++ разные вещи. Второй, обратный: отказ после обновления окружения не означает, что дефект внёс тот, кто обновлял. Что здесь может эксперт: установить, есть ли в коде ошибка описанного класса, воспроизводится ли отказ при исходных настройках сборки и при новых, связан ли он с найденной ошибкой. Такие ошибки ловят при выполнении программы. Санитайзеры GCC и Clang находят обращение к освобождённой памяти, выход за границы и переполнение знаковых целых. Анализаторы вроде Valgrind работают без пересборки, но переполнения целых не видят. Все они динамические: ошибку они видят только на том пути, который программа реально прошла на испытании. Поэтому найденная ошибка — факт, а ненайденная не означает, что её нет, и в заключении это оговаривают. Вину между сторонами эксперт не распределяет — это дело суда. Он даёт проверяемые факты; кто и за что отвечает по договору, решает суд.

Аварийные завершения, зависания и рост потребления памяти

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

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

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

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

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

Библиотеки, статическая сборка и условия их использования

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

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

Условия использования библиотеки записаны в её лицензии — MIT, BSD, Apache, GPL, LGPL, у Boost собственная, и другие. Эксперт устанавливает факты: какая библиотека какой версии использована, каким способом подключена и каким лицензионным документом сопровождается; текст этого документа приводится в заключении дословно. Способ подключения — тоже факт, и его фиксируют. А что из условий лицензии следует для прав на программу и нарушены ли они, эксперт не решает: толкование условий и правовая оценка — за судом.

Если объект — прошивка, контроллер или промышленная линия

Значительная часть споров по C++ приходится на программы, которые работают не на обычном компьютере: станки с числовым программным управлением (ЧПУ), производственные линии, приборы учёта, охранные и медицинские устройства, бортовые системы. Такие программы называют прошивками — они записаны в память самого устройства, — а исполняются они на микроконтроллерах (STM32, микроконтроллеры на ядре ARM, AVR), на программируемых логических контроллерах (ПЛК) вроде Siemens SIMATIC или систем на CODESYS и на промышленных компьютерах, часто под управлением операционных систем реального времени — FreeRTOS, QNX, VxWorks. Обмен между ними идёт по промышленным протоколам: Modbus, PROFINET, CANopen, OPC UA, и разбор спорного взаимодействия нередко начинается именно с записей этого обмена. Объект здесь двойной: устройство и записанная в него программа.

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

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

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

Работы на действующем оборудовании: как это согласуют

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

До выезда согласуют несколько вещей:

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

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

Если в проекте не только C++

Крупные системы редко пишут на одном языке: вокруг расчётного ядра на C++ вырастают интерфейс, сервисы и обмен, написанные на других языках. Границу исследования лучше провести до постановки вопросов, иначе эксперт получит поручение шире своей задачи.

Обычно её проводят так:

• спор о расчётном ядре, драйвере, обработке сигналов, работе с оборудованием или производительности: это как раз тема страницы, которую вы читаете;
• спор о серверной части корпоративной системы или об обмене документами: экспертиза кода на Java;
• спор о воспроизводимости расчёта в обработке данных и отчётности: экспертиза кода на Python;
• спор о поведении интерфейса в браузере: экспертиза кода на JavaScript;
• спор о сайте или интернет-магазине: экспертиза кода на PHP.

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

Что устанавливает эксперт по коду на C++

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

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

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

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

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

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

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

Какие объекты исследуются в споре о программе на C++

Перечень зависит от вопросов, но по этому направлению набор устойчив. Разделим его на две части.

Исходный код и то, что из него получается

Основной материал — то, из чего программа получается и во что превращается:

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

Следы выполнения и документы проекта

Материал, по которому восстанавливают ход событий и требования:

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

Как передать исходники и сборочную среду

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

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

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

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

Порядок исследования программы на C++

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

1. Принимаются материалы, фиксируется их состав и контрольные суммы; описывается, откуда и когда получена каждая копия.
2. Воспроизводится сборочная среда; выполняются контрольные сборки и определяется уровень шума сравнения.
3. Устанавливается, чем является переданное: собирается ли из него программа и та ли это программа, о которой идёт спор.
4. Проверяют, относятся ли вспомогательные материалы к этому объекту: отладочная информация и снимки памяти сверяются с идентификатором спорной сборки.
5. По каждому проверяемому требованию выполняется проверка выбранным способом; условия получения результата фиксируются.
6. Проверяются альтернативные объяснения обнаруженного: настройки среды, данные, действия третьих лиц, особенности оборудования.
7. Формулируются выводы в пределах поставленных вопросов; перечисляются ограничения и то, что установить не удалось.

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

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

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

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

1. Является ли содержимое архива с контрольной суммой SHA-256 … исходным текстом программы, представленной исполняемым файлом …; возможно ли получить из него работоспособную программу и какие компоненты для этого необходимы?
2. Соответствует ли программа, полученная сборкой из архива …, требованиям пунктов … технического задания (приложение № … к договору от …)?
3. Какие сторонние библиотеки использованы в программе …, каким способом они подключены и какими лицензионными документами сопровождаются?
4. Какова причина аварийного завершения программы …, зафиксированного в снимке памяти … при сценарии, описанном в …?
5. Имеются ли в исходных текстах архива … и архива … совпадения, не объясняемые использованием общих библиотек, стандартных конструкций языка и сгенерированного кода?
6. Чем версия программы, представленная файлом …, отличается от версии, представленной файлом …, в части реализации функций, указанных в пунктах … технического задания?

В каком виде можно получить результат

Задача решается в одном из нескольких форматов, и выбор зависит от стадии спора:

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

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

От чего зависят стоимость и срок по проекту на C++

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

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