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

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

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

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

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

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

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

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

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

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

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

Delphi компилирует исходный текст в машинный код. Из исполняемого файла можно получить дизассемблированное или приближённое представление, но не первоначальную программу на Object Pascal с её комментариями, именами и разбиением по файлам. В этом Delphi ближе к C++, чем к платформам с промежуточным кодом.

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

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

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

Что сделать сегодня, пока следы не стёрлись

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

Способ копирования зависит от СУБД, версии и режима эксплуатации. Файл работающей базы нельзя копировать как обычный документ без подтверждения целостности. В Firebird один из предусмотренных механизмов использует nbackup -L перед файловой копией и nbackup -UN после неё. Команды выполняет администратор по документации именно к установленной версии, с резервной копией, окном работ и планом восстановления. В других случаях применяют штатное резервное копирование, снимок согласованного уровня или корректную остановку сервиса.

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

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

Порядок действий такой:

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

Что собрать, кроме базы:

• каталог установленной программы целиком — с исполняемым файлом, всеми библиотеками рядом с ним, файлами настроек и шаблонами печатных форм; если программа собрана с внешними пакетами, часть кода и форм лежит в отдельных файлах рядом, и без них объект неполон;
• дистрибутив, которым программу устанавливали, и сохранившиеся обновления — они помогают сопоставить версии вместе с документами и журналами;
• если исходный текст у вас есть, копию всего каталога проекта, включая файлы форм и файл проекта, а не только файлы с кодом;
• сведения о базе: производитель, версия, архитектура и параметры сервера. Совместимость копии и способ восстановления зависят от версии и формата, поэтому эти сведения нужны для стенда;
• сведения об аппаратном ключе защиты, если программа его требует. Необходимость и последствия перемещения ключа с рабочего сервера предварительно оценивают совместно с владельцем системы; для стенда согласуют отдельный порядок;
• контрольные суммы архивов, вычисленные сразу и внесённые в защищённый журнал передачи. Они позволяют позднее проверить соответствие файлов записанным значениям, но сами не подтверждают источник и дату. В Windows используют PowerShell: Get-FileHash архив.zip -Algorithm SHA256; начиная с Vista доступна команда certutil -hashfile архив.zip SHA256; в Linux — sha256sum архив.zip. Перенос на другой компьютер документируют.

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

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

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

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

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

Версия среды и набор компонентов: почему исходники не собираются

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

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

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

Сторонние компоненты и их условия использования

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

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

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

База данных: где живёт половина логики

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

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

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

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

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

Для сравнения выбирают признаки, сохраняющиеся в сборке:

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

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

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

Как устанавливают возраст спорной версии

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

Опираются на такие следы:

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

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

Следы миграции: что ломается при переносе старой системы

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

Смотреть нужно как минимум сюда:

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

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

Отказы, зависания и рост потребления памяти

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

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

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

Сравнение двух программ на Delphi

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

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

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

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

Когда исполнителя уже нет

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

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

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

Какие обстоятельства устанавливают по программе на Delphi

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

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

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

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

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

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

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

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

Что просят прислать по спору о системе на Delphi

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

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

Сначала идентифицируют программу и материалы сборки:

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

База и площадка: где система хранит накопленное

Затем собирают данные и сведения о площадке:

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

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

Пароли внутри программы: как отдать материалы и не открыть систему

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

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

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

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

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

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

Как идёт работа: от приёмки материалов до выводов

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

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

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

Как формулируют вопросы по программе на Delphi

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

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

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

Форматы работы: что выбирают по старым системам

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

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

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

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

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

Из чего складываются стоимость и срок

Стоимость и срок зависят прежде всего от состояния объектов и подготовки стенда.

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

Для старой системы может потребоваться изолированная среда с совместимой версией Windows, СУБД, драйверами, компонентами и аппаратной защитой. Возможность безопасного воспроизведения и объём подготовки оценивают отдельно.

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

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

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

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

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