В споре об учётной системе, настольной программе или веб-сервисе на C# обычно проверяют соответствие результата заданию и состав переданного. Многие сборки .NET содержат промежуточный код IL и метаданные типов. Декомпилятор может восстановить по ним читаемое представление классов и методов, но не первоначальный исходный текст. Состав публикации проверяют по файлам: ReadyToRun может сочетать IL и машинный код, а Native AOT, доступный начиная с .NET 7, создаёт платформенный машинный код без обычного набора IL для декомпиляции. Поэтому наличие машинного кода само по себе не определяет возможность восстановления. Экспертиза исходного кода на C# — специализированное направление экспертизы процесса разработки программного обеспечения. В зависимости от процедуры результатом будет заключение судебного эксперта или документ внесудебного исследования; доказательственное значение оценивает суд.
Если спор уже начался, сохраните то, что удаляют первым. Собранные файлы программы — их называют сборками — обычно остаются целы: они установлены у вас и работают. Быстрее исчезает другое: доступ к хранилищу исходных текстов, записи сервера сборки, содержимое площадки, где программа развёрнута. Что именно сохранять, разобрано ниже, в разделе «Что сохранить, пока сборки и история на месте».
Начать можно с разговора, и он бесплатный: назовите систему, опишите спор и перечислите, что у вас на руках. Пока ничего собирать и никуда загружать не нужно — порядок передачи материалов мы предложим отдельно, когда станет понятно, какие из них вообще потребуются.
С какими спорами приходят по программам на C#
Обращаются, когда разногласия касаются проверяемых обстоятельств: состава переданных материалов, поведения программы при заданных условиях и зафиксированного хода работ. До исследования определяют спорные версию, площадку и период.
Типичные ситуации выглядят так:
- подрядчик сдал учётную или складскую систему, настольную программу на WinForms или WPF либо веб-сервис на ASP.NET, а заказчик считает техническое задание невыполненным;
- исходный код передали, но собрать из него работающую программу не получается: не хватает файлов проекта, пакетов или настроек;
- переданные сборки обработаны обфускатором, и заказчик не может ни доработать систему, ни сменить исполнителя;
- программа падает, зависает или со временем занимает всю доступную память, и стороны спорят, дефект это или условия эксплуатации;
- заказчик утверждает, что подрядчик выдал за свою разработку чужой код или нарушил условия использования пакета;
- спорят о переносе системы с прежней платформы .NET Framework на современную и о том, входил ли этот перенос в работы;
- требуется установить, к какому периоду относится спорная версия и что изменилось между выпусками.
Если спор идёт об обмене с учётной системой предприятия, начните со страницы экспертизы 1С: там объекты и следы другие.
Почему по .NET исходный текст почти всегда восстановим
Если управляемая сборка содержит IL и метаданные, средства вроде ILSpy, dnSpy и dotPeek восстанавливают представление на C# с именами типов и членов. Это декомпиляция, а не возврат первоначального исходного текста: результат зависит от компилятора, оптимизации, обфускации и выбранного инструмента.
Даже без исходников можно исследовать состав типов и методов, строки, внешние зависимости и часть логики. Обращения к базе или внешним системам устанавливают лишь в пределах доступного кода, конфигурации и наблюдаемого выполнения. Отсутствие исходников поэтому ограничивает, но не всегда исключает исследование.
Ограничения описывают отдельно. Комментарии и авторские пояснения обычно отсутствуют, а исходные имена локальных переменных зависят от отладочных данных. Разбиение по файлам и некоторые конструкции языка восстанавливаются неполно или в преобразованном виде. PDB может содержать пути, номера строк и иные сведения, но его связь со сборкой проверяют. В заключении прямо указывают, исследовались ли переданные исходники или результат декомпиляции.
Обфускация: зачем её ставят и что она значит для спора
Обфускаторы, в том числе Dotfuscator и ConfuserEx, затрудняют анализ: переименовывают типы и методы, преобразуют строки и поток управления. Упаковщики и преобразователи могут дополнительно менять представление сборки. Эксперт устанавливает признаки применённой защиты, доступный объём анализа и ограничения методики; обход защиты допустим только при законном основании.
Последствия зависят от преобразований. Переименование не обязательно скрывает зависимости и структуру типов, но затрудняет понимание назначения методов. Зашифрованные строки иногда наблюдаются во время выполнения, однако полнота такого восстановления зависит от сценария. Предположения о назначении элементов отделяют от установленных фактов.
Если переданы только защищённые сборки без исходников, эксперт фиксирует их состав, признаки обработки и доступность программной логики. Соответствует ли такой комплект договору и нарушены ли обязательства, решает суд.
Что сохранить, пока сборки и история на месте
Копируйте и передавайте только то, к чему у вас есть законное основание доступа: право владельца, согласие, договорное полномочие или процессуальное решение. Если репозиторий доступен только подрядчику, письменно запросите предусмотренные договором материалы и сохраните ответ. Способ истребования доказательств зависит от процедуры; в ходатайстве обозначают доказательство, указывают подтверждаемые им обстоятельства, причины невозможности получить его самостоятельно и место нахождения.
Разумный минимум выглядит так:
- сохраните каталог установленной программы целиком, вместе с файлами настроек и вспомогательными сборками, документируя источник и порядок копирования;
- если репозиторий доступен, сохраните его зеркальную копию со всеми доступными ссылками, ветками, метками и достижимой историей; чаще всего это Git;
- заберите файлы отладочных данных, если они лежат рядом со сборками: в .NET их называют PDB; после проверки связи со сборкой они помогают сопоставлять исполняемый код с исходными файлами и строками;
- сохраните записи сервера сборки за спорный период: когда, из чего и с какими настройками выпускались версии;
- выгрузите базу данных, конфигурацию площадки и журналы веб-сервера или службы, где программа развёрнута;
- для каждого архива посчитайте контрольную сумму и сохраните её отдельно. Она позволяет позднее проверить соответствие файла записанному значению, но сама не подтверждает дату и источник. В Windows используют PowerShell —
Get-FileHash архив.zip -Algorithm SHA256— или обычную командную строку —certutil -hashfile архив.zip SHA256; в Linux —sha256sum архив.zip, в macOS —shasum -a 256 архив.zip; - составьте служебную записку: какие архивы получены, с какого сервера, когда, под чьей учётной записью и кто присутствовал.
Фиксацию выполняет сотрудник с законным доступом к серверу и репозиторию. Если вы не уверены, с чего начать, позвоните по номеру 8 (800) 333-24-09: подскажем порядок применительно к вашей ситуации, это бесплатно.
До фиксации по возможности не переустанавливайте и не обновляйте спорную версию, не удаляйте ветки и журналы. Если изменение необходимо для безопасности или работы, сначала сохраните доступное состояние и документируйте действия. Для самостоятельно снятой копии отдельно подтверждают происхождение; контрольная сумма решает только задачу последующего сравнения. Возможность нотариального или судебного обеспечения доказательств зависит от обстоятельств и процедуры, поэтому порядок согласуют с юристом.
Сборка .NET повторяема — и это меняет доказывание
SDK-проекты современного .NET обычно используют детерминированную компиляцию: при одинаковых учтённых входных данных компилятор способен выдать одинаковый результат. Это не гарантирует воспроизводимость всей публикации, куда входят пакеты, генераторы, ресурсы, упаковка, подпись и другие операции.
Контрольная сборка возможна при наличии исходников и достаточного окружения. Если представлены только сборки, исследуют доступные типы, методы, зависимости, строки и поведение, прямо указывая ограничения.
При наличии исходников фиксируют версию SDK и компилятора, граф пакетов, параметры проекта, генераторы и операции публикации, затем выполняют контрольные сборки. Сведения внутри сборок и PDB помогают проверить часть окружения, но не всегда позволяют восстановить его полностью.
Критерии сравнения задают заранее. Побайтовое совпадение в подтверждённо воспроизводимой среде поддерживает вывод о соответствии результата переданным исходникам, но само по себе не устанавливает происхождение файлов. Расхождение классифицируют по секциям, метаданным, ресурсам и исполняемой логике, проверяя влияние инструментов, пакетов, путей и подписи. Необъяснённое различие описывают, не превращая его автоматически в вывод о подмене исходников.
У старых и нестандартных проектов детерминированность может быть отключена или нарушена внешними этапами. Пути к исходникам также могут попасть в PDB и исполняемый файл; для их нормализации существует PathMap. Повторные сборки в зафиксированных и намеренно изменённых условиях выявляют источники недетерминированности, но каждое различие всё равно оценивают по происхождению и значению.
По атрибутам сборок, runtimeconfig/deps-файлам и установленному окружению можно определить заявленную или совместимую платформу настолько точно, насколько позволяют материалы. Точная версия SDK в итоговых файлах присутствует не всегда.
Подпись сборки и строгое имя: что они доказывают
Строгое имя сборки и подпись файла решают разные задачи, и их доказательственные пределы различаются.
Строгое имя задаёт идентичность сборки через открытый ключ и подпись, но не удостоверяет личность издателя и не должно использоваться как самостоятельная проверка доверия. Проверяют саму подпись, токен ключа и параметры среды, поскольку режим проверки зависит от платформы. Отдельный механизм — подпись файла сертификатом издателя. Она связывает файл с субъектом сертификата и позволяет проверить целостность в рамках доверенной цепочки. Достоверное время подтверждают только при наличии проверяемой метки времени.
Ни один механизм не доказывает авторство кода или полномочия конкретного человека: ключ мог использоваться несколькими сотрудниками и системами сборки. Результат сопоставляют с эталонными файлами, сертификатами, журналами подписания и правилами хранения ключей. Если закрытый ключ скомпрометирован, его использование прекращают и выполняют предусмотренную владельцем процедуру отзыва сертификата либо замены ключа.
Пакеты NuGet и условия их использования
В проектах с PackageReference прямые ссылки находятся в файле проекта, а полный разрешённый граф — в создаваемом при восстановлении файле. Файл блокировки версий используется только при включённом режиме и фиксирует прямые и транзитивные зависимости. В старых проектах сведения могут находиться в packages.config. По одним сборкам обычно видны ссылки на внешние модули, но точный пакет NuGet и его версия устанавливаются не всегда.
Сторонние пакеты, изменённые компоненты и собственный код классифицируют раздельно. При оценке объёма указывают правила исключения и отдельно учитывают работу по интеграции и сопровождению зависимостей.
Лицензионный документ может использовать обозначения MIT, Apache, BSD, GPL, LGPL или коммерческие условия. Эксперт устанавливает пакет и его версию, подтверждённые представленными материалами, а также реквизиты лицензионного документа и способ подключения. Толкование условий и вывод о нарушении относятся к правовой оценке.
.NET Framework и современный .NET: спор о переносе
.NET Framework и современный .NET — разные платформы с различиями в совместимости и развёртывании. Поддержка .NET Framework зависит от конкретной версии и версии Windows, поэтому возраст платформы сам по себе не означает прекращения поддержки. В спорах обычно проверяют два случая.
Первый: заказчик считает, что подрядчик обязан был сделать систему на современной платформе, а получил её на устаревшей. Здесь эксперт устанавливает факт — под какую платформу и версию собрана программа, — а вопрос о том, следовало ли из договора требование к платформе, решается по документам. Если требование в задании названо, несоответствие проверяемо; если не названо, вывод о «неправильном выборе» становится оценочным, и эксперт его не делает.
Второй: перенос заказан, и стороны спорят о полноте. Эксперт сравнивает функции до и после переноса, проверяет оставшиеся компоненты прежней платформы и воспроизводит заявленные сценарии на обеих версиях. Различия связывают с конкретным кодом, библиотекой или условием среды.
Отказы, зависания и рост потребления памяти
Для анализа нужны журналы, трассировки или снимки состояния, относящиеся к спорной версии и сценарию.
Необработанная ошибка может оставить цепочку вызовов в журнале, событии или дампе, если соответствующая запись настроена. Номера строк и значения зависят от PDB, оптимизации и состава дампа. Место проявления отказа не всегда совпадает с местом дефекта, поэтому проверяют входные данные, внешние системы, ресурсы и действия других программ.
При зависании анализируют состояние потоков: ожидание базы или внешней системы, блокировку либо длительное вычисление. Последовательные снимки, трассировки и журналы помогают отличить остановку от медленной работы, но достаточность материала оценивают для конкретного случая.
Рост памяти исследуют воспроизведением и сравнением метрик процесса, управляемой кучи и нативных ресурсов. Сборщик мусора не исключает удержание объектов обработчиками, кешем или статическим полем. Возможны также неосвобождённые нативные ресурсы, фрагментация и кеширование. Вывод сопровождают сценарием, условиями и пределами использованных средств.
Где у решения на .NET прячется логика помимо кода
Распространённая ошибка — ограничить исследование только кодом. Поведение корпоративного решения может задаваться и вне программы.
Смотреть нужно как минимум сюда:
- файлы настроек приложения и веб-сервиса: строки подключения к базе, адреса внешних систем, включённые и выключенные возможности;
- переменные окружения и параметры запуска службы: в типовой конфигурации Generic Host и ASP.NET Core они имеют приоритет над appsettings-файлами, но приложение может изменить порядок провайдеров;
- саму базу данных: справочники, правила расчёта, права доступа, хранимые процедуры — на SQL Server значительная часть логики нередко живёт именно там;
- настройки площадки: параметры веб-сервера IIS или службы Windows, расписания фоновых задач, учётные записи, от имени которых всё работает;
- обмен с внешними системами: адреса, форматы, журналы обеих сторон;
- файлы, загруженные пользователями, и шаблоны документов, если система их формирует.
Одного каталога с программой обычно мало, и объём материалов лучше согласовать заранее — иначе исследование упрётся в вопрос, ответ на который лежит в настройке, а не в коде.
Сравнение двух кодовых баз: почему по .NET это работает лучше
В споре о заимствовании можно сравнивать не только исходные тексты, но и управляемые сборки, если в них сохранились необходимые IL и метаданные. Обфускация, Native AOT, смешанный код и иные преобразования ограничивают этот подход.
Если представлены исходные тексты, их сравнивают непосредственно. При сравнении управляемых сборок основой служат IL и метаданные, а декомпилированный текст используют как вспомогательное представление с указанием инструмента и его версии. Сравнивают состав типов и их членов, структуру и порядок операций внутри методов, тексты сообщений, схему данных.
Общие элементы классифицируют в тех же единицах, в которых ведут сравнение: библиотечный код, описания форм, модели данных, обёртки, стандартные конструкции и созданные компилятором элементы. Их не исключают автоматически: сначала устанавливают происхождение, наличие изменений и значение для конкретного совпадения. Версию компилятора и настройки учитывают, поскольку они порождают сходства и различия. Необъяснённые совпадения проверяют вручную. Подробнее — на странице экспертизы плагиата исходного кода.
Как датируют спорную версию
Дату создания или выпуска нельзя надёжно определить по одному признаку. Каждый источник проверяют на происхождение, возможность изменения и связь со спорной версией.
На что при этом опираются:
- история в хранилище исходных текстов — самый содержательный источник, но даты в ней задаются свободно штатными средствами, поэтому её подтверждают другими;
- записи сервера сборки: когда, из чего и с какими настройками выпускалась каждая версия, — с проверкой прав изменения и сохранности журналов;
- сведения о версии внутри самих файлов программы и время их создания на площадке — но файловые метки переписываются копированием и переустановкой, поэтому сами по себе они доказывают мало;
- действительная метка доверенной службы времени в подписи сборки, если она есть, — как один из независимых источников;
- журналы установки и обновления на сервере заказчика, резервные копии за прошлые периоды;
- переписка сторон с вложениями, акты и задачи в системе учёта.
Вывод обычно формулируют как подтверждённый интервал существования или выпуска версии с указанием точности. Расхождения источников отражают в заключении. Спор о сроках разбирает экспертиза сроков и хронологии разработки.
Когда спор выходит за пределы C#
Крупные системы редко пишут на одном языке: серверная часть на C# обрастает интерфейсом в браузере, обменом с учётной системой и вспомогательными сервисами. Границу исследования лучше провести до постановки вопросов.
Границы обычно проводят так:
- спор о самой программе на C#, её сборках, базе и развёртывании: это и есть предмет настоящего направления;
- претензия к тому, что происходит в браузере пользователя, а не на сервере: экспертиза кода на JavaScript;
- спор о серверной части, написанной на другой платформе: экспертиза кода на Java;
- спор о сайте или интернет-магазине: экспертиза кода на PHP;
- спор о программе для оборудования или о расчётном ядре: экспертиза кода на C++;
- спор о воспроизводимости расчётов при обработке данных: экспертиза кода на Python.
Ссылки на соседние направления помогают определить границы задачи. Если спор охватывает несколько технологий, их можно исследовать совместно, сформулировав отдельные вопросы. Определять язык заранее не обязательно: он может быть указан в документах или установлен по составу файлов.
Какие обстоятельства устанавливают по программе на C#
Доступные исследования определяют поставленные вопросы, состав сборок, исходников, конфигурации и следов выполнения.
- сохранены ли в спорных файлах IL и метаданные, какие иные представления доступны и как это ограничивает декомпиляцию;
- может ли установленная программа быть получена из переданных исходников и какие соответствия и различия выявлены;
- выполнено ли каждое проверяемое требование задания — с указанием объекта и способа, которым это проверялось;
- какие пакеты каких версий использованы, чем это подтверждается и какими лицензионными документами сопровождаются пакеты;
- какие признаки обфускации выявлены, какие элементы они затрагивают и как ограничивают исследование;
- под какую платформу собрана программа, что можно установить о среде, подписи и времени;
- какие технические причины отказа, зависания или роста потребления памяти подтверждаются воспроизведённым сценарием и представленными следами; достаточно ли материалов для установления технической причинной связи;
- совпадения между двумя кодовыми базами с отдельной оценкой пакетного, шаблонного и сгенерированного кода;
- чем спорная версия отличается от предыдущей и что изменилось между ними;
- какой период существования или выпуска спорной версии подтверждается совокупностью источников;
- какой объём изменений относится к спорному периоду или учётным записям, без вывода о личном авторстве и стоимости.
Добросовестность сторон, толкование договора, существенность недостатка и размер убытков оценивает суд. Технический вывод может служить основанием для такой оценки, но не заменяет её. Денежные вопросы исследуют в рамках экспертизы объёма и стоимости работ, при необходимости с участием экономиста.
Как проверяют соответствие заданию по коду и по работающей системе
Каждое требование связывают с конкретным объектом и способом проверки: исходниками, декомпилированным представлением, сборкой, базой, конфигурацией или работающей системой.
Требования к устройству программы проверяют по исходному коду, а при его отсутствии — по доступному результату декомпиляции с соответствующей оговоркой. Поведение воспроизводят на стенде либо, если это необходимо и разрешено, на площадке владельца по утверждённому сценарию. Условия присутствия участников дела и порядок доступа определяет назначивший орган, требования безопасности — владелец площадки. Эксперт фиксирует извещение, состав участников, условия, действия и результаты; их доказательственное значение оценивает суд.
По каждому требованию указывают: реализовано, реализовано частично, не реализовано либо не может быть проверено на представленных объектах. Затем описывают объект, способ, условия и результат. Существенность недостатка и его влияние на приёмку оценивает суд. Если язык значения не имеет, проводят экспертизу соответствия работ техническому заданию.
Что просят прислать по спору о системе на .NET
Материалы корпоративной системы могут быть распределены между исходниками, сборками, базой и площадкой.
Программа: исходники, сборки, пакеты
Первая часть — исходные материалы и результаты сборки:
- исходные тексты вместе с файлами проектов и решения; если их нет, работают по сборкам и прямо указывают это ограничение;
- репозиторий со всеми доступными ссылками, ветками, метками и достижимой историей, если она велась;
- сборки спорной версии и, если сохранились, предыдущих — по ним сравнивают, что изменилось между выпусками;
- файлы отладочных данных, связанные со сборками: они облегчают символизацию и повышают точность анализа, но не устанавливают причину отказа автоматически;
- ссылки на пакеты в файлах проектов, файл блокировки версий и, для развёрнутого приложения, список зависимостей, который создаётся при публикации;
- точные версии и контрольные суммы SDK, MSBuild или Visual Studio, NuGet.config, lock/assets-файлы, пакеты, генераторы, анализаторы, сценарии и параметры restore/build/publish, ОС, архитектура и операции после сборки.
Площадка: где система живёт и что она о себе оставила
Вторая часть — то, без чего первая объясняет не всё:
- файлы настроек приложения и площадки, включая параметры веб-сервера IIS или службы Windows;
- выгрузка базы данных: справочники, правила, права доступа, хранимые процедуры;
- журналы приложения и журнал событий Windows за спорный период, снимки памяти при отказах;
- журналы обмена с внешними системами — с обеих сторон, если это возможно;
- записи сервера сборки: когда, из чего и с какими параметрами выпускалась каждая версия;
- техническое задание с приложениями, договор, акты, переписка сторон, задачи в системе учёта, документы на коммерческие компоненты.
Недостающие материалы определяют после первичного разбора: их набор зависит от вопросов, поэтому собирать всё без разбора не нужно.
Как передать материалы и не раскрыть доступы
Настройки, исходники и дампы могут содержать строки подключения, ключи сервисов, персональные данные и закрытые ключи подписи. Их выявляют до передачи и включают в модель доступа.
До первичного разговора материалы пересылать не нужно. Затем согласуют состав, защищённый канал и круг допущенных лиц; при приёмке фиксируют опись и контрольные суммы. Материалы с рабочими настройками не отправляют по обычной почте или через мессенджеры.
Неизменный оригинал сохраняют в защищённом контуре. Для передачи готовят документированную производную копию с маскированием действующих секретов и лишних персональных данных, если это не уничтожает исследуемый признак. Иначе исследование проводят на месте либо по отдельно согласованной защищённой процедуре. В судебной экспертизе состав и доступ определяют через назначивший орган; во внесудебной — основание и порядок обработки заранее согласуют с юристом.
Отзыв или замена учётных данных выполняются владельцем или уполномоченным им лицом без неоправданной задержки и документируются. Срок хранения, возврат или уничтожение переданных материалов и режим доступа фиксируют до начала работы.
Если раскрытие исходников другой стороне создаёт риск, до передачи обсудите с юристом пределы состава, исследование на территории владельца и процессуальные меры конфиденциальности. Решение зависит от применимой процедуры и назначившего органа.
Как идёт работа: от приёмки материалов до выводов
Порядок построен так, чтобы каждый шаг мог повторить другой специалист, а спорные места были видны читателю заключения.
- Приёмка: записывают состав материалов и контрольные суммы, описывают происхождение каждой копии.
- Опознание объектов: что перед экспертом — исходные тексты, сборки или и то и другое; сохранено ли в сборках промежуточное представление; какая версия платформы, какие пакеты, есть ли обфускация и подпись.
- Восстановление окружения и контрольные сборки: фиксируют входы и инструменты, выявляют недетерминированные части и сопоставляют результат со спорными файлами.
- Разбор кода: по исходному тексту либо декомпилированному представлению, с указанием объекта, средства и его версии.
- Проверка требований — каждое своим способом, с записью условий, при которых получен результат.
- Проверка альтернативных объяснений: настройки, данные, внешние системы, действия третьих лиц.
- Формулирование выводов в пределах поставленных вопросов и перечисление ограничений.
Указывают обфускацию, отсутствие отладочных данных, недоступность внешней системы или площадки и иные ограничения. Читателю должны быть видны основания и пределы каждого вывода.
Как формулируют вопросы по программе на C#
Вопрос должен точно идентифицировать объект: архив с контрольной суммой, набор сборок, конфигурацию, базу, дамп или работающую систему с указанием источника. Отдельно называют проверяемый критерий, условия или сценарий.
Происхождение кода, соответствие заданию, обфускацию и причину отказа лучше формулировать отдельными вопросами. Следует предусмотреть возможность вывода о недостаточности материалов. При судебной экспертизе круг вопросов определяет назначивший орган; эксперт отвечает в пределах специальных знаний и сообщает о неясности в установленном порядке. Помочь сформулировать вопросы можно до назначения; подробные перечни собраны на страницах экспертизы качества исходного кода и экспертизы плагиата исходного кода. По программам на C# используют, например, такие формулировки:
- Могут ли сборки … быть получены из исходных текстов архива с контрольной суммой SHA-256 … в воспроизведённой среде; какие совпадения, различия и ограничения установлены?
- Соответствует ли программа, представленная сборками …, требованиям пунктов … технического задания (приложение № … к договору от …)?
- Какие признаки обфускации или иных преобразований обнаружены в сборках …, какие элементы они затрагивают и как ограничивают исследование?
- Какие сторонние компоненты каких версий использованы в программе …, чем это подтверждается и какими лицензионными документами сопровождаются компоненты?
- Какие технические причины отказа программы … подтверждаются журналом … и сценарием, описанным в …; достаточно ли материалов для установления причинной связи?
- Имеются ли в сборках … и … совпадения программного кода; каково происхождение и значение общих пакетов, стандартных конструкций и созданного средой кода?
Форматы работы: от разбора до рецензии
До обращения в суд и после назначения экспертизы возможности разные, и выбирать формат стоит по стадии спора.
До иска или параллельно с ним возможны внесудебное исследование и письменная консультация по отдельному вопросу. Судебную экспертизу назначает суд или орган расследования; материалы поступают через назначивший орган. Имеющееся заключение можно проверить рецензированием — подробнее на странице рецензии на заключение о процессе разработки. Рецензия сама не отменяет заключение, а помогает обосновать процессуальное ходатайство. Вопрос о вызове эксперта, дополнительной или повторной экспертизе решает назначивший орган. Заключение оценивается вместе с другими доказательствами.
После назначения судебной экспертизы дополнительные материалы, доступ к площадке и новые сведения передают через назначивший орган. Эксперт не принимает дополнительные материалы непосредственно от сторон и не даёт им частных оценок по существу поручения. Предшествующую работу для участника спора раскрывают при рассмотрении кандидатуры; решение о назначении и отводе принимает назначивший орган.
Из чего складываются стоимость и срок
Расчёт складывается из трёх позиций. Первая — состояние объекта.
Трудоёмкость зависит от того, представлены ли исходники, доступны ли IL и метаданные и применены ли обфускация или нативная публикация. Второе обстоятельство — окружение: для стенда могут потребоваться нужная платформа, база и заменители внешних сервисов. Третье — работа на площадке, которую согласуют по времени, порядку и участникам.
Дополнительно учитывают размер спорного контура, число проверяемых требований и вопросов, необходимость смежных специалистов. Ориентир для судебной экспертизы — от 100 000 ₽, ориентировочный срок — от 10 рабочих дней. Их уточняют после просмотра материалов; о выходе задачи за эти рамки сообщают до начала работы.
Вывод о невозможности ответить по представленным материалам также требует исследования: эксперт указывает, какого объекта или условия не хватило. Поэтому объём определяют после первичного разбора. Выезд, стенд с внешними системами и участие в заседании включают в смету отдельными позициями до начала работы.
Для расчёта достаточно описать спор, назвать систему и перечислить имеющиеся материалы: договор, задание, переписку, доступы. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — мы определим направление исследования и сведения, необходимые для расчёта.
Проведение экспертизы по уголовному делу
Судебная экспертиза по уголовному делу производится государственными судебными экспертами и иными экспертами из числа лиц, обладающих специальными знаниями.
Согласно постановлению Пленума Верховного Суда Российской Федерации от 21 декабря 2010 г. № 28 «О судебной экспертизе по уголовным делам», негосударственными судебно-экспертными учреждениями признаются некоммерческие организации, созданные на основании Гражданского кодекса Российской Федерации и Федерального закона «О некоммерческих организациях» и ведущие судебно-экспертную деятельность согласно своим уставам.
По сведениям организации, проведение судебных экспертиз предусмотрено её уставом (см. действующую редакцию в разделе «Документы организации»). Это само по себе не означает автоматического поручения любой экспертизы. Возможность поручить конкретное исследование определяет назначающий орган.
В случаях, перечисленных пунктом 5 постановления № 28, когда экспертизу по уголовному делу назначает суд, ему следует мотивировать в определении или постановлении поручение исследования учреждению либо конкретному лицу. Пункт 5 постановления № 28 связывает выбор негосударственного учреждения с невозможностью провести исследование в государственном учреждении, обслуживающем соответствующую территорию: например, из-за отсутствия нужного специалиста, материально-технической базы или специальных условий, либо с отводом компетентных государственных учреждений. Дополнительно учитываются квалификация эксперта, основания для отвода и действующий перечень экспертиз, выполняемых только государственными судебно-экспертными организациями.
