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

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

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

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

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

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

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

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

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

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

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

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

• сохраните зеркальную копию репозитория со всеми доступными ссылками, ветками, метками и достижимой историей; при споре о переписывании истории отдельно фиксируют серверное хранилище и журналы сервиса. Если системы контроля версий не было, сохраните каталог с исходными текстами целиком;
• сохраните исполняемые файлы спорной версии ровно в том виде, в каком они работают, и связанную отладочную информацию: PDB в Windows, встроенные либо отдельные файлы в Linux и каталог .dSYM в macOS;
• зафиксируйте сборочную среду: точные версии и контрольные суммы компилятора, компоновщика и других средств, SDK, системные и сторонние библиотеки, генератор и сценарии сборки, параметры, переменные, операционную систему, архитектуру, локаль, пути и операции после сборки. Полезно сохранить образ машины или контейнера вместе с файлами описания сборки (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 обычно используют файл PDB, в Linux — встроенные или отдельные отладочные файлы, в macOS — каталог .dSYM.

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

Отладочную информацию сверяют со спорной программой. При наличии используют PDB GUID/age, ELF build ID, Mach-O UUID или другой идентификатор; иначе сопоставляют контрольные суммы, метаданные модулей и прочие признаки. Данные от иной сборки могут показать правдоподобные, но неверные имена и строки. Так же проверяют соответствие снимка памяти исполняемому файлу и загруженным модулям.

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

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

В C++ неопределённое поведение особенно существенно при анализе отказов.

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

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

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

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

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

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

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

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

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

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

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

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

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

C++ применяют в микроконтроллерах (STM32, решения на ядре ARM, AVR), промышленных компьютерах и отдельных компонентах оборудования. Объектом может быть прошивка контроллера или прикладная программа. Язык программ ПЛК вроде Siemens SIMATIC и систем на CODESYS устанавливают отдельно: там часто используются иные специализированные языки. Для анализа взаимодействия сохраняют записи обмена по Modbus, PROFINET, CANopen, OPC UA. Исследовать приходится и программу, и связанное с ней устройство.

Способ получения зависит от платформы: файл поставки, штатная выгрузка, загрузчик, JTAG или SWD, программатор, средства вроде OpenOCD либо аппаратное извлечение памяти. Файл обновления может отличаться от содержимого устройства. Отладочный интерфейс открывает только доступные области, поэтому фиксируют карту памяти, внешние носители, конфигурацию защиты и пределы полноты образа. Любое вмешательство требует оценки риска остановки или повреждения.

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

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

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

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

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

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

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

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

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

Границы обычно проводят так:

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

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

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

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

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

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

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

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

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

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

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

Состав объектов зависит от вопросов, но обычно включает две группы.

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

Основные объекты — исходные материалы и результаты сборки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исследование проводят в одном из нескольких форматов; выбор зависит от стадии спора:

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

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

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

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

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