[Windows Phone 7 Development and Hacking] Heathcliff74:
And suddenly it hit me. I think I understand why we get the 1260/0x4ec/0x800704ec when trying to write to the \Windows\Security\policydb.vol. The reason is that PolicyLoader.exe really doesn't have any privileges at all. There is not one file in the IMGFS partition that references PolicyLoader.exe. That means that PolicyLoader.exe is either used offline (by Platform Builder or something), or it is only called on (first) boot from another partition (SPLDR or something). In any case it is not launched within a running OS. And so it is not launched when the PolicyEngine is active. And therefore there are no policies anywhere in the policydb to grant any permissions or privileges to PolicyLoader to be run in a live OS.

So, where does that leave us? I see 4 possibilities. To be honest, only 3 of them are kind of realistic.

This option is not really realistic, but I'm going to mention it anyway for in case all other options fail. We could port the PolicyLoader, including all referenced dll's and the policydb.vol to an WM6 emulator and try to get it running there. The whole new security model of WP7 is not in effect there, so that should grant us the permissions to modify the policydb.vol. I think the main-problem with this is CoreDll.dll. If we don't port it, the CoreDll from WM6 will be used by the PolicyLoader and there is a big chance of incompatibility. If we do port the CoreDll from WP7 to WM6 there is a big chance that the CoreDll is not compatible with the WM6 kernel. It is also possible that the rommodules are not 100% correctly reconstructed with RecMod, which may result in failure.

Use native database access to edit the Policydb.vol. To do that we need to copy the Policydb.vol to the isolated storage of our app that will be dedicated for this purpose. From there we need to use the API to modify the database. When we inserted the policies we want, we'll copy the database back. My exploit has TCB access for file-transactions. That is not a problem. There is however a very big challenge in writing the database-access in native C++ without debugger. Another problem is that we can't test this in the emulator, because the exploit doesn't work in the emulator. Modifying the database can be tested, but copying back the modified database is kinda risky.

We could try to find a way for the PolicyLoader to do its work without the need for privileges. For that we need a location on the filesystem that is completely unrestricted and accessible to "Everyone" = "S-1-5-112-0-0XFF". Well, luckily there is. I first thought of \Temp\, but you need at least Standard Privileges for that and the PolicyLoader doesn't even have that. But I found this in the policies:

<Rule PriorityCategoryId="PRIORITY_STANDARD" ResourceIri="/FILESYS/PRIMARY/APPLICATION%20DATA/PHONE%20TOOLS/10.0/CORECON/LOGS/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="\Application Data\Phone tools\10.0\CoreCon\Logs is folder that can be used to collect CoreCon diagnostic logs">
<Authorize>
<Match AccountId="S-1-5-112-0-0XFF" AuthorizationIds="FILE_ALL_ACCESS, FILE_GENERIC_READ, FILE_GENERIC_WRITE, FILE_GENERIC_EXECUTE, FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES, FILE_LIST_DIRECTORY" />
</Authorize>
</Rule>

So it seems that \Application Data\Phone Tools\10.0\CoreCon\Logs\ can be used for this. Like the previous option, we'll copy the the policydb to this location. We can try to modify this database with PolicyLoader, using option /pdb pointing to our new location with write access. We can verify the output XML's. If that looks good it is pretty safe to copy the modified database back to the original location. For the same reason, this can't be tested in the emulator, only on our device.

Last possibility is to copy our own Homebrew.Policy.xml to the \Windows folder and somehow try to trigger a merge for that. But we need to find out if and how this is triggered. If the policydb is only merged by Platform Builder, this will not be possible for us. But somehow I think it is possible, because an OS update should be able to add new executables and add policies for that. So I think such a policy-merge is triggered from one of the other partitions, when the device is rebooted after an update. If we are really lucky, this happens on every reboot. In that case we only have to copy the xml to \Windows and restart the device. During boot (before the PolicyEngine is up) the system will look for new policies and add them to the database. This can be tested by creating a Homebrew.Policy.xml with a dummy policy (non-effective) and place it in \Windows and restart. We can check the xml's afterwards. If it doesn't work, we'll need to find out if there is a registry-setting or something else that might trigger a 'Policy collection'. Again, for the reason of copying files to \Windows, this can only be tested on a device and not in an emulator.

I think we should begin looking at option 3 and 4.

Ciao,

Heathcliff74