[Q] Hacking Windows RT to Run Desktop Apps?

Search This thread

revxx14

Senior Member
Feb 6, 2011
328
60
Chicago
ghostlyco.de
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
 

phailyoor

Senior Member
May 17, 2012
172
56
www.hiddencreeksoftware.com
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.

Compiling desktop apps for ARM using VS 2012 gives an error message, but it can be bypassed. Not sure if the results will run in Windows RT though.

Of course there's no way to find out until Windows RT devices are released to the public, because everyone who has access to one is under NDA. Have some patience.
 
  • Like
Reactions: mstank12

Pseudonym117

Senior Member
Dec 26, 2011
58
47
Crystal Lake
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.
 

lseidman

Senior Member
Jun 14, 2011
229
103
Las Vegas
lance.compulsivetech.biz
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.
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.
 
  • Like
Reactions: sidbessi

phailyoor

Senior Member
May 17, 2012
172
56
www.hiddencreeksoftware.com
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.

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?
 
Last edited:
  • Like
Reactions: riboa

xanderkaiber

Member
Sep 15, 2008
35
3
Bath
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
 

Pseudonym117

Senior Member
Dec 26, 2011
58
47
Crystal Lake
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
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.
 

danchar4

Senior Member
Feb 27, 2011
53
9
Seattle
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?

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.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
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.
 

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
228
mamaich-eng.blogspot.ru
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.
Description of the change:
WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load. This document describes the technical steps required to enable unsigned test, development, or manufacturing applications to run. This document does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing.
Action required
In order for any test binary or tool to run on WOA platforms you must do one of the following:
· Register the install location of your test binaries as an exclusion path, OR
· Attach a Kernel Debugger and disable checking by setting the appropriate registry value
...cut...
2. Scripts - Scripts will be allowed to run if the script host (e.g. cscript.exe, cmd.exe, etc.) is Microsoft signed or is run under an exclusion path.
...cut...
How to register your test binaries in an exclusion path
...cut...
Exclusion paths are listed in the following registry key in REG_MULTI_SZ format:
Key: HKLM\SYSTEM\CurrentControlSet\Control\CI\TRSData
Value: TestPath
Paths added to this key should be in one of two formats:
1. Path (recursive): \Program Files\TestAutomationPath
2. Binary (specific): \Program Files\TestAutomationPath\mybinary.exe
Note: Do not include the drive letter of the volume. Each path will be excluded across all volumes.
...cut...
The following paths are restricted and cannot be added as an exclusion:
1. \
2. \Windows
3. \Windows\System32
4. \Program Files
...cut...
How to disable signature verification with an attached Kernel Debugger
To disable signing verification when a Kernel Debugger is attached the “DebugFlags” value must be deleted from the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI” registry key and the system must be rebooted. After this Signing Verification will not take place.
This can be scripted by putting the following in a .cmd script and executing with admin privilege:
cmd /c reg delete "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI" /v DebugFlags /f
shutdown -r -t 0
...cut...
Note: Enabling Kernel Debug will not be allowed by default on machines with Secure Boot enabled. Either Secure Boot will need to be disabled, or during boot the F8 menu selection to EnableDebugging must be chosen.
...cut...
At a later point, changes will be made to Windows 8 builds which will enforce that only machines configured as “Debug System” will support exclusion paths.
A “Debug System” is will initially be identified by the presence of the Microsoft Test Signing CA in the UEFI signature database (“db”).
...cut...
Note: If there is a need to run unsigned tools, the system can be configured as a “Debug System” during manufacturing but there must be a step in the production process that removes the Microsoft Test CA.
Production machines must not ship with the Microsoft Test CA in the db.
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 :)
 

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
228
mamaich-eng.blogspot.ru
And one more thing:
This document “Enabling Debug Mode for Development, Manufacturing, and Support of Windows RT Devices” discusses placing a production device into ‘Debug Mode’ is accomplished by creating a per device Windows Debug Policy using tools provided by Microsoft.
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...
 
Last edited:

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
228
mamaich-eng.blogspot.ru
Just tried editing the registry to add a testing path. Didnt work :(
According to MS document - this would work only on "debug mode"/"debug system" devices.

Can you turn on the test-signing mode:
Code:
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).
 
Last edited by a moderator:

xsoliman3

Senior Member
Jan 25, 2012
113
34
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.

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
 

xanderkaiber

Member
Sep 15, 2008
35
3
Bath
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
 

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
228
mamaich-eng.blogspot.ru
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 :)

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.
 

xanderkaiber

Member
Sep 15, 2008
35
3
Bath
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 ;)
 

SilverHedgehog

Senior Member
Oct 30, 2010
458
163
Cupertino
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.
 

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
228
mamaich-eng.blogspot.ru
I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 17
    This would be fantastic.

    Other than one bug I just tracked down I've got everything except getting the kernel base automated in a batch file + debugger.

    Edit: Here's what I've got so far. To use:

    1) Install the app in the top of THIS thread (Sorry, you'll have to compile it for now, I'm working on a clean app I can package, but it's not ready yet)
    2) Copy the 'getKernelBase.exe' from the ZIP attached to this post to the folder it installs to (%userprofile%\appxlayouts\<appname>)
    3) Run the app, click the button
    4) Click OK on the prompt, type 'getKernelBase' into the command prompt. If it doesn't do anything, snap the app to the side of your screen.
    5) Keep the 4 numbers it gives you
    6) Open 'runExploit.bat' as an administrator
    7) Put those 4 numbers in there, make sure you keep the spaces between them
    8) Press enter
    9) Press Volume Down
    10) Press enter again
    11) You should be jailbroken now.

    And a writeup for what I'm doing for my hack:
    It's mainly the same basic hack as clrokr, but I found a way that I could write process memory using cdb (but, I can't attach as a debugger, so I lose breakpoints)

    I change winsrv.dll+0x3644 to redirect to winsrv.dll+0x10800

    I inject this modified payload at winsrv.dll+0x10800:
    Code:
    	push {r5-r8}
    	mov r7, 0x80000
    	ldr r8, my_addr
    loc_loop_begin
    	movs r3, 0xC
    	add r2, sp, 0x68 ;0x58 org.
    	add r5, r2, 4
    	str r8, [r5]
    	movs r1, 9
    	mvn r0, 1
    	mov r12, 0x10E1
    	svc 1
    	subs r7, r7, 1
    	cmp r7, 0
    	bne loc_loop_begin
    	pop {r5-r8}
    	mov r7, r0
    endloop
    	cmp r7,#0
    	b endloop
    	b -0xD1E6
    my_addr dcd 0x<Kernel Base>
    	end

    That then gets called when you press vol down. It hangs at the loop at the end so it doesn't execute the exploit twice (which would crash the tablet)

    I then reset winsrv.dll+0x3644 back to default
    Once it's default, I zero out 'b endloop', allowing it to progress to the b -0xD1E6 and resume execution

    cdb -pvr <pid> attaches to <pid> in non-invasive mode, which grants the ability to see loaded modules and change ram but not debug (pause, resume, break, manage breakpoints, get debug events), since there's no debugger actually attaching. That's why it works on the ARM too.

    And that's it.


    Edit: I missed something, it's not working in the zip. I'll check it real fast.
    More edit: I see what I did, fix in a couple minutes.
    Even more edit: Should be fixed, the offset I had at the bottom of the payload was off by 0x6.
    Super edit: Nope, something is still up. It works perfectly if the debugger is attached to csrss, but if not it crashes. =/
    Super-duper edit: seems to work intermittently, I'm not 100% sure why it crashes some of the time, though.
    Mega Edit: One of the offsets I'm using changes randomly between a few different possibilities, I'll see if I can come up with some way to generate the code for it.
    9
    I just got the exploit running using only on-tablet programs, I should be able to bundle it into a nice little app where you just have to click one or two things.
    9
    Got Mouse Without Borders (MS-Made Synergy-ish app) working.
    Simple guide:
    Install it on desktop
    Copy the folder out of the program files to the tablet
    Open admin command prompt on tablet
    run sc create MouseWithoutBorders binpath="c:\Path\To\MouseWithoutBordersSvc.exe" (Fix the path)
    Open services.msc, start the service you just created
    It'll then prompt to set it up.
    7
    Pardon if I misunderstood, but why *not* decrement it oh, 0x7FFF0 times? That way, if it was 0x80101, it will now be 0x00110 (which is maybe not ideal, but depending on what those other bytes represent it might still work) and if it was 0x80000, it will now be 0x0000F (which again may be less than ideal, but won't be the fully zeroed-out value).

    Working on that exact thing right now. Should have a result momentarily.

    Edit: Seems to have worked, at least for the initial test. If all goes well, I should be able to get a 100% exploit rate.

    Edit 2: 3 for 4 so far, with the one that failed being because the offset was off.

    Edit 3: Still getting a crash. Going to try 0x7EFF0 instead of 0x7FFF0.

    Edit 4: Seem to at least be getting a higher success rate with this method.

    Edit 5: Hopefully not jumping the gun, but I seem to have gotten it except in the occasions where the offset is not what I've preprogrammed. I think I've got a means to fix it when the offset is wrong, but I haven't actually managed to get a debugger attached recently when it was wrong.

    Edits are fun: I've tried it 7 times now, all worked. I've never had that success rate with it before, I'm going to call this one fixed.

    More edit: It's odd, it only seems to give the SYSTEM_SERVICE_EXCEPTION when I don't have a debugger attached. Guess I get to go dig through a memory dump. Does it make sense that the debugger would be shifting everything down (0x....3646 -> 0x....3644) just by having a debugger on?

    Edit 8: I can say with 75% certainty that I've fixed the 0x18 bugcheck.

    Edit 9: I think the bug might be caused because the debuggers I'm using in the script don't have the PDB loaded for winsrv.dll, I'm going to give it the PDB and see what it does.

    Edit 10: I've found out that the crash happens reliably if the exploit is ran within a few seconds of the system booting, it seems to work best if you wait at least a minute after logging in before running it.

    Edit 11: Please see THIS THREAD for what I believe will be the final version of my jailbreaking tool.
    7
    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.