Package structure considerations
Basic OSBuilder’s folder structure is left intact.
As for package paths. OSBuilder uses paths like these:
i.e. path for
Microsoft.MainOS.Production package (ru-ru) will look like:
I am yet to find anything better than keep file names the way they are in CABs
%magicnumber%*%fewlettersofname%.%extension%). Why? Because some files in the
package might have the same name but belong to different folders on real
device. Increasing folder complexity is a nasty idea (don’t forget about Windows
folder path limit - not saying anything about overcoming this limit).
For a better control over registry building process, I’ve made the
whole new registry parser. What we have: .reg files - easy to add. Simply add or
replace content of registry value in the given key. .rga files - usually they
are about adding something to
REG_MULTI_SZ (multi-string values). Order is
usually not important here, but I tried to keep it as close to stock as
possible. While adding content of .reg files is basically easy, the biggest
problem is to keep original order.
Package order can be found
\\Windows\\ImageUpdate\\UpdateHistory.xml file. But don’t head over to it.
Don’t fully trust it. After some experiments I realized that some packages
still have to be moved up. While it doesn’t render
useless, it might break real building order, might lead to incorrect registry
values, non-relevant policies etc… Trying to be careful here.
That’s probably the most time consuming part of the whole process. We have to
rebuild policy database (stored in registry) in order to keep it in sync with
.policy.xml files. Policy database contains all rules like
User Ivan can open
Administrators can add new kitties to folder
C:\\FunnyCats. Without correct database, it is impossible to boot Windows
Phone - it will simply fail in the beginning of the process (not really
beginning, but still). Imagine: you have file like this:
<?xml version="1.0" encoding="utf-8"?> <PhoneSecurityPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" HashType="Sha256" PackageID="Microsoft.BaseOS.IpOverUsb" xmlns="urn:Microsoft.WindowsPhone/PhoneSecurityPolicyInternal.v8.00"> <Capabilities> <Capability xsi:type="PrivateResources" ElementID="08826C28AC9B35E6DC9BEEE6CAB066A603CFBA91C157DD765F1EE7C475D0548D" AttributeHash="C4F906E3940D86900E1EDAE6241A799DF3918136DCB3686A3EBC66A71F9F12E1" Id="ID_CAP_PRIV_IPOVERUSB" SvcCapSID="S-1-5-80-3281897998-4027600974-1982452685-2998814832-604313930" FriendlyName="IPOVERUSB private capability" Visibility="Private"> <CapabilityRules> <Rules> <SDRegValue ElementID="B5320ADB6B754E2CCC033A46DD49B63FE82C64ED8FB2694FCFC277FE10C3DDF7" DACL="(A;;0x111FFFFF;;;S-1-5-80-3281897998-4027600974-1982452685-2998814832-604313930)" Flags="2147483652" Path="HKEY_LOCAL_MACHINE\SYSTEM\CONTROLSET001\CONTROL\NOTIFICATIONS\41C61D22A3BC8075" Type="WNF" /> </Rules> </CapabilityRules> </Capability> </Capabilities> <Components> <Service ElementID="EE71E815BB0E265E208AA56A3B2C4AEE3FFB782C26A41203AA65549F16F01780" AttributeHash="67E67DB70A5BE2BB6E8BCECABD139168A4E95C76A4E43A8E186C0C2527DFBBDF" SID="S-1-5-80-3281897998-4027600974-1982452685-2998814832-604313930" Name="IPOVERUSB" PrivateCapSID="S-1-5-80-3281897998-4027600974-1982452685-2998814832-604313930" Executable="\windows\System32\SvcHost.exe" IsTCB="No" SvcHostGroupName="IPOVERUSBGROUP"> <RequiredCapabilities> <RequiredCapability CapId="S-1-5-21-2702878673-795188819-444038987-1543" /> </RequiredCapabilities> </Service> </Components> </PhoneSecurityPolicy>
“Wow, that’s a lot of text”, you will say. And you’re right. There are a lot of entries like this and they all look similarly. Still, we need to parse all of them and make something useful from it. I turn it to something like that:
[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
Not much better. But Windows is ready to use it. Basically, there is no documentation “how to do that”, but I do analysis. I do things in the way I think it should be, compare to stock values and alter behaviour a bit. Repeating until 0 differences are found. Looks like that:
Based on the policies parsed above, I have to set correct NTFS permissions on the whole folder structure. After rebuilding, of course. Currently I install rebuilt OS right on device. First wiping the whole MainOS partition and Data partitions, then pushing new files, creating symbolic links, then applying permissions and set file/folder owners. Pretty quick process, in fact. Without it, OS doesn’t boot as well.
How does OSBuilder look?
At this point you might wonder how does this OSBuilder looks at all. It is unbelievably attractive. If you want to hire me for my designer skills… Oh, no! No queuing.
“How do you test it?”
Well… Just compare to stock. Not a bad idea usually. Also I test it on my Ativ S (from time to time). It was successfully booting older builds, but I’ve broken something and it doesn’t work right now. Not a big deal.