[RT] Windows RT 8.1 Jailbreak Discussion

Search This thread

HandyBesitzer

Senior Member
Jan 29, 2012
587
109
Köln
just downloaded, installed, converted fuu to img and write to USB (with diskimager) after 5 minutes with a black screen and the surface logo on it, I aboard. Next I copied the c:/windows/system32/drivers folder to windows/system32 on the USB. Boot,... 15 to 20 minutes on the black screen with surface logo. So I aboard again.

Any suggestions why it does not work??
 

roxas22

Senior Member
Oct 6, 2014
72
5
just downloaded, installed, converted fuu to img and write to USB (with diskimager) after 5 minutes with a black screen and the surface logo on it, I aboard. Next I copied the c:/windows/system32/drivers folder to windows/system32 on the USB. Boot,... 15 to 20 minutes on the black screen with surface logo. So I aboard again.

Any suggestions why it does not work??
First,what you downloaded,second,what program you used for convertimg the files,third,it can't sork BECOUSE WE DON'T HAVE A METHOD TO UNLOCK THE BOOTLOADER,GENIUS
 

HandyBesitzer

Senior Member
Jan 29, 2012
587
109
Köln
First,what you downloaded,second,what program you used for convertimg the files,third,it can't sork BECOUSE WE DON'T HAVE A METHOD TO UNLOCK THE BOOTLOADER,GENIUS
1) This download: http://forum.xda-developers.com/showpost.php?p=66546577&postcount=219
2) converter: https://raw.githubusercontent.com/t0x0/random/master/ffu2img.py found here: http://raspberrypihq.com/how-to-install-windows-10-iot-on-the-raspberry-pi/
3) as far as i know others already got it working on the surface, booted from a USB device.
 
Apr 24, 2016
5
1
First,what you downloaded,second,what program you used for convertimg the files,third,it can't sork BECOUSE WE DON'T HAVE A METHOD TO UNLOCK THE BOOTLOADER,GENIUS

Hey roxas, it's not very helpful to piss off fellow users, even if you think HandyBesitzer's question to be unnecessary. Try treating people the same way you want to be treated. Also, we RT users are a small group to begin with, so we should stick together.
People on this board (e.g. black_blob - as you know) have reported it to be possbile with only little explanation how they did it, so valid question I think.

just downloaded, installed, converted fuu to img and write to USB (with diskimager) after 5 minutes with a black screen and the surface logo on it, I aboard. Next I copied the c:/windows/system32/drivers folder to windows/system32 on the USB. Boot,... 15 to 20 minutes on the black screen with surface logo. So I aboard again.

Got the very same result on my Yoga 11. In my case I'm stuck with the Lenovo logo.
 

roxas22

Senior Member
Oct 6, 2014
72
5
Hey man,sorry for my bad reply,but it's an exam moment and i'm very stressed,i think that don't work for the latest updates,but for this you have to ask to @OnbekendV
P.s Sorry again

---------- Post added at 09:59 AM ---------- Previous post was at 09:58 AM ----------

Hey man,sorry for my bad reply,but it's an exam moment and i'm very stressed,i think that don't work for the latest updates,but for this you have to ask to @OnbekendV
P.s Sorry again
 

Reacan

Member
Dec 8, 2015
6
1
Someone claiming that the secure boot on his RT device was disabled.

forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/Yoga-11-Secure-Boot-State-Off-How-to-enable-it/td-p/1234237
 

aq3e

Senior Member
Nov 10, 2008
88
11
Someone claiming that the secure boot on his RT device was disabled.

forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/Yoga-11-Secure-Boot-State-Off-How-to-enable-it/td-p/1234237
That is absolutely infuriating. Finally somehow a device shows up in the wild with an unlocked secure boot and just like that he patches over it and its gone. I know the device was his and he seemed to have no interest in "hacking" his device but we could have used that.
 

quartarian

Member
Jan 27, 2011
17
4
Akron
Hi All,
Quick question; theoretically speaking, if I were to modify an existing firmware update, sign with the test certificate, and use Myriachan's test mode exploit, could I potentially update the UEFI configuration?

I have a slight suspicion that the nvram values for the surface rt would mirror the nvram values for the surface pro. Why wouldn't they use the same UEFI code base after all.

Obviously this wouldn't be trivial but I figured I would see if it's even plausible before digging.
 

Qiangong2

Senior Member
Oct 31, 2014
1,452
380
Samsung Galaxy S20
Hi All,
Quick question; theoretically speaking, if I were to modify an existing firmware update, sign with the test certificate, and use Myriachan's test mode exploit, could I potentially update the UEFI configuration?

I have a slight suspicion that the nvram values for the surface rt would mirror the nvram values for the surface pro. Why wouldn't they use the same UEFI code base after all.

Obviously this wouldn't be trivial but I figured I would see if it's even plausible before digging.

Potentially, but as the UEFI code is reconfigured for ARM on RT, the nvram values would most likely be different

Sent from my Q5 using XDA Free mobile app
 

UsagiNZ

New member
Aug 12, 2016
1
0
Game changer?

Code:
https://rol.im/securegoldenkeyboot/

Could this be what everyone has been waiting for?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 23
    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.
    20
    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
    19
    Just got Kernel-mode working.
    12
    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.
    10
    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