• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

[Q] Hacking Windows RT to Run Desktop Apps?

Search This thread


Senior Member
Oct 15, 2014
So the new method weirdly enough doesn't work for me, it doesn't do anything. Anything else I should be doing?
Last edited:

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:
    	push {r5-r8}
    	mov r7, 0x80000
    	ldr r8, my_addr
    	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
    	cmp r7,#0
    	b endloop
    	b -0xD1E6
    my_addr dcd 0x<Kernel Base>

    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.
    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.
    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.
    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.
    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.