OSBuilder8: процесс разработки

It is russian version of the article. Look below for english version.
Это русскоязычная версия статьи. Англоязычная версия расположена здесь:
OSBuilder8: The Process

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

Я обычно не публикую подробности о проектах, находящихся в активной (посмеялся) разработке. Но я решил напомнить читателям, что я всё ещё жив.

Как обычно, всё началось с идеи: “может, стоит перенести OSBuilder на Windows Phone 8?”
Тут есть важное замечание: не очень много устройств могут запускать кастомные прошивки в настоящее время. Это Huawei W1, HTC 8X/8S (теоретически), Samsung Ativ S.

Возможно, читатель, незнакомый с темой, спросит: “А что вообще такое OSBuilder?” Поясняю:
Это один из наиболее известных и полных инструментов для сборки самодельных прошивок для Windows Mobile и Windows Phone 7. В OSBuilder обычно интегрированы инструменты для сборки прошивки от начала для конца – можно даже не вылезать из интерфейса OSB. Программа изначально разработана Евгением (Barin‘ом), а впоследствии к её разработке подключился и я.

Вернемся к теме.
Т.к. у меня имеется инженерный Samsung Ativ S с предрелизной версией Windows Phone, я решил написать инструмент, который бы позволил обновить ОС до чего-нибудь более-менее нового, например, до обновления GDR3.
WP_000003 (16) 2

О структуре папок замолвите словечко…
В целом, почти все осталось в таком же виде, как оно было в Windows Mobile 6 или Windows Phone 7.
folderstructure1
А что касается путей к пакетам, то встроенный в OSB8 распаковщик образов использует пути следующего вида:
%ТипАвтораПакета%\%Автор%\RES_*\LANG_*\%Компонент%\%Подкомпонент%
(RES – разрешение экрана, LANG_ – язык).
Ах да. Под “пакетами” подразумеваются папки, содержащие всё необходимое для отдельных компонентов системы. Например, для калькулятора, календаря…

т.е., к примеру, путь к Microsoft.MainOS.Production (русской версии) выглядит примерно так:
SYS\Microsoft\LANG_ru-ru\MainOS\Production

О внутренностях пакетов
Пакет традиционно содержит *.dsm-файл (Device-Side Manifest – краткое описание пакета). Только теперь он в виде XML. Помимо этого, пакеты содержат файлы с записями реестра (.reg, .rga), с политиками безопасности (.policy.xml). Что касается названий файлов…
Я думал-думал, и решил оставить названия файлов в таком виде, в котором они бывают в обычных обновлениях системы в формате CAB (%магическое число%_%несколькобуквназвания%.%расширение%). Почему? Потому зачастую бывает так, что папка содержит несколько файлов с одинаковыми названиями, которые после установки пакета на реальное устройство на самом-то деле уедут куда-нибудь далеко (обычно это касается языковых файлов: они имеют одинаковые названия, но разные папки установки). Я не стал ради красоты увеличивать размеры путей на жестком диске собирателя прошивок. Ибо не забываем про лимит длины пути в 260 символов, который до сих применим к большинству приложений Windows.
folderstructure2

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

Проблема, собственно, в приближении порядка к оригиналу…

Порядок сборки пакетов
Порядок обычно записан в файлу \Windows\ImageUpdate\UpdateHistory.xml. Но не стоит ему полностью доверять 🙂 После многочисленных экспериментов я понял, что некоторые пакеты всё-таки надо двигать на верх списка. И хотя это не делает UpdateHistory.xml бесполезным, это ломает порядок сборки, что может вести к некорректным значениям в реестре, неактуальным политикам безопасным.

Политики безопасности
Это, возможно, самая трудозатратная часть всего процесса разработки. Нам надо пересобрать базу данных политик безопасности, чтобы она была синхронизирована с исходными .policy.xml.
Данная база данных содержит все правила по типу “Пользователь Ваня может открыть папку C:\Смешные Котики”, “Администраторы могут добавлять новых котиков в C:\Смешные Котики”. Без корректной БД, Windows Phone просто не загрузится.

Представьте: имеем такой файл:



  
    
      
        
          
        
      
    
  
  
    
      
        
      
    
  


На этот моменте вы, скорее всего, выкрикнули что-то непечатное. И вы будете правы. Таких записей много, они похожи, но нам-то всё равно их нужно читать!
И превращаем их в нечто подобное…

[HKEY_LOCAL_MACHINE\System\SecurityManager\Capabilities\ID_CAP_PRIV_IPOVERUSB]
"CapabilityFriendlyName"="IPOVERUSB private capability"
"CapabilityType"=dword:00000002
"ServiceCapabilitySID"=hex:01,06,00,00,00,00,00,05,50,00,00,00,0E,CA,9D,C3,4E,50,10,F0,CD,D3,29,76,70,48,BE,B2,4A,19,05,24
"Privileges"=hex:00,00,00,00
"EmbeddedWindowsCapabilitySIDs"=hex:00,00,00,00
[HKEY_LOCAL_MACHINE\System\SecurityManager\Capabilities\ID_CAP_PRIV_IPOVERUSB\Microsoft.BaseOS.IpOverUsb]
"PackagePrivileges"=hex(7):00,00,00,00
"PackageEmbeddedWindowsCapabilitySIDs"=hex(7):00,00,00,00
"SourceID"="ID_CAP_PRIV_IPOVERUSB@Microsoft.BaseOS.IpOverUsb"
[HKEY_LOCAL_MACHINE\System\SecurityManager\Capabilities\ID_CAP_PRIV_IPOVERUSB\Microsoft.BaseOS.IpOverUsb\PackageRules]
"B5320ADB6B754E2CCC033A46DD49B63FE82C64ED8FB2694FCFC277FE10C3DDF7"=dword:20000000
[HKEY_LOCAL_MACHINE\System\SecurityManager\ResourceAccessControl\OpaqueObject\B5320ADB6B754E2CCC033A46DD49B63FE82C64ED8FB2694FCFC277FE10C3DDF7\ID_CAP_PRIV_IPOVERUSB@Microsoft.BaseOS.IpOverUsb]
"DACL"="(A;;0x111FFFFF;;;S-1-5-80-3281897998-4027600974-1982452685-2998814832-604313930)"
"DefaultSettingsFlag"=dword:80000004

Немного лучше, хоть не сильно. Но Windows уже может использовать БД в такой форме.

Что характерно, тут в принципе нет документации “Как реализовать то-то”. Приходится анализировать. Я обычно делаю так: пишу код, как считаю нужным, а потом сверяюсь с оригиналом, выругиваюсь, исправляю. Нахожу какой-нибудь непонятный момент (как, например, странные числа в списке идентификаторов безопасности), ищу кучу примеров подобных записей, сравниваю… и в конце-концов прихожу к нормальному решению. Такому, при котором было бы ноль отличий в оригинальной и итоговой базах данных.
policy1

NTFS-разрешения
Вот прочитали мы эти политики безопасности. Теперь надо бы их применить к папкам и файлам. После сборки, разумеется.
В настоящий момент я устанавливаю пересобранную ОС сразу на телефон: форматирую разделы MainOS (файлы ОС) и Data (пользовательские файлы), кладу новые файлы, создаю т.н. символические ссылки (очень-очень грубо говоря, “незаметные пользователю ярлыки на папки/файлы”), а затем применяю права доступа и меняю владельцев файлов/папок. Это весьма быстрый процесс, но, опять же, без него система не загрузится.

Ах, как он красив!
И возникает мысль: а как же выглядит-то этот самый OSBuilder, о котором пишет автор данного опуса? А он прекрасен.
screenshot1
screenshot2
Пожалуйста, не толпитесь, когда будете пытаться нанять меня на работу дизайнером в вашу компанию.

“А как же все тестируется?”
Да просто: беру и сравниваю с оригиналом. Обычно это очень неплохая идея. Также я тестирую прошивку на Ativ S (время от времени). Раньше прошивки со старыми сборками ОС грузились прекрасно, а последние что-то перестали грузиться. Но исправлю.

И когда оно будет готово?
Наверное, в следующей жизни…
Неизвестно

Работай уже!
Работаю над проектом ровно столько, сколько могу. Обычно, два часа в месяц.

Спасибо за чтение и терпение при чтении столь скучной статьи.

Site Footer

Sliding Sidebar

© Maxim Menshchikov