I don't think you quite understand the problem. The libs work fine. They just aren't written for high-privilege access, so they don't do what it takes to get it. Here's how a normal native function call works in WP8:
1) Managed (.NET) code calls a function in a .WINMD file.
2) The .DLL corresponding to the .WINMD is loaded into the process address space, if not already present. The native function matching the one the program called is identified.
3) The function's parameters are "Marshaled" into native code parameters, which (among other things) converts a .NET System.String object to a C++/CX Platform::String object.
4) The native function is called, and executes within the process that called it. It has no more or less privileges than its caller. During this process, the native code may call other native code.
5) The return value of the native function is marshaled back into managed types.
6) The managed code receives the returned value and proceeds to do whatever its next instruction is.
Note that every part of this happens inside the app's address space. Therefore, every part of it happens with the app's token (apps don't have enough privileges to impersonate, in case you were wondering). App tokens tend to have very little access. Some capabilities that are available to OEMs give extra access, but it's still basically just a whitelist of places you can reach. The ID_CAP_INTEROPSERVICES capability is a little different. It says that an app can make Remote Procedure Calls (RPC), which means the app can now tell other processes to do stuff, and that stuff gets done outside of the app and therefore with different privileges. Here's now that works:
1-3) Same as above.
4) The native function is called. Rather than executing the operation itself, it instead opens a connection to a particular RPC service, assuming such a connection isn't already open. The native code then marshals its parameters again, but instead of marshaling them for managed/native interop, it marshals them to be passed between processes.
5) The native function uses a native Windows mechanism for communicating between processes (inter-process communication or IPC) to tell that RPC service "hey, call function X with these parameters" and passes the parameters.
6) The native function - indeed, that whole thread of the app - stops executing for a while. On the RPC service, a thread that was waiting for an incoming call wakes up.
7) The RPC service receives the request to run the function, and the parameters to run it with. The function begins executing within the RPC service, using the RPC service's security ID (usually SYSTEM, the Windows equivalent of "root").
8) The RPC service completes execution and marshals the return value for passing back to our app, then passes it back over the channel that the request came from.
9) The native code in the app, having received the result of executing the function, wakes up and marshals the response from the RPC server from native types to managed types.
10) Same as #6 above.
Those extra steps - sending the function over to the RPC service to have it executed under different privileges, and then waiting until the RPC service does so and sends the result back - are why some function calls run with much higher privileges than others. You can't just make a high-privilege copy of a library; first you need to even *find* a high-privilege RPC service that will run that function, then you need to write the code to open a connection to the service, pass it the function call, and receive the response. Nokia might not even *have* a RPC service that allows writing to arbitrary memory locations. If it does, there's no RPC client - the native library we have our app use - which will do that, so we would first need to find the RPC service and figure out how to call it, then write the RPC client to make the call. This is not impossible (assuming such a service really does exist) but it's not a simple thing. If that service doesn't exist at all, we are in trouble.
There are still other cool things you can do with this kind of access. For example, some of the stuff that our registry tweaks do is in locations which an OEM app could write to, so we can hijack an OEM app's chamber to do that for us without worrying about RPC at all. This includes things like creating special accent colors, but not things like Full FS Access (that requires writing to places OEM apps can't even *read* unless they have an RPC service do it for them). It also expands the area we can search for other, better hacks. But it looks like HTC and Nokia may have been a step ahead of us even here.
