ID_CAP_INTEROPSERVICES is a Windows Phone app "capability" flag that tells the OS to allow the app to access (specifically, create handles to) drivers by device name. This is useful because drivers run outside the security context of the OS, so they are not sandboxed, and thus if they offer IOCTLs (on Windows, DeviceIoControl codes) that can do useful things for us, we can use those IOCTLs to our own benefit.
This is the standard way that OEM apps do stuff which would normally not be possible, like controlling the cellular radios or accessing parts of the filesystem that are outside the app sandbox. Each OEM includes one or more drivers in their ROMs which support these operations.
On WP7, this was the way that early homebrew worked. Access to the filesystem (TouchXplorer, Advanced Explorer) and write access to the registry (Advanced Explorer, Registry Editor, Advanced Config, and others) were made possible by OEM-provided COM DLLs which in turn opened device handles and invoked IOCTLs to obtain the required access. Later, WP7 Root Tools worked by directly accessing the drivers and exploiting security vulnerabilities within them that Heathcliff74 had discovered to gain arbitrary code execution in the kernel. That will be harder on WP8 (assuming we even get that far) because of the many exploit mitigations in the NT6.2 kernel, but it's worth a shot. Even if we can't pull that off, though, there's a decent chance we could get something like the Windows RT "jailbreak" to work, and a good chance that we could get something like the old Advanced Explorer to work.
