47 minutes ago, AndyC wrote
@evildictaitor: You're still making the assumption that you have unrestricted access to the file system, there is no such guarantee that forthcoming updates to the kernel-mode parts of Metro won't prohibit that. At which point no amount of trying to circumvent it helps.
I am making no such assumption. You can load stuff like ntdll and kernel32 because they're not really files, they're kernel namespace objects. Additionally, if you take sysinternal's vmmap to a metro app you'll see that ntdll and kernel32 and so on are already loaded in your address space. All your app needs to do is find it and jump to it and you'll have called a Win32 api!
Yes, there is stuff you can't do in Metro apps, but that's not because of the WinRT libraries, it's because of the LowBox tokens in kernel mode. My point was actually that the on-boarding process doesn't really mean very much when it comes to protecting your apps.
Working on the assumption today that you'll be able to make arbitrary Win32 calls is just plain foolish, even for sideloaded apps.
You can make arbitrary Win32 calls. They might return STATUS_ACCESS_DENIED if they interact with the kernel and the kernel says no, but that doesn't mean you can't call them.
There's a lot of terminology abuse going on around here (since WinRT seems to mean wildly different things to different people), so I'll define what I mean when I say stuff:
Win32: All of the old-fashioned APIs in user-mode libraries such as ntdll, kernel32. Specifically when I say Win32, I don't mean Win32k or anything in kernel-mode (when I want to say that I'll say Win32k or "the windows kernel"). Win32 APIs might call the kernel (e.g. VirtualAlloc calls NtAllocateVirtualMemory, but I consider "NtAllocateVirtualMemory" part of "the kernel" and "VirtualAlloc" to be a Win32-api).
Kernel-mode: processor Ring 0, or system-mode in ARM.
"The kernel": ntoskrnl.exe and win32k.sys, and any other Microsoft drivers that are designed to service requests from user-mode (like Afd.sys).
WinRT: The APIs and framework of user-mode libraries for Metro apps. WinRT is only in user-mode.
Metro: The start menu thing for apps, as opposed to "Desktop mode".
On-boarding process: The process by which you submit a binary to Microsoft and they decide if it goes into the app-store
app-protection: The kernel-mode protections to stop metro apps doing something bad at the syscall layer. app-protection is only in kernel-mode.
Hence, "WinRT" sits on top of "Win32" in user-mode, and is protected by the "the kernel" in "kernel-mode" by "app-protection".
With those definitions, a Metro app can call any WinRT or any Win32 api. Indeed any user-mode app can call any WinRT or Win32 api. If that API tries to do a protected syscall it might fail (e.g. ZwLoadDriver), but that's not to say that the API can't be called.