Программное обеспечение стало повсеместным. От микроволновых печей до электронного управления дроссельной заслонкой – всё это теперь входит в нашу жизнь благодаря миллиардам новых продуктов, выпускаемых ежегодно. Будь то нарушение интеллектуальных прав или ответственность за качество продукции, когда продукты, управляемые программным обеспечением, становятся предметом судебного разбирательства, крайне важно должным образом тщательно проанализировать встроенное программное обеспечение (также известное как firmware).

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

1. Получите исходный код как можно раньше

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

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

2. Запросите список ошибок

По крайней мере, в случаях предполагаемой ответственности за [программный] продукт, при раскрытии доказательств следует регулярно запрашивать и предоставлять базу данных дефектов команды разработчиков программного обеспечения — или “список ошибок” (багов).

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

3. Настаивайте на исполняемом файле

На языке программного обеспечения “исполняемая” программа — это двоичная версия ПО, которая фактически выполняется в [программном] продукте. Машиночитаемый исполняемый файл создаётся из набора файлов исходного кода в удобочитаемом формате (т.е. удобном для чтения человеком), с использованием инструментов сборки ПО, таких как компиляторы и компоновщики.

Иногда легко извлечь исполняемый файл непосредственно из продукта для проведения экспертизы — в этом случае таким этапом должен заниматься эксперт. Например, программное обеспечение, работающее в Microsoft Windows, состоит из исполняемого файла с расширением .EXE, который легко извлечь. Однако из большинства встраиваемых систем исполняемые программы извлечь трудно.

Исполняемые файлы могут оказать большое влияние на судебный процесс. Хотя исполняемая программа и непонятна пользователю, она может предоставить ценную информацию эксперту-рецензенту. Например, одним из распространённых методов является извлечение удобочитаемых “строк” из исполняемого файла. Строки в исполняемой программе содержат такую информацию, как сообщения на экране для пользователя (например, "Нажмите кнопку ”?" для получения справки"). В деле о нарушении авторских прав, по которому когда-то компания Barr Group давала консультации, несколько строк в исполняемом файле ответчика содержали фразу, похожую на “Истец по авторским правам” – простую, но важную строку, которая оказала существенное влияние на ход дела.

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

4. Воспроизведите среду разработки

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

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

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

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

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

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

5. Попробуйте воспользоваться репозиторием управления версиями

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

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

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

6. Помните об оборудовании

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

Причина 1. Правильно выполнить реверс-инжиниринг или дизассемблирование исполняемой программы можно только после того, как известен конкретный микропроцессор (например, Pentium, PowerPC или ARM).

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

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

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

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

Бонусный совет: наймите подходящих экспертов

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