Экспертиза мобильных приложений

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

Если спор начался, зафиксируйте магазин сегодня. В Google Play и App Store публично доступна только текущая версия: как только разработчик выложит обновление или снимет приложение с публикации, прежняя карточка, её описание, скриншоты и номер версии исчезнут из открытого доступа. Это след, который теряется буквально за один день, и восстановить его потом нечем — как и хранилище исходных текстов, записи системы сборки и отчёты об отказах, о которых сказано ниже. Что и как сохранять, разобрано ниже.

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

С какими спорами приходят по мобильным приложениям

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

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

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

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

Android и iOS — два разных объекта

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

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

Приложение для iOS поставляется собранным в машинный код процессора, и обратного пути к исходному тексту на Swift или Objective-C нет. Но объект не пуст: система требует, чтобы приложение описывало само себя, поэтому в файле остаются имена классов и методов, перечень используемых системных возможностей, тексты интерфейса, изображения и описания экранов. Для кода, написанного на Objective-C, таких сведений больше, для Swift — меньше. То есть по iOS-приложению устанавливают устройство и состав, но не алгоритм.

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

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

Обфускация: когда код закрыт, а когда нет

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

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

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

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

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

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

1. выгрузите из консоли разработчика историю выпусков с датами и номерами версий, отчёты об отказах, статистику по устройствам и версиям системы, а в Google Play — ещё и универсальный установочный файл каждого нужного релиза из раздела с содержимым сборок: он подписан площадкой и потому лучше любой копии с телефона;
2. зафиксируйте карточку приложения в магазине: снимки экрана всей страницы с описанием, скриншотами, номером версии и разделом о собираемых данных. В Google Play публична только текущая версия; в App Store доступна и история прежних выпусков, но описание и скриншоты к ним не сохраняются;
3. посчитайте контрольную сумму каждого сохранённого файла и запишите её отдельно — например, в письме самому себе. Это короткая строка, вычисленная из содержимого файла: изменится хоть один знак — изменится и она. На Windows её считают в приложении PowerShell командой Get-FileHash файл.apk -Algorithm SHA256, на macOS в приложении «Терминал» — shasum -a 256 файл.apk;
4. сохраните переписку с подрядчиком и с площадкой, включая уведомления магазина об отклонении или снятии приложения;
5. если у вас есть доступ к хранилищу исходных текстов, сохраните его полную копию с историей: хранилище удаляется одним действием и собственного независимого журнала не имеет, поэтому исчезает быстрее всего остального;
6. оттуда же выгрузите записи системы сборки — журналы и собранные артефакты за спорный период: именно они отвечают на вопрос, из какого кода получена опубликованная версия, и хранятся обычно от месяца до трёх;
7. сохраните отчёты службы сбора сведений об отказах, если она подключена: такие службы хранят данные около трёх месяцев, а при закрытии проекта подрядчиком исчезают вместе с ним;
8. если у вас есть доступ к серверной части, сделайте резервную копию базы и сохраните журналы за спорный период;
9. напишите служебную записку на полстраницы: что и когда сохранено, из какой учётной записи, кто присутствовал;
10. и только теперь направляйте письменное требование о передаче материалов.

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

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

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

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

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

Подпись приложения и аккаунт разработчика

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

Подпись связывает выпуск с обладателем ключа и проверяется устройством при установке и обновлении. Но у приложения из магазина ключей обычно два, и от того, какой именно проверяют, зависит вывод. Случаев три. Первый: приложение подписывает сама площадка своим ключом, а разработчик подписывает только загружаемую сборку ключом загрузки — так устроены нынешние публикации в Google Play, и так же переподписывает каждое приложение App Store. Второй: ключ подписи принадлежит разработчику, но передан в механизм площадки — распространённый случай для приложений, опубликованных давно и переведённых на новый порядок позже. Третий: разработчик ведёт ключ полностью сам, вне механизма площадки.

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

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

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

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

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

Магазин как источник проверяемых фактов

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

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

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

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

Серверная часть: половина логики не в приложении

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

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

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

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

Сторонние библиотеки, реклама и аналитика

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

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

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

Разрешения и передача данных: что проверяется на самом деле

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

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

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

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

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

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

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

Отказы, зависания и расход батареи

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

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

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

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

«Не работает на моём телефоне»: совместимость

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

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

Как связывают исходный код с опубликованным приложением

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

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

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

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

Сравнение двух приложений

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

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

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

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

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

Опираются на такие источники:

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

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

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

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

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

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

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

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

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

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

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

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

Приложение и код

Первая часть — то, что было опубликовано и из чего оно получено:

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

Сервер, магазин и документы

Вторая часть — то, без чего первая объясняет не всё:

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

Чего не хватает по вашему спору, скажем после первичного разбора.

Как передать материалы и не открыть чужие доступы

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

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

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

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

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

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

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

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

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

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

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

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

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

Как формулируют вопросы по мобильному приложению

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

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

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

Форматы работы: от разбора до рецензии

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

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

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

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

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

Цену задаёт не размер приложения, а число объектов, до которых удалось дотянуться.

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

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

Отдельно об исходе «на представленных материалах не проверяется»: это тоже результат работы, он оплачивается наравне с любым другим, а суду показывает, какого объекта или условия не хватило. Чтобы такого исхода было меньше, состав материалов и определяют на бесплатном разборе.

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

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