Что представляют собой двоичные данные вокруг списка в файле профиля подготовки?

Структура файла .mobileprovision выглядит примерно так:

<!-- small binary data -->

<?xml version="1.0" encoding="UTF-8"?>
<!-- plist data -->
</plist>

<!-- large binary data -->

У меня есть несколько вопросов по этому поводу:

  1. Что это за двоичные данные?
  2. Это полезно?
  3. Как я могу извлечь список из файла .mobileprovision без поиска границ XML?

В частности, я буду рассматривать этот вопрос как ответ (и присуждать награду +100 вместе с ним), когда будут даны ответы на Q1 и Q3, указанные выше.


person Chaitanya Gupta    schedule 15.03.2012    source источник


Ответы (5)


Наконец-то я получил ответ от ответа на другой вопрос по SO.

В основном файл .mobileprovision представляет собой зашифрованный файл XML с помощью CMS. Его можно декодировать с помощью security в OS X:

security cms -D -i /path/to/profile.mobileprovision
person Chaitanya Gupta    schedule 11.07.2012
comment
Информацию, которую вы получаете с помощью этого метода, также можно получить, просто открыв мобильное приложение в текстовом редакторе. после XML идет блок дополнительных данных, которые при использовании security не декодируются. - person n_b; 26.11.2013
comment
Я знаю; именно поэтому я задал этот вопрос. Мне нужен был программируемый / скриптовый способ получения только XML и ничего больше. - person Chaitanya Gupta; 26.11.2013

У меня нет ответа на ваш первоначальный вопрос, но я могу объяснить, как извлечь сертификат подписи из файла .mobileprovision:

  1. Часть plist .mobileprovision имеет ключ DeveloperCertificates, значение которого представляет собой массив NSData.
  2. Каждый NSData представляет собой файл .cer - сертификат подписи, который вы ищете.

У меня есть короткий сценарий оболочки для извлечения темы сертификата подписи непосредственно из файла .mobileprovision здесь: https://gist.github.com/2147247 - скрипт работает только с одним сертификатом в массиве, упомянутом ранее, что должно быть обычным случаем.

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

person NeoNacho    schedule 21.03.2012
comment
Большое спасибо. Хотя, как вы сказали, он не отвечает на первоначальный вопрос, он все же был очень полезен - я наконец узнал, что сертификат в ключе DeveloperCertificates является сертификатом x509, что я планировал спросить на SO ;-) Спасибо ты. - person Chaitanya Gupta; 21.03.2012

использовать

security cms -D -i /path/to/profile.mobileprovision

если вы получили сообщение об ошибке security: SecPolicySetValue: One or more parameters passed to a function were not valid, просто перенаправьте сообщение об ошибке /dev/null

security cms -D -i /path/to/profile.mobileprovision 2> /dev/null
person schmichri    schedule 25.04.2017

Файл .mobileprovision представляет собой кодировку DER ASN.1,

Список - это одно из значений, хранящихся в этом сообщении ASN.1.

person Tal Aloni    schedule 14.11.2017

Этот файл в основном представляет собой открытый ключ распространения + цепочку общедоступных сертификатов Apple + разрешенные устройства, на которые можно установить - при условии, что файл IPA также подписан.

Ваш ключ закодирован в записи списка. а двоичные данные после plist - это связанные общедоступные сертификаты: общедоступный сертификат Apple Root (можно загрузить с сайта Apple и центр сертификации Apple iPhone (можно загрузить через портал Apple).

[Обновлено на основе комментариев]

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

Внутри файла мобильной подготовки тег ApplicationIdentifierPrefix содержит идентификатор пользователя сертификата. Этот номер можно использовать для поиска сертификата в инструменте связки ключей.

Итак, вручную, шаги будут такими:

  1. Извлеките номер ApplicationIdentifierPrefix из файла .mobileprovision.
  2. Откройте приложение связки ключей. Просмотрите каждый логин / сертификат, чтобы найти тот, у которого есть соответствующий UserId.

Для автоматизации процесса

  1. запустите какую-нибудь причудливую команду unix, чтобы извлечь идентификатор
  2. запустите security find-certificate -a >a.out, затем введите идентификатор с помощью grep. Затем найдите общее имя из той же записи.
person peterept    schedule 15.03.2012
comment
Обычно я хочу отказаться от приложения с другим файлом подготовки. Мне было интересно, можем ли мы вместо явного указания имени сертификата отказаться от приложения, извлечь информацию о сертификате подписи из самого нового профиля подготовки. К этому я привел при просмотре содержимого файла .mobileprovision. - person Chaitanya Gupta; 15.03.2012
comment
Как мне извлечь из этого файла только информацию о plist? - person Chaitanya Gupta; 15.03.2012
comment
AFAIK вы не можете уйти в отставку - потому что вам также нужно подписать двоичные файлы во время компиляции в XCode, а затем в окончательном IPA. Хотя позже может быть просто добавлен файл XX.mobileprovisiong в пакет приложения как embedded.mobileprovisioning. Итак, ваша ситуация заключается в том, что у вас есть двоичный IPA / APP, но нет источника? - person peterept; 15.03.2012
comment
В этом документе содержится хороший анализ управления безопасностью предоставления. - person peterept; 15.03.2012
comment
Нет, я не смотрю файл plist в ipa. Наш процесс развертывания выглядит следующим образом: мы встраиваем приложение со специальным профилем подготовки для бета-тестирования. Если бета-тестирование пройдет нормально, мы просто откажемся от того же приложения с профилем обеспечения магазина приложений, используя команду xcrun. Теперь соответствующая формулировка этой команды требует, чтобы я предоставил и профиль обеспечения и имя сертификата подписи. Поскольку профиль обеспечения действительно содержит информацию о сертификате подписи, мне было интересно, можем ли мы избежать необходимости писать это. - person Chaitanya Gupta; 15.03.2012
comment
о, вау, это хорошая идея, я никогда не пробовал этого - я всегда перестраивал проект и подписывал его в то время либо сертификатом AdHoc, либо сертификатом AppStore и тем же именем сертификата. Я просто сохраняю эту информацию в файле конфигурации, а затем имею сценарий сборки, который запускает xcodebuild и xcrun. - person peterept; 15.03.2012
comment
Да, используя xcrun, вам не нужно перекомпилировать весь проект - вы можете просто отказаться от существующего .app и получить новый ipa. См. stackoverflow.com/questions/ 2664885 / для получения дополнительной информации. Это здорово, потому что вы точно знаете, что двоичный файл, который вы отправляете в магазин приложений, является тем же двоичным файлом, который использовали ваши бета-тестеры. Мы попробовали, и это работает. Дополнительным преимуществом является то, что вам не нужно создавать отдельный файл dsym для отчетов о сбоях. - person Chaitanya Gupta; 15.03.2012
comment
Мне будет интересно попробовать. Большинство моих приложений проверены на соответствие нашему сертификату распространения и выпущены с сертификатом магазина приложений клиентов, поэтому в нашем случае сертификат общего имени отличается (и я передаю это имя как в xcodebuild, так и в xcrun). Так что мне интересно, работает ли повторная подпись, только если общее имя такое же? - person peterept; 15.03.2012
comment
Я покопался и увидел, как идентификатор в файле .mobileprovision может привести к правильному общему имени, которое затем можно использовать для подписи. Я не придумал точных команд, чтобы автоматизировать это, но уверен, что это не составит труда с небольшой хитростью unix. - person peterept; 15.03.2012
comment
Вы передаете удостоверение подписи при увольнении (с помощью команды xcrun), поэтому я считаю, что вы сможете подписать его другим сертификатом, даже если общее имя отличается. - person Chaitanya Gupta; 16.03.2012
comment
позвольте нам продолжить обсуждение в чате - person Chaitanya Gupta; 16.03.2012
comment
Поиск значения ApplicationIdentifierPrefix не работает - таким образом мне не удалось найти ни один из моих сертификатов разработчика или распространения. Хотя здесь находится наш push-сертификат. Лучше найти способ декодирования значений в ключе DeveloperCertificates. Он содержит NSData значения, и если вы попытаетесь передать эти данные в strings утилиту, вы увидите, что он содержит полную информацию о полномочиях подписи. - person Chaitanya Gupta; 16.03.2012