[Windows Phone 8 Development and Hacking] GoodDayToDie:
A happy Diwali to you too!

There are two completely unrelated problems you're having with reading things like the MaxUnsignedApp value. One of them is that the access control lists - the standard NT security model ACLs, same as you'd find on your PC - don't allow low-privilege apps to read some parts of the registry. Even the AllCapabilities version of the webserver can't read everywhere. The other problem is that the webserver itself has a glitch right now where sometimes it closes a socket before sending the full response. I'm trying to figure out why, and fix it. In any case the solution is to simply not display those registry keys. On an interop-unlocked phone you can get specific values, if you know their names, but getting the key (with the list of all its values) is not so easy.

The OEM components don't need to be "pre-registered", exactly. There are two types of OEM components. The first type is a driver or other Windows service that runs with high privileges - usually SYSTEM - and offers an inter-process communication channel (usually RPC and/or IOCTLs) which OEM apps can use to request privileged operations. This type is baked into the OEM firmware and requires both a signed binary (almost always in the System32 directory) and at least one registry key. Any process that has ID_CAP_INTEROPSERVICES can call into these services, but knowing *how* to call into them is a trick. The other OEM components are application libraries which communicate with the first type. Apps (usually OEM apps) load the second type - WP7 used explicit COM interfaces, WP8 uses WINMD interfaces for C++/CX libraries - and call their exported functions, which the libraries translate into inter-process calls to the SYSTEM services. The libraries are parts of OEM apps, not parts of system firmware; they are installed out of .XAP files and run with the privileges of the OEM apps (since OEM apps have INTEROPSERVICES, the second-type libraries can call into the first-type components). These second-type components don't need to be registered in any way that I'm aware of; in a sideloaded app, you can use modified or from-scratch versions of them. However, any app that uses them needs ID_CAP_INTEROPSERVICES, or they can't do anything useful because they can't talk to the system services.

I'm really not sure what exactly you're asking in the third question. If you're wondering about replacing the OEM service binaries - the first-type stuff that runs as SYSTEM - with our own code, that's not possible because the SYSTEM chamber requires that all binaries be signed, and modifying the library would break the signature. If you're wondering about replacing the OEM libraries - the second-type stuff - then there's a problem. There's no inherent reason it won't work - you don't even have to mess with the SD card; I wrote a second-type library from scratch on WP7 and it worked fine - but while reverse-engineering an IOCTL interface isn't too hard, RPC looks to be a lot harder. Nobody has yet come up with a way for us to call the RPC functions of the system services directly, so that's why we're all still using the OEM libraries for now.