[RT] Windows RT 8.1 Jailbreak Discussion

Search This thread
By:
Advanced…
T

Toxickill

Senior Member
Apr 29, 2013
78
37
If you have nothing to add to this discussion please do not post. Thanks

Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...

Thanks,

Toxickill.
 
Last edited:
T

Toxickill

Senior Member
Apr 29, 2013
78
37
LolitaPlus said:
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.

I think this is probably the only change.
Click to expand...
Click to collapse

Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
 
T

Toxickill

Senior Member
Apr 29, 2013
78
37
  • Like
Reactions: lloydo
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).

I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
 
  • Like
Reactions: Ferrybigger
T

Toxickill

Senior Member
Apr 29, 2013
78
37
GoodDayToDie said:
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).

I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
Click to expand...
Click to collapse

Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.

Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
 
Last edited:
T

Toxickill

Senior Member
Apr 29, 2013
78
37
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
 
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.

The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.

When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
 
Last edited:
T

Toxickill

Senior Member
Apr 29, 2013
78
37
GoodDayToDie said:
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.

The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
Click to expand...
Click to collapse

So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:

Code: 
[DllImport("ntdll.dll", SetLastError = true)]
        internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
                NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));

C# code of course but you could easily code in any language.
 
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
 
T

Toxickill

Senior Member
Apr 29, 2013
78
37
GoodDayToDie said:
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
Click to expand...
Click to collapse

Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.

Looking into this, might be worth a shot.
 
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.

Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.


EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
 
Last edited:
T

Toxickill

Senior Member
Apr 29, 2013
78
37
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.

Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.

Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
 
Last edited:
T

Toxickill

Senior Member
Apr 29, 2013
78
37
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?

Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."

It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb. :rolleyes:

Edit:

Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.

Lots of me rambling on about that, hopefully we get somewhere.
 
Last edited:
  • Like
Reactions: BIade
L

LolitaPlus

Senior Member
Oct 30, 2013
80
20
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?

Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."

It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb. :rolleyes:

Edit:

Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.

Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse

Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK

C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist

cdb is part of WinDBG
 
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx

EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
 
Last edited:
G

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...

They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
 
T

Toxickill

Senior Member
Apr 29, 2013
78
37
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx

EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse

Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.

Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
 
Last edited:
L

LolitaPlus

Senior Member
Oct 30, 2013
80
20
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...

They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse

I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.

Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):

https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE
 
You must log in or register to reply here.

Similar threads

N
  • Locked
  • Sticky
[Release] RT Jailbreak Tool
Replies
519
Views
1M
N
netham45
G
Desktop apps ported to Windows RT
Replies
1K
Views
2M
M
michael.santos
V
[Windows RT 8.1] Development Tool V3.0 BUILD XXXX
Replies
685
Views
340K
N
naytmare66
revxx14
[Q] Hacking Windows RT to Run Desktop Apps?
Replies
378
Views
348K
N
nar001
B
Windows Phone and Windows 10 Mobile for Surface RT
Replies
261
Views
276K
jwa4
jwa4

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 23
    N
    netham45
    Myria told me her current method for jailbreaking the tablet, I've gotten the hardest part replicated. I think I see a way to get it automated, at least to an extent, too. It's not going to be as straightforward as the 8.0 exploit, sadly, but it should be persistent.
    View
    20
    N
    netham45
    http://i.imgur.com/Y38fel5.png

    Edit: Did that bounty idea ever take off? :p

    Edit 2: PuTTY running: http://i.imgur.com/KGwAMo6.png
    View
    19
    N
    netham45
    Just got Kernel-mode working.
    View
    12
    G
    GoodDayToDie
    Mmm. An attempt at this summary you ask for...
    1. RT devices boot with UEFI, which is firmware that runs at the same level as the old BIOS but is far more advanced, effectively being its own mini-OS (many x86 devices allow you to boot into an interactive UEFI shell, from which you can run UEFI programs, for example).
    2. Flashing UEFI is often possible, but requires either that the firmware image support it or that an UEFI program to do so is available (I think; don't take this part as gospel). RT devices do, I believe, support firmware updates... but as you'd expect, they check them for Microsoft's cryptographic signatures.
    3. UEFI supports a feature called Secure Boot. This feature checks the UEFI programs that are run (such as the bootloader for an OS) for cryptographic signatures. The list of allowed public keys might be stored in the firmware image, or in a hardware security chip called a Trusted Platform Module (TPM). I suspect the TPM but am not sure. All RT devices are required to implement Secure Boot, and to not allow the user to disable it or add their own certificates to the trust list. The Windows bootloader is of course signed.
    4. UEFI can also store named variables in firmware, typically for the use of the operating system. In the case of RT, a variable which controls what signing level the OS enforces is apparently stored in the UEFI, and is supposed to be read-only. I don't know how easy or hard it would be to change this value, assuming we have Admin-level arbitrary code execution in Windows.
    5. With Secure Boot enabled, the Windows bootloader disables certain options. In particular, the kernel debug and the "testsigning" boot options are prohibited. This restriction is enforced by the bootloader, which is either informed by the UEFI of the presence of Secure Boot or queries for it (not sure). If it was possible to cause the bootloader to think Secure Boot wasn't enforced, we could use these options to jailbreak with relative ease.
    6. The Windows bootloader verifies the cryptographic signature on the kernel before loading it. Thus, modifying the kernel on-disk would prevent a successful boot, unless we could modify the bootloader too (to remove this check), but doing that would break the bootloader's signature and Secure Boot wouldn't allow it to run.
    7. The Windows kernel checks various sources (boot parameters, registry, and UEFI variables) for what signature level to enforce. Lacking the "testsigning" or "debug" boot parameter, the kernel takes the more-restrictive policy from the registry or UEFI. On RT devices, this policy (as stored in a UEFI variable) requires Microsoft-signed programs. Binary images without a valid Microsoft signature will not load or run, unless they are in an "AppContainer" which is an app-specific sandbox with Low mandatory integrity control (a "lowbox").
    8. All "Windows Store" (Metro) apps run in AppContainers, and any processes they spawn will also be in an AppContainer. We can modify ACLs on many securable objects in the system, such as files and registry keys, to allow AppContainers to access them. However, we cannot actually elevate the privileges that an AppContainer has, and lowbox tokens have a number of restrictions that largely prevent them from carrying out any kind of Administrative tasks.
    9. However, we can probably get arbitrary code execution as Admin anyhow, by using a debugger on the OS and attaching to a (Microsoft-signed) process running as Admin, then injecting executable code into the process' address space and creating a thread to run it.
    10. In fact, this is how the 8.0 jailbreak works: there's a vulnerability in a system call that allows modification of arbitrary kernel memory. However, this system call can only be made by one process, the CSRSS.EXE process started at system bootup. In 8.0, this process can be debugged and the vulnerability exploited. In 8.1, this process is "protected" meaning you can't attach a debugger to it, even if you have SeDebugPrivilege.
    11. Another vector for arbitrary code execution in RT is PowerShell. Although PS is supposed to prevent running arbitrary code that isn't in a signed script, there have been exploits to bypass this restriction. The exploits that were known for 8.0 have been patched in 8.1, but I believe there are more (that still work).
    12. There is an additional level of protection in 8.1: the kernel flag that controls the signing level is "protected" by PatchGuard, a complicated kernel watchdog system that periodically checks protected memory (usually things like IRQ tables and ISRs) and, if a change from the expected values is detected, bugchecks the kernel (Blue Screen Of Death). Patchguard can only be disabled using boot flags that Secure Boot prohibits.
    13. To make the 8.0 jailbreak work again, two things are needed: a way to attach a debugger to CSRSS.EXE (probably means making it not run as a protected process somehow), and a way to avoid PatchGuard crashing the system when it checks the signing level value.
    14. Other avenues towards a jailbreak, such as disabling Secure Boot in UEFI (enables modifying the bootloader and would also permit loading different OSes) or in Windows (would allow using Testsigning mode, where non-Microsoft signatures can be fully trusted anyhow), or changing the UEFI variable that tells the kernel to enforce Microsoft signing level, or finding a way to take advantage of the ability to launch unsigned binaries in an AppContainer but without a lowbox, would also be of interest. There may be some possibilities not listed here, too.
    OK, that wound up longer than expected. At least it's all in one place. Please, those who know, correct me or add additional info as needed. I probably also ought to add links to forum threads where some of these points are discussed in more detail, but it's late.
    View
    10
    X
    xsoliman3
    ok someones got to say it ...

    Please can you release what you have or the work in progress
    even if Patchguard isn't disabled
    So can at least run something (then put the flags back so Patchguard doesn't notice) and accept the 1-2% chance it might blue screen

    So other can build on it and investigate other ideas
    (eg I have an idea for a driver that might help)

    Or do a limited release to a few of us who are really interested

    Thanks
    View

New posts