Yes. Desktop EXEs can do absolutely anything on the entire system on Windows 8. This includes running desktop EXEs on Windows RT.
Officially, a subset of the Windows Runtime API (the store apps API) is already available to desktop apps.
[HACK] Using complete Windows API in Windows Store app (c++)
- Thread starter mamaich
- Start date
Yes. Desktop EXEs can do absolutely anything on the entire system on Windows 8. This includes running desktop EXEs on Windows RT.
Officially, a subset of the Windows Runtime API (the store apps API) is already available to desktop apps.
Agreed, but hardly a subset that takes advantage over the most useful! eg. my desktop app still can't use wns push, even though it s available on winrt...
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
15As we know, MS prohibits using most of standard Win32 API in Windows Store applications. Obviously there are lots of ways to overcome this limit and to call any API you like, if you are not going to publish your app on Windows Store. And here is one of them.
Idea is really simple and rather old (lots of viruses use it): search for kernel32.dll base in memory, then parse its exports for LoadLibraryA and GetProcAddress, call them - and get profit.
Writing here so this post can be indexed by google.
Partial code:
Complete project is attached. It contains sources and compiled appx files for side-loading.Code:void DoThings() { char *Tmp=(char*)GetTickCount64; Tmp=(char*)((~0xFFF)&(DWORD_PTR)Tmp); while(Tmp) { __try { if(Tmp[0]=='M' && Tmp[1]=='Z') break; } __except(EXCEPTION_EXECUTE_HANDLER) { } Tmp-=0x1000; } if(Tmp==0) return; LoadLibraryA=(t_LLA*)PeGetProcAddressA(Tmp,"LoadLibraryA"); GetProcAddressA=(t_GPA*)PeGetProcAddressA(Tmp,"GetProcAddress"); CreateProcessA=(t_CPA*)PeGetProcAddressA(Tmp,"CreateProcessA"); HMODULE hUser=LoadLibraryA("user32.dll"); MessageBoxA=(t_MBA*)GetProcAddressA(hUser,"MessageBoxA"); MessageBoxA(0,"A native MessageBox!","Test",MB_OK); STARTUPINFO si; memset(&si,0,sizeof(si)); si.cb=sizeof(si); PROCESS_INFORMATION pi; CreateProcessA("c:\\Windows\\system32\\cmd.exe",0,0,0,FALSE,0,0,0,&si,&pi); }
Code compiles fine for x86/x64 and ARM, tested on x86/x64. Can someone test it on ARM? Ability to sideload metro apps is required.
The application should output a MessageBox, then execute cmd.exe.
A note: Windows Store application runs in a sandbox and as a limited account, so most of API returns "access denied". You can check this in a launched CMD - it displays "access denied" even on a "dir" command because normally "modern ui" apps don't have even read access to c:\.
To overcome this - add "all application packages" full control to the directories/objects you like (for example to c:\).2There are no code signature checks from the command prompt that you launch.
Code:#include <iostream> void main() { std::cout << "Hello RT World!\n"; }
Compiled as an exe with info in http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-20121
Great seeing you again!
Anyways, I determined from some work with the VS Remote Debugger that the integrity checks are enforced in ZwCreateUserProcess. But, I bet LoadLibrary has its integrity checks in user-mode, since it normally doesn't access any functions using a call-gate to the kernel on Windows 7, which would mean we can modify it to allow us to load unsigned DLL's.
However, with this vulnerability, I had a different. What about allowing a native application to open, such as Notepad, and before it reaches the entrypoint, remotely injecting a different application to be ran (this would involve some sort of custom LoadLibrary + CreateRemoteThread pair of functions)? With the VS Debugger, you can already attach to any native process in user-mode and modify running code, data, and even the context (e.g. registers and similar data).
