[Windows Phone 7 Development and Hacking] Heathcliff74:
At the moment I'm working on an app called "WP7 Root Tools". I got the registry editor almost finished, but I am also going to add a File Explorer, Certificate Stores and maybe more. When the registry editor is working I will release the first alplha-version. As the title of the app implies, the tool uses root privileges to perform queries and transactions. I let the tools parasitize other processes to get the code executed in the TCB chamber of the device. I have this working stable now on my Samsung Omnia 7. Unfortunately I have to use a little bit of device-specific API's to do this. And I have to make quite a detour to make it work, which has a negative impact on the performance.

So the ultimate goal is that, in the end, this will work with other, more direct API's, which work on all devices. During my research I found some possiblities that need more investagation. I already decided that I will first concentrate on getting this working with my Samsung device, so that I have at least the tools to do further research. But I thought I'd drop some of my findings here that may lead to better device-support and better performance for future-versions of the tools.

There are many ways that may lead to executing code with elevated or root privileges. But in this post I want to concentrate on XML provisioning. A lot of info can be queried and configured through these API's. I have tried to call the native OS functions for XML provisioning. The function you need to call is: DMProcessConfigXML(). And it is declared in: Cfgmgrapi.h. If you call this function it returns errorcode: 0x4ec (or 0x800704ec), which means "Access disabled by policy". If you use a native COM dll and you forget to add ID_CAP_INTEROPSERVICES to the WMAppManifest.xml, you will get the same errorcode when calling a native function through the COM-interop. So when I get the same errorcode when calling DMProcessConfigXML() this may suggest, that I might be missing a capability in the WMAppManifest.xml.

In another thread on this forum some undocumented capabilities were discussed. One of them was ID_CAP_WAP. Since OMA Client Provisioning is also call WAP-Provisioning, I thought that might be the missing capability. I was not able to add the capability from within Visual Studio, because the capability is missing from the corresponding xsd's so it will give an validation error on building the project. But I could add it manually after the project was build. When I deploy it to the device, using the Application Deployment tool, it would return "Access is denied". I thought it might be an invalid capability, but when I changed the capability to ID_CAP_XXXXXX that would return "Install failed. Fix the capabilities." which is the real error message for an invalid. That implies that ID_CAP_WAP is in fact an existing capability, but I'm just not allowed to use it. When I would be able to use it, I would probably have access to the function DMProcessConfigXML(). That part of the app would be impesonated into higher chambers.

So the big question is what is keeping me from using the ID_CAP_WAP? Why am I not allowed to use it? I tried to attach a debugger to XapDeploy.exe, but it does not throw any exceptions at all. The errorcode is generated in the phone. Getting this fixed will give a big boost to getting closer to root access on all devices. Any help or insight on this will be appreciated.

Heathcliff74