Подписывание sis-пакетов с помощью SISContents

Первоисточник: отсутствует. Статья написана мной и ранее не публиковалась.

В сети можно найти много различных FAQ по подписанию sis-пакетов, а также описаний софта, используемого для подписи. Целью данной статьи не является подготовка еще одного такого FAQ, я лишь хочу осветить некоторые моменты, связанные с подписью, обычно не упоминаемые в руководствах, а также рассказать о том, как подписывать пакеты с помощью программы SISContents.
Вообще, SISContents это не только программа для подписи, у нее много других возможностей, но так как речь не об этом, я не буду их перечислять, кому интересно, могут ознакомиться с ними на официальном сайте программы. Там же (на сайте) всегда можно найти самую последнюю версию SISContents.
Чем SISContents отличается от всех прочих программ для подписи sis-пакетов? Начну с того, что существующие программы не всегда отличаются универсальностью и наглядностью. Это касается удобства подписи embedded-пакетов (sis-файл, имеющий в себе один или несколько встроенных компонентов - вложенных в него sis-пакетов), отображения package UID sis-файла, а также capabilities, требуемых подписываемому приложению.
Далеко не весь существующий софт для подписи сможет показать, есть ли в пакете встроенные компоненты. Почему они важны для подписи? Потому что в случае наличия компоненты также должны быть подписаны как и сам пакет, в который они встроены. Если этого не происходит, sis-пакет не допускается к установке - инсталлятор продолжает выдавать ошибку, несмотря на то, что пакет, вроде бы, подписан, но он настойчиво советует обратиться к поставщику sis-файла (признак того, что подпись отсутствует).
Package UID и capabilities также имеют большое значение, так как от них зависит какой сертификат выбрать для подписи: self-signed или личный сертификат разработчика, привязанный к IMEI телефона. В случае с package UID значение имеет диапазон, к которому он относится: если используется UID из интервала 0x00000000-0x7FFFFFFF (защищенный диапазон значений), то пакет должен быть подписан доверенным сертификатом Symbian (сертификат разработчика в нашем случае) независимо от capabilities, требуемых приложению (в противном случае выдается ошибка о невозможности установить защищенный пакет из ненадежного источника). Влияние capabilities следующее:
1. для обеспечения NetworkServices, LocalServices, ReadUserData, WriteUserData, UserEnvironment ( Location в моделях на базе S60v3.2 и новее и UIQ 3.0 и новее) - достаточно self-signed сертификата.
2. Capabilities Location (в телефонах на базе S60v3.0 и S60v3.1), ReadDeviceData, WriteDeviceData, PowerMgmt, ProtSer, SwEvent, SurroundingsDD, Trusted UI требуют подписи доверенным сертификатом Symbian (в нашем случае сертификат разработчика).
3. Capabilities CommDD, DiskAdmin, NetworkContol, MultimediaDD, DRM, AllFiles, TCB требуют уровень доверия, который обычный сертификат разработчика обеспечить не способен, а потому подписывать приложения, требующие их, бесполезно - установка будет отклонена из-за недостаточности прав.
Понятно, что если в пакете встречаются исполняемые файлы, требующие capabilities из третьей категории, а у вас невзломанный телефон с «универсальным сертификатом» или модифицированным installserver’ом, то установка даже подписанного пакета провалится, но показывает ли ваша программа capabilities? Если нет, вы этого не узнаете, пока не подпишите пакет и не перенесете на устройство. Лишняя работа.
Кто-то может спросить: «а зачем выбирать сертификат, если сертификат разработчика способен обеспечить capabilities из первых двух категорий, тогда как self-signed только из первой? Ну и подписывать всё dev.cert'ом».
В различных FAQ по подписыванию обычно не упоминается подпись sis-пакетов с помощью self-signed сертификатов и подразумевается, что все файлы подписываются личным сертификатом разработчика, привязанного к IMEI телефона владельца сертификата. Однако данная практика, на мой взгляд, является неправильной, потому что бывают случаи, когда возможности, обеспечиваемые сертификатом разработчика, являются избыточными. Примером тому могут служить темы оформления, для которых понятие capabilities неприменимо, а подпись их dev cert'ом нецелесообразна в силу того, что подписанный им sis-пакет может быть установлен только на устройство, IMEI которого прописан в сертификате. Обычно темы оформления, которые можно найти в сети, уже подписаны автором в процессе формирования пакета, однако, можно также встретить пакеты, собранные и без помощи Carbide UI Theme Edition, а также возможны случаи, когда срок действия сертификата темы истек и чтобы не гадать какую дату устанавливать в телефоне, дабы инсталлятор принял тему, проще ее переподписать новым сертификатом, с более продолжительным сроком действия.
Таким образом, хотя dev. cert. обеспечивает больший диапазон capabilities (первая и вторая категории), это преимущество нивелируется привязкой к IMEI, что затрудняет установку sis-пакета на других устройствах, IMEI которого не значится в сертификате (например, если вы решили поделиться с кем-нибудь темой оформления или программкой, не требующей системных capabilities).
Надеюсь, я смог убедить вас в том, что package UID, capabilities и наличие встроенных компонентов играют немаловажную роль в процессе подписи, а также в выборе сертификата. Отсюда вытекают основные преимущества SISContents по сравнению с другими программами:
- наличие графического интерфейса, обеспечивающего наглядный обзор всех компонентов sis-пакета и подписей, которые у них есть с указанием срока действия сертификата, участвовавшего в подписывании;
- управление подписями (добавление/удаление) индивидуально по каждому компоненту пакета, благодаря чему программа незаменима при подписи embedded sis-файлов;
- наличие профилей подписывания, позволяющих добавить неограниченное количество сертификатов и использовать их в зависимости от ситуации.
Первые два пункта мы уже обсудили выше, хотелось бы ненадолго остановиться на профилях подписывания. Каждый профиль это сертификат и его секретный ключ (private key). Данная схема позволяет прописать в программу несколько сертификатов, например, self-signed и сертификат разработчика. Также эта возможность будет полезна, если у вас несколько телефонов и для каждого используется свой сертификат.

Итак, переходим практической части. (Примечание: скриншоты, использованные в статье, можно посмотреть в приложенном архиве “Скриншоты к статье.zip”).
Открываем sis-пакет, который необходимо подписать, с помощью SISContents и прежде всего, смотрим его Package UID (скриншот 1). Если он относится к защищенному диапазону значений, используем сертификат разработчика (привязанный к IMEI), в противном случае смотрим capabilities. Впрочем, capabilities надо смотреть в любом случае, потому что если нам встретятся manufacturer approval capabilities (категория 3, см. выше), подпись можно не проводить (если вы не пользуетесь универсальным сертификатом на хакнутом устройстве, пакет установить не получится). Capabilities можно увидеть в списке файлов, при этом, необходимо просмотреть все исполняемые файлы пакета (они отмечены синим шрифтом). Если пакет имеет встроенные компоненты, необходимо чтобы была включена галочка Show files of subcomponents внизу списка – это позволит включить отображение в списке файлов этих компонентов.
В приведенном примере (скриншоты 1 и 2) пакет имеет package UID 0xE6FAEAAE и capabilities: ReadDeviceData, WriteDeviceData, NetworkServices, ReadUserData, WriteUserData, Location. Так как исполняемый файл требует capabilities из второй категории (ReadDeviceData, WriteDeviceData, Location), то подписывать необходимо сертификатом разработчика.
Подпись в SISContents осуществляет в диалоговом окне, которое можно вызвать в главном меню, пункт Tools->Sign package (скриншот 3). Перед тем как подписать sis-пакет необходимо добавить в программу свой сертификат разработчика, т.е. сформировать список профилей подписывания.
Формирование списка профилей осуществляется на вкладке Key Pairs (key pair – пара ключей, т.е. секретный ключ и соответствующий ему сертификат), см. скриншот 4. Добавить новый профиль позволяет форма в правой части окна. Когда в списке профилей (левая часть окна) выделен какой-либо профиль, это означает редактирование его параметров в форме. Для добавления нового профиля необходимо, чтобы в списке сертификатов ни один не был выделен (достаточно кликнуть на пустой области списка, чтобы снять выделение).
Для добавления нового профиля необходимо заполнить все поля:
- Выбрать файл сертификата;
- Выбрать файл ключа, соответствующего этому сертификату;
- Ввести пароль для дешифровки файла ключа, если ключ шифрован. Опция Show letters позволяет включить отображение символов пароля, чтобы не ошибиться при вводе. Максимальная длина пароля – 25 символов.
- Имя профиля. Здесь можно ввести что угодно, но рекомендуется выбрать осмысленное название, чтобы этот сертификат можно было сразу идентифицировать.
Примечание: в SISContents по умолчанию присутствует один профиль для подписывания. Это self-signed сертификат сроком действия 25 лет (SISContents self-signed certificate). Он может быть использован для подписывания тем и программ, требующих capabilities из первой категории (см. список capabilities, приведенный в теоретической части).

После того, как формирование списка ключей завершено, можно переходить к процессу подписывания sis-пакетов. Подпись добавляется к каждому компоненту пакета индивидуально. Если это не embedded-пакет, то компонент всего один. Для embedded-пакетов нужно соблюдать правило: сначала должны быть подписаны встроенные компоненты, потому что подписи родительских компонентов в процессе подписи дочерних удаляются (так как перестают быть валидными).
Для добавления подписи к выбранному компоненту выберите нужный профиль из сформированных ранее пар ключей/сертификатов и нажмите на «Add signature». После формирования подпись будет добавлена в список. При подписывании embedded sis-пакетов следите за тем, чтобы напротив всех компонентов в колонке Signatures не было нулей (ноль означает, что компонент не подписан), иначе вы не сможете установить sis-пакет на устройство. После подписывания всех компонентов закройте окно работы с подписями и сохраните пакет, выбрав в главном окне SISContents пункт Files->Save as…
Если у компонентов sis-пакета уже есть какие-либо подписи, их можно удалить. Для этого выберите подпись в списке и нажмите на кнопку «Delete signature». Удалить подпись может понадобиться в случае, если срок действия предыдущего сертификата истек или пакет подписан self-signed сертификатом, а для установки требуется подпись сертификатом разработчика.
Как при подписывании sis-пакетов отличить какая подпись нужна, а какая нет? Во-первых, self-signed сертификат можно отличить от доверенного сертификата Symbian тем, что у self-signed поля кем и кому выдан сертификат (Issuer и Subject) совпадают. Для просмотра деталей сертификата в главном окне SISContents нужно дважды кликнуть на сертификате. Во-вторых, у сертификатов, выданных Symbian, в графе Issuer значится Symbian. Подписи Self-signed сертификатами можно удалять и заменять своими. Естественно, если компонент подписан сертификатом Symbian, удалять подпись нет необходимости, если только это не чей-то сертификат разработчика (они, как известно, тоже выдаются Symbian и, соответственно, имеют Symbian в графе Issuer). Подписи сертификатом разработчика легко отличить по сроку действия сертификата (3 года или 6 месяцев для старых сертификатов) и графе Issuer, где значение CN = Symbian Developer Certificate CA. Такие подписи тоже нужно удалять.

Ну и напоследок хотелось бы сделать одно замечание. В случае с embedded sis-пакетами, если часть его компонентов подписана Symbian, при просмотре capabilities необходимо определять, а не относятся ли эти файлы к уже подписанным компонентам. Для этого в SISContents можно просмотреть файлы встроенных компонентов отдельно, выбрав интересующий компонент в списке справа от строки с именем открытого файла.
Например, на скриншоте 5 видно, что пакет состоит из 4-х компонентов. Если просмотреть список всех его файлов, среди них можно найти те, которые требуют manufacturer approval capabilities, но эти файлы относятся к компоненту Symbian OS PIPS, которые уже подписан Symbian, а потому переподписи не требует. А вот срок действия компонента libavcodec истек, а так как файлам этого компонента достаточно self-signed сертификата (у него capabilities из первой категории), то старый сертификат можно удалить и подписать своим self-signed сертификатом.

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

Прикрепленный файл: 2314_skrinshoty-k-st.zip (146.99 кб)