Although compatible with all Windows RT 8.1 devices with a suitable update level the Myriachan jailbreak is mainly useful for Qualcomm based Windows RT 8.1 devices (Dell XPS 10, Nokia Lumia 2520 & Samsung Ativ Tab) that are permanently prevented from applying the Golden Keys / Longhorn jailbreak due to the installation of Windows Updates beyond October 2016.
Requirements
Windows RT 8.1 installation that has not been updated beyond August 2015. Updates released after this date contain "Jailbreak Killing" updates that will prevent the installation of this jailbreak or reverse its effect if they are installed afterwards.
Third party applications are required to be test signed when running under Test Mode under Windows RT 8.1. See the SignTool page for further information.
Apply Myriachan Jailbreak
The use of this Jailbreak is entirely at your own risk.
Open PowerShell as administrator.
Copy or type the following commands into PowerShell and press Enter after each line.
Reboot, after rebooting check that Test Mode has been successfully activated by looking for the watermark in the bottom right corner of the Windows desktop. The Test Mode watermark may not be shown if Windows is not activated.
Windows RT 8.1 displaying "Test Mode" Watermark
Troubleshooting
Jailbreak Killing Updates
Where the Windows RT 8.1 installation has been updated beyond August 2015 the options are either attempting to manually remove the "Jailbreak Killing" updates or to restore the device using a Bare Metal Recovery image (Restoring from the Recovery Partition will not work).
Vulnerability title (Microsoft): Trusted Boot Security Feature Bypass Vulnerability
CVE: CVE-2015-2552
Vendor: Microsoft
Product: Windows NT series 8.0+
Affected versions: See "systems affected".
Reported by: "Myria"
Vulnerability Summary:
=====================
An attacker with administrative access to a Windows machine with UEFI Secure
Boot enabled may bypass code signing policy checks by putting intentionally-
malformed configuration options in the boot configuration database (BCD).
Vulnerability Details:
=====================
On a Windows system with Secure Boot enabled, Windows doesn't correctly
protect against attempts to enable features that are prohibited while UEFI
Secure Boot is enabled, such as "test-signing" and the local kernel
debugger. This allows things such as loading unsigned kernel drivers, or,
in locked-down Windows installations like Windows RT, effect a "jailbreak".
In Windows Vista and later, the boot configuration database ("BCD") is a
registry hive used by the operating system boot loader to load and prepare
the NT kernel (ntoskrnl.exe) for launch. In UEFI systems, this task is
split between bootmgr.efi and winload.efi. The latter is what contains this
vulnerability.
One of winload.efi's responsibilities is to take the settings in BCD and
translate them to a simple command line for the kernel, similarly to Linux.
When an attempt to enable a prohibited feature such as "test-signing" occurs
the standard way, winload.efi will block the attempt by not passing the
"/TESTSIGNING" command-line option to the NT kernel.
The BCD setting named "loadoptions" allows passing arbitrary kernel command
line arguments to the NT kernel. An obvious attack would be to attempt to
pass "/TESTSIGNING" by putting it into the "loadoptions" field. winload.efi
counters this obvious attack by checking against a blacklist of strings, but
fails to account for Unicode.
BCD, being a registry hive, stores all strings as UTF-16. To search for the
prohibited strings, winload.efi calls wcsstr(). However, ntoskrnl.exe takes
its command line as ASCII bytes. To do the conversion from Unicode to
ASCII, winload.efi simply truncates each UTF-16 code point to 8 bits.
The bug is then simple: winload.efi is checking against pre-transformed
data, while ntoskrnl.exe is checking post-transformed data. By replacing
character(s) of a blacklisted string with Unicode characters that become the
original character(s) when truncated to 8 bits, one can get past the
wcsstr() check while still passing the desired parameter to the kernel.
Proof of Concept:
================
In an Administrator-privileged instance of PowerShell, execute the
following command, then reboot:
bcdedit /set '{current}' loadoptions '/T_STSIGNING'
replacing "_" with the Unicode character U+0145 ("Latin Capital Letter N
With Cedilla"). The machine will come back up with test-signing enabled,
which can be seen by the watermark in the lower-right corner of the desktop.
Impact:
======
Users or programs with administrative access to a machine can escalate to
kernel privilege by loading unsigned drivers, or using the kernel debugger
to poke at kernel memory and gain arbitrary code execution.
Users can intentionally use this on their own devices to bypass lockdowns
for certain products (Windows Phone, Windows RT).
Mitigating Factors:
==================
- The attack requires administrative access.
- A watermark appears when this is enabled, but this is bypassable.
No public attack against systems for which the owner does not want the
exploit is known.
Systems affected:
================
UEFI systems with Secure Boot enabled running the following:
Windows 8
Windows 8.1
Windows Server 2012
Windows Server 2012 R2
Windows 10
Windows Server 2016 Technical Preview
Windows RT 8.0
Windows RT 8.1
Windows Phone 8
Windows Phone 8.1
Windows Mobile 10 Preview
Advisory:
========
https://technet.microsoft.com/en-us/library/security/ms15-111.aspx
Solution:
========
Install KB3088195.
https://support.microsoft.com/en-us/kb/3096447
(mismatched number intentional)
Disclosure Timeline:
===================
Discovery: Approximately summer 2013
Vendor notification: Unknown (*)
Vendor fixed vulnerability: October 13, 2015
Public advisory: October 13, 2015
Public disclosure: October 13, 2015
(*) The author, the original discoverer, did not report it. The author
believes that the disclosure happened in approximately spring 2015.
