yashsingh1/xdaforums huggingface dataset:
[Windows RT Development and Hacking] Pseudonym117:
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.

now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.

someone correct me if im wrong, but i believe im correct.
[Windows RT Development and Hacking] lseidman:
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
[Windows RT Development and Hacking] phailyoor:
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
[Windows RT Development and Hacking] xanderkaiber:
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.

Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'

If anyone knows a workaround to this we might be able to get it working
[Windows RT Development and Hacking] Pseudonym117:
well the simple way would be to sign it. HOW to sign it is a completely different problem... there may be a group policy change or registry edit to turn off signature verification, but i am not familiar with windowsRT at all.
[Windows RT Development and Hacking] danchar4:
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?

Since Office RT is a desktop app, one can only assume all of this is possible.
[Windows RT Development and Hacking] GoodDayToDie:
Windows RT is basically just Win8 recompiled for ARM, with one major exception: EXE files need to be signed by Microsoft before they will run. This means that MS can release desktop apps just fine - they have the signing keys, after all - but third-party software can't run by itself (as a desktop app) and will need to be bundled as an .APPX file (Metro-style app bundle).

If you want to try bypassing the signature check, there are a few things you could attempt. One would be to create your own signing certificate, install the public key in the OSes root code signing cert store (not the per-user store, though it qprobably wouldn't hurt to install it there too), and then sign your test apps with that cert. MS *probably* used certificate pinning - where a specific cert is used, rather than just any cert present in the OS of sufficient trust level - but they may not have, too. Alternatively, you could try looking for some legacy or debug functionality to disable the code-signing. Finally, you coul try using a built-in program, rundll, to invoke your applications.

I can't test any of this right now, because I don't have an RT device. There's a lot of research on them that I want to do, though.
[Windows RT Development and Hacking] mamaich:
Quote from one very old MS Windows 8 document, from those times when windows RT was called "woa" (2011). Everything could have changed from those days.

First we need to get hands on ARM device. I'd recommend Qualcomm-based, as chinese friends regularly leak their docs/sources. MS Surface is Tegra-based, so don't buy it :)
[Windows RT Development and Hacking] mamaich:
And one more thing:

Unfortunately I don't have “Enabling Debug Mode...” document, as I don't have access to connect.microsoft.com. Anyway it would not be helpful for us, end-users.

So to turn on a device to debug mode - you'll need a special "something" that is signed for your particular device. Sign is based on 2048-bit key, so you can't bruteforce it. But you can try to hack UEFI. UEFI is partially opensourced, so you can start to study its code now from edk2.sf.net

And one more way. Remember the test signing mode in Win7+. It is still present in Win8. Turn it on via bcdedit on your RT-device, use your own certificate to sign your driver or your program, ..., profit.

But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
[Windows RT Development and Hacking] xanderkaiber:
Just tried editing the registry to add a testing path. Didnt work :(

Still asks for certificate
[Windows RT Development and Hacking] mamaich:
According to MS document - this would work only on "debug mode"/"debug system" devices.

Can you turn on the test-signing mode:

In elevated CMD type:
bcdedit.exe /set {globalsettings} testsigning Yes
bcdedit.exe /set {bootmgr} testsigning Yes
bcdedit.exe /set {current} testsigning Yes

and try to sign your app with your own certificate I hope that test signing is still present on WinRT.

But first check that you are not using BitLocker (the "get-bitlockerVolume" command in admin's powershell). According to MS docs the retail device would not boot in this case (this info is taken from windows phone 8 "portico" docs, so may be unrelated to WinRT devices).
[Windows RT Development and Hacking] xsoliman3:
Theres some info on the web somewhere for a config change to VS2012 that lets it build ARM desktop apps

Not that you can run them due to the signing issues

http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-2012
[Windows RT Development and Hacking] xanderkaiber:
I did it!

I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran :)

Definitely a good sign
[Windows RT Development and Hacking] xanderkaiber:
Not a surface, a Qualcomm engineering sample device. But I imagine it would definitely work on the surface also.
[Windows RT Development and Hacking] mamaich:
Great news :)

Seems that turning on the test-sign mode would soon be a must on ARM devices, at least for those of us who need programs like VLC player, DosBox, FAR manager and so on.
[Windows RT Development and Hacking] xanderkaiber:
As far as I can see, you could port pretty much anything (as long as it's c++) if you can get the source code.

Might give VLC a try now ;)
[Windows RT Development and Hacking] SilverHedgehog:
Doesn't seem like a very good solution to me though.

While it's nice that progress is made, I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.
[Windows RT Development and Hacking] mamaich:
MS can't revoke the keys, as the keys are generated by you, and you can always generate new key and resign. But MS can easily issue the hotfix blocking the test-sign mode. This test-sign mode allows you installing non-MS (say, stolen/cracked) apps, and, obviously, MS would block this opportunity. Of cause there would be ways to skip this "fix", this is just a question of time.
[Windows RT Development and Hacking] netham45:
He ported Windows RT to the HTC HD2, also known as the HTC Leo. Since he has full bootloader control he can disable secureboot at will.

It's of no use to us.
[Windows RT Development and Hacking] Slymayer:
Ok. But at least we know how to compile for ARM without an error message now.
[Windows RT Development and Hacking] lilstevie:
but we could already do that.
[Windows RT Development and Hacking] clrokr:
Okay you guys, I found a way to change the required signing level. I'm trying to figure out how to automate this so everybody can profit. You basically use VS2012 to edit the last code page of a module that runs in CSRSS's process. Insert some hand-assembled ARM opcodes to trigger the (still not patched) exploit in NtUserSetInformationThread, set a breakpoint somewhere specific and hit it, then modify this instruction pointer PC to point to the hand assembled code. Boom.

As you can see, this is not quite ready for the general public.

I have built a proof of concept that loads ntoskrnl as an image resource and scans through the code segment to find the literal that points to the value we need to change. Using this offset and NtQuerySystemInformation it calculates the linear address of the byte that needs to be zeroed out and fixes the alignment.

Note that using the hand assembled code we can easily trigger the exploit 524288 times which would be impractical otherwise.

You can however set a trace point in VS2012 that displays a message and use the evaluation function to change memory just before NtUserSetInformationThread is called. For example, the last call to NtUserSetInformationThread in TerminalServerRequestThread is perfect for this. It hits every time you press a volume button. I got the signature level down from 8 (the address read 0x00080101) to 7 by pressing a volume button very often.

So, stay prepared.
[Windows RT Development and Hacking] netham45:
Any chance you could do a (more detailed) writeup of how to do it so we can start on automating it? I'll look at getting authentication going with the remote debugger from a metro app for now.

Edit: I was able to connect to the debugger with authentication disabled, though I'm just replaying the packets right now.
[Windows RT Development and Hacking] clrokr:
Reversing the protocol could be hard. I'm thinking about some kind of replay attack. The user would have to run my TIFKAM app that spits out the right address, fire up the Remote Debugger Monitor as administrator and then the app can connect via loopback and play the sequence.
[Windows RT Development and Hacking] netham45:
That's exactly what I'm looking at right now.

As far as the protocol goes, it actually doesn't seem too hard. I've got it connecting and requesting a task list, which is basically a tab seperated spreadsheet (0x01 = tab, 0x02 = new row). It even has labeled headers. Granted, I'm just replaying the connection part.

The only issue about doing a complete replay attack is that things like the PID and such are going to change, we're going to need those.

But, if you could post some more information on what you're doing (as in, how to do it), I could get that going.
[Windows RT Development and Hacking] clrokr:
I'm working on that. In the meantime, some good news. I managed to run my own desktop program, unsigned and everything. We have to compile the release version because the Surface doesn't come with debug runtime libs for C++.

One thing though: we need to attach to csrss.exe because the exploit depends on it. I don't think this is possible locally because stopping csrss effectively stops the computer (well, the whole Windows subsystem) and we can't send the network packages to continue.
[Windows RT Development and Hacking] netham45:
Sign on as a different user to spawn another instance of CSRSS, then attach it from the first user?
[Windows RT Development and Hacking] clrokr:
Have at it!

Circumventing Windows RT's Code Integrity Mechanism
[Windows RT Development and Hacking] netham45:
Excellent. Any chance you could post the app you're using to get the kernel's base address? Would be very appreciated.
[Windows RT Development and Hacking] clrokr:
Sorry, no. I don't trust MSFT's compiler, it may include some licensing info in the binaries. But it's really easy, you call NtQuerySystemInformation with information class 11 and make the output buffer really big (like 0x20000). The structure is easily recognizable when viewing the memory.
[Windows RT Development and Hacking] netham45:
#include <Windows.h>
#include <iostream>

typedef struct _SYSTEM_MODULE {
ULONG Reserved1;
ULONG Reserved2;
PVOID ImageBaseAddress;
ULONG ImageSize;
ULONG Flags;
WORD Id;
WORD Rank;
WORD w018;
WORD NameOffset;
BYTE Name[255];
} SYSTEM_MODULE, *PSYSTEM_MODULE;

typedef struct _SYSTEM_MODULE_INFORMATION {
ULONG ModulesCount;
SYSTEM_MODULE Modules[0];
} SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION;

typedef NTSTATUS (NTAPI *_NtQuerySystemInformation) (
ULONG SystemInformationClass,
PVOID SystemInformation,
ULONG SystemInformationLength,
PULONG ReturnLength OPTIONAL
);

BOOL GetKernelBase()
{
_NtQuerySystemInformation NtQuerySystemInformation;
PSYSTEM_MODULE_INFORMATION pModuleInfo;
ULONG i,len;
NTSTATUS ret;
HMODULE ntdllHandle;

ntdllHandle = GetModuleHandle(L"ntdll");
if (!ntdllHandle)
return false;
NtQuerySystemInformation = (_NtQuerySystemInformation)GetProcAddress(ntdllHandle,"NtQuerySystemInformation");
if (!NtQuerySystemInformation)
return false;
NtQuerySystemInformation(11,NULL,0,&len);
pModuleInfo = (PSYSTEM_MODULE_INFORMATION)GlobalAlloc(GMEM_ZEROINIT, len);
NtQuerySystemInformation(11,pModuleInfo,len,&len);

for (i=0;i<pModuleInfo->ModulesCount;i++)
{
if (strcmp((const char*)pModuleInfo->Modules[i].Name,"\\SystemRoot\\system32\\ntoskrnl.exe") == 0)
printf("[*] Driver Entry: %s at %p\n",pModuleInfo->Modules[i].Name,pModuleInfo->Modules[i].ImageBaseAddress);
}
return true;
}

int main()
{
GetKernelBase();
system("pause");
return 0;
}

If anyone else needs it.

Edit: Just getting a BSoD with this. Here's what I'm doing:

1) Get kernel base w/ app higher in post

2) Put base in the my_addr field in the source

3) armasm -o exploit.o exploit.asm

4) Taking the code starting at 0x64 (push r5) and putting it in Winsrv.dll!0x10800

5) Placing a breakpoint right after 'bl NtUserSetInformationThread (75475134h)' (Note that there are two calls to NtUserSetInformationThread, I've tried putting the break right after both)

6) Placing a breakpoint at mov r0,r0 at Winsrv.dll!0x10800

7) Resuming CSRSS

8) Hitting vol down

9) Moving PC to Winsrv.dll!0x10800

10) Resume, at this point I BSoD.

I've checked, and it BSoD's on the 'svc 1' line, citing csrss dying.

Here are the registers going into svc 1:

R0 *=*FFFFFFFE R1 *=*00000009 R2 *=*0117FCA0 R3 *=*0000000C R4 *=*00000013 R5 *=*0117FCA4 R6 *=*00000000 R7 *=*00080000 R8 *=*8381E000 R9 *=*755D1118 R10 *=*755D7A50 R11 *=*0117FCF8 R12 *=*000010E1 SP *=*0117FC38 LR *=*755C3645 PC *=*755D0822 CPSR*=*00000030
[Windows RT Development and Hacking] peterdn:
Looking great guys!

Fyi, I believe that my_addr should actually contain the address of the word we want to modify, i.e. in this case nt+0x19ffa4.

Otherwise I ran through those steps exactly and I'm getting the 0x18 REFERENCE_BY_POINTER bugcheck as described at the end of clrokr's blog post.

For every dump I have, address nt+0x19ffa4 contains the value 0x00080101. Does that look like what you guys have?
[Windows RT Development and Hacking] clrokr:
@netham45:

You need to add 0x18 to the address you supply in your step 2), because ObfDereferenceObject subtracts 0x18 from it, so it changes the wrong address in your case. I updated the article accordingly.

@peterdn:

0x00080101 looks right and is the reason we can do this without a bluescreen.
[Windows RT Development and Hacking] peterdn:
Oops, I forgot to add the 0x18 as well.

Will have another go in a few minutes.

EDIT: works beautifully :)
[Windows RT Development and Hacking] peterdn:
Utterly fantastic. Managed to compile PuTTY with not much trouble and it runs perfectly!
[Windows RT Development and Hacking] netham45:
I just tried a simple pure .net program (Form with a label on it) and the same .exe works on both my desktop and my tablet. I can't believe MS locked this out.

Edit: Oddly enough, running from a metro app has debug dlls, while running from desktop doesn't.
[Windows RT Development and Hacking] clrokr:
Awesome! Try out more open source stuff, I know I will.

I really don't get how the people on Reddit are so against having desktop apps on their devices. It works flawlessly. Probably a bad case of Reddit Reverse Psychology :)

It honestly just feels like my Surface's value has magically increased by $300.
[Windows RT Development and Hacking] peterdn:
Now, who wants to port Chromium? :D

The list of libs I needed (to make manually, as they aren't included in any SDKs) were:

comctl32.lib

imm32.lib

winmm.lib

gdi32.lib

advapi32.lib

ole32.lib

shell32.lib

comdlg32.lib

winspool.lib (from winspool.drv)

I'd be happy to send my *.libs and *.defs if that's allowed, would save you some time.
[Windows RT Development and Hacking] netham45:
That'd be very appreciated. I already sent you a PM about that a few minutes ago, heh.

Already working on getting Synergy going, too.

Edit: Holy crap, tons of stupid version number checks, freaks out if it can't find VS2010. :|

More edit: TightVNC seems to only be requiring a few missing .libs to build. I've got to go for a few hours, but when I get back I'll see if I can come up with a script to generate .libs for all the .dll's that x86/x64 has .libs for. Then we can give that to people, and not worry about distributing potentially copyrighted .libs.

Even more edit: Benchmark in 7z (Compiled by Cotulla):
[Windows RT Development and Hacking] samco08:
yeh !!!!!!!!!!!!!!!!!!!! amazing !

good job guys !

vlc ?

7zip ?

chromium ?

;)
[Windows RT Development and Hacking] peterdn:
I've whipped up a super simple C# app that generates a .lib from a .dll. It relies on dumpbin.exe and lib.exe being in %PATH%, so you just run it from the ARM cross tools command prompt. It works for all the .dlls I mentioned above, but I can't promise it'll work for everything -- it just does some very rough chopping to create the .def file.

Source & binary on Github: https://github.com/peterdn/dll2lib
[Windows RT Development and Hacking] vincepg13:
Great work guys looks like lots of progress. Hopefully this becomes possible for us with less knowledge of the subject. I just wanna run Utorrent :p
[Windows RT Development and Hacking] mamaich:
No need for that as we already have complete Win RT SDK (and WDK too, thanks to chinese guys).
[Windows RT Development and Hacking] netham45:
That's not exactly legal, nor can it be given to aspiring developers on XDA.
[Windows RT Development and Hacking] mamaich:
Yes. But this topic is also completely illegal as decompilation, reverse engineering and modifying Windows executables is explicitly prohibited in its EULA :)

Anyway, really good job is already done by clrokr. Unfortunately the value is hardcoded in ntoskrnl.exe, and is reseted to zero only when kernel debugger is initialized - in SepInitializeDebugOptions function in the case if SepIsUmciDisabled returns true ("\MACHINE\System\CurrentControlSet\Control\CI\UMCIDisabled" is set).

But there are some more checks, instead of that unnamed variable that allow loading of unsigned files. I'll download and look at the x86 Win8 checked build, as its files usually contain more information. Unfortunately we can't get the checked arm ntoskrnl...
[Windows RT Development and Hacking] mamaich:
Can someone check this idea?

First read this post: http://forums.mydigitallife.info/threads/39411-Windows-Product-Policy-Editor - it describes the way how you can edit the kernel policies (i.e. limitations in different OS editions). Check that the process is working on RT - a provided .NET program obviously would not work, so you should do the same manually (look into the source code, and don't forget to disable all sppsvc tasks in scheduler, or just set the "deny everything to everyone" NTFS right on sppsvc.exe).

I'd recommend to play with the "WorkstationService-DomainJoinEnabled" value, setting it to 1 would unlock the "join domain" button in "change computer name" window, so you'll easily see the result.

When you'll get the process working (I'm sure that it would work on RT too) - then here is the idea.

Look into the PoInitSystem disassembly of ARM ntoskrnl. It checks the Kernel-CsChecksDisabled policy (ZwQueryLicenseValue function), and if it is set to "1" - ignores the TESTSIGNING setting in BCD. And the TESTSIGNING flag is ignored by the WinRT kernel, as you've already found, so this may be the reason of such behavior.

And even more, you can play with the "SecureStartupFeature-Enabled" policies setting all of them to zero, but be careful as this may break the bitlocker and make your device unbootable.

I still have not ordered the device to test, so posting here the idea that I can't check myself yet.

If all my thoughts are right - you'll get a "testsign-unlocked" device. The process could be easily automated, so that any unexperienced user would be able to use it by running a simple VBS/CMD or powershell script. And if it would not work - I have tons of other ideas to check :)
[Windows RT Development and Hacking] WithinRafael:
Was this blog post written with the actual Visual Studio Remote Debugging tools in mind or did you use the WDK toolset? Also, did you hand jam the bytes into winsrv.dll using Visual Studio 2012's memory window? I was expecting some sort of copy-on-write semantics to kick in but Visual Studio seems to do some annoying sanity checks beforehand.
[Windows RT Development and Hacking] tq959:
Is that any guid of compile desktop programe on Surface RT?
[Windows RT Development and Hacking] mamaich:
You can't currently compile programs "on" RT as there are no native compilers, though GCC can be easily ported. You can compile programs "for" RT with Visual Studio 2012 running on your desktop, but you need to hack it a bit (described earlier in this topic) and provide it some additional import libraries.

But first of all you need to hack RT device to allow running the unsigned or testsigned apps. clrokr found one method, but it is really inconvenient for users (as you need to work with a debugger on your desktop PC). I've posted another idea, lets wait for someone to check it.

and please edit your post and remove unneeded screenshots from it.
[Windows RT Development and Hacking] WithinRafael:
Bitlocker and Secure Startup aren't related; you can actually disable and use Surface without Bitlocker. But you're right, might render the device unbootable.
[Windows RT Development and Hacking] netham45:
Bitlocker has already done it's thing far before the kernel is loaded, and even farther before those keys are accessed, I wouldn't worry about it.

I'm not sure what clrokr was using, but I used the remote debugger and the memory window in VS2012. I used a small vb program to use 'sendkeys' from a textbox to type into the memory window, since for some reason you can't paste to it.

For compiling, there are two issues: 1) Visual Studio tells you that desktop apps don't work on ARM, to fix this you need to go edit an XML value (It was mentioned at least twice in the thread), and 2) A large number of .libs are missing. You can either generate these yourself or use the (questionably legal) ones from the WDK.

I'll see if I can get a step-by-step guide typed up later, though I should advise that if you're the type of person who needs a step-by-step guide this hack may be a bit too complex for you in it's present state.
[Windows RT Development and Hacking] lilstevie:
did you ever manage to get it working properly? I tried following your instructions but every time it leads to bsod
[Windows RT Development and Hacking] netham45:
I didn't update my instructions. You need to add 0x19FFBC (0x19FFA4 + 0x18) to the kernel base that my program gives out.
[Windows RT Development and Hacking] samco08:
?

cool !

Do you think that Microsoft can patch your exploit ?

You think we should stop Surface Update until you provide us a tool or something like that ?

I dont know if you foresee to do that :confused:

@+