[Windows RT Development and Hacking] CrackTheSurface:
I am still active pls help me/us

Hi, I am following this thread for several years and always tought that a Linux touch tablet would be very nice thing.

I started investigating with no more than interest in Linux and learned a lot about it in my free time.

Now I want to share my knowledge that I gathered the last year(s).

I saw that this thread is still active, and at the moment I have enough time to waste. :(

In the following I will sum up what you can find in this and other threads and than i will tell you what i tried so far.

This thread contains tutorials for downgrading Windows 8.1 to 8.0 which is necessary, because we need all security holes which existed back then

Downgrade Tutorial, I didnt tried yet but will in a few days and let you know

Further i suggest uninstalling all Windows Updates which are installed after the downgrade.

Then you should Jailbreak your Surface RT Jailbreak Original(?)

Jailbreak in this thread

Download the Grub files from this thread (same link as Jailbreak)

Grub files

Try to run the grub files which are provided in this thread, if it works you can join developing Linux for Surface RT

As far as I know this is the furtherst documented progress one did and posted on the internet.

So here begins guessing and cursing.

First the technical details about the Surface RT:

Manufactured by Microsoft so we dont have any documentation about hardware etc.

processor: Nvidia Tegra 3, Arm Cortex-A9 quadcore processor

ram: 2gb

display: 1366 x768

storage: 32/64GB (microSD expandable)

connectivity: usb, hdmi, i2c (only the now relevant ones)

Bios: its an EFI Bios which was build 24.01.2014 with secure boot enabled

Tegra 3 has mainline Linux kernel support, which is a good thing, so we don't need to write everything from scratch

2GB Ram should be enough for a light weigth Linux distro like Arch (older raspberry pi had <= 1GB RAM)

Secure Boot is the point where the trouble begins.

Microsoft required that Secure Boot is implemented in devices running Windows 8 and later, it ensures that every component loaded at boot is trustable because it is signed and validated. On top it can't be disabled on ARM devices

Let's look at the Boot process of the Surface RT (no Jailbreak):

1: bootloader

which is hardcoded in some flash storage and is loaded on power on (provided by nvidia).

This bootloader loads the "/efi/boot/bootarm.efi" file, if it is signed with the (hardcoded) secureboot-key, to RAM and passes control to it.

2: WindowsBootManager (/efi/boot/bootarm.efi):

loads "efi\microsoft\boot\bcd"*

It also loads other security polices, also supplemental policies*.

(3: By now the winload.efi would be loaded to start Windows 8 RT, which is totaly uninteresting for us)

*efi\microsoft\boot\bcd:

BCD -Boot Configuration Data- stores informations about bootloaders, which can boot operating systems.

*supplemental policies

https://web.archive.org/web/20170604013028/https://rol.im/securegoldenkeyboot/

The common Jailbreak installs such supplemental policy, which enables testsignmode!

Great! We can bypass a security feature created by Microsoft, with a backdoor created by Microsoft. (you played yourself)

Now we are able to boot *.efi files which are self-signed.

Theoreticallly the surface is now free, because Grub could boot whatsoever we want.

Let's look at the things we have already before we create new things:

Grub.zip

+efi
+---microsoft
+------boot
+---------fonts (obvious)
+---------bcd(2)
+---------(automatically generated files)
+---boot
+------bootarm.efi(1)
+unicode.pf2
+test.efi(3)
+grub.cfg
+BOOT.efi(?)

SecureBoot.zip

+SecureBootDebug.efi (4)
+SecureBootDebugPolicy.p7b (5)
+...

With microsofts signTool Ichecked the signature of the files

BOOT.efi: no signature found

bcd: no signature found

test.efi: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

bootarm.efi: Algorithm: sha256; Timestamp: RFC3161

It is obvious that bootarm.efi is signed, since it is there very first thing secureboot sees/loads

I was surprised that "bcd" wasn't signed, ?that seems to be common because everyfile which gets loaded gets checked, therefore bcd cant damage anything?

I examined the BCD(2) file with VisualBCD (windows program / aren't available anymore? couldn't find link, but screenshoted erverything back then will upload if I find them).

It contains an os loader which is named "lol hax" which refers to test.efi(3)

test.efi was signed, but isn't trusted anymore, but it still boots.

Best case: it boots because of testsign mode which only requires that a file is signed.

Worst case: is signed by microsoft but it boots because micosoft cant revoke the hardcoded secure boot key

My guess: test.efi acts as a boot shim (only has ~30kB). (shim is a microsoft signed loader which loads unsigned or selfsigned .efi files; common on x86 secureboot linux systems)

BOOT.efi is much larger with ~700kB so I guess this is the GrubImage which gets loaded by test.efi

i will confirm this with linux command "strings BOOT.efi", which should show grub specific strings

Therefore we can only change BOOT.efi or test.efi which must be self signed

Let's look at the Jailbreak boot process:

You copy the whole content of Grub.zip to an usb drive.

Insert it in the surface and let it boot from usb.

Hardcoded bootloader boots "bootarm.efi"(1: windows bootmanager)

Bootmanager loads BCD (2)

Bootmanager loads "Jailbreak" (4&5)

Bootmanager loads test.efi (3) (shim)

test.efi loads BOOT.efi

BOOT.efi ist grub and displays grub console

At the grub console we can enter some commands for easier debugging

pager=1: If set to ‘1’, pause output after each screenful and wait for keyboard input. The default is not to pause output.
debug=all: should be self explanatory

Now we try to boot Linux:

Linux boot process:

Grub loads kernel into RAM (the heart of Linux )

Grub loads devicetree into RAM (hardware description which linux uses to know what it can use)

Grub loads initramfs into RAM

Grub passes control to Linux

Nvidia has a developer tablet based on Tegra3, it is called cardhu

Find resources here

initramfs:

is optional, when all the software can be loaded from harddrive, but i think we should try ramFs first otherwise we must be sure that linux has usb support and can read the rootFs from usb

initramfs is a small rootfilesystem which contains the most important linux programs like the shell we want to interact later.

There are a lot rootFS available but i think busyBox has a good arm support, is small, ut has a shell and some other basic programs

Nvidia also provides a simple rootFs for Cardhu

devicetree:

devicetrees contain information about the Hardware like CPU, RAM, HDMI, USB, and so on

We should create a basic device based on Tegra Cardhuwhich has the most basic information about CPU, RAM, CLOCKS, INTERUPTS, USB, HDMI

I dont think its a good idea to start with the build in screen because we dont which driver we need for this specific display, but a hdmi driver should be available from nvidia cardhu pack

Since Surface has an efi Bios which supports acpi, we maybe could extract Hardware information from acpi tables and translate them to devicetree format or advise Linux to use acpi instead of devicetree, which would be easier if it works

to make Grub boot linux we need 4 more commands

linux <kernelFile>
devicetree <devicetreeFile>
initrd <initRamFs>
boot

after hitting boot grub tries to boot Linux boot did a weird thing:

...
jumping to Linux
jumping to MacOS

after that nothing happens for 15min and i shutdown the surface by holding the powerbutton for some seconds

Maybe Linux booted in the background but hasn't the right display driver.

Maybe it it crashes on a simple problem we cant see?

Normally Linux is debbuged by a serial connection, but till this day nobody has found a serial interface

Alternatively linux could be debugged by usb. Which would be great but also a problem

in usb debbuging mode the usb controller can't do anything else, but we need the usb controller to load linuxkernel, initramfs, devicetree

as well you need a usb 2.0 ehci debug adapter which isn't available anymore.

fortunately the guys at coreboot did a diy versiondiy usb debug dongle

i ordered 2 Cypress CY7C68013A and will try if we can debug windows to confirm that the usb port supports usb debugging

as well i orderd a second surface which cracked open. on the top of the main board I found an unsoldered connector which is labeled "J14", my guess is that this is a debugging connector which contains a serial connections.

My next step is to remove the top layer to get access to the copper and activate serial debbuging in windows in order to find a serial port which hopefully could be accessed by linux to give us some debugging output

I think we should start with:

-maybe open a own thread where i collect everything / or setup an free website

-in the next weeks i will create tutorials about downgradeing and jailbreaking and document it to confirm all the old things still work

-I will upload bcd / grub "lsefitab" screenshots

-getting a debugging access (preferred: serial; or usb) (in progress)

-compiling a newer Grub version, because there were massive improvements for ARM32 (tried but failed; maybe good advise)

-extracting acpi information from the efi Bios, because in the acpi tables there should be a hardware description (need to write efi application which get loaded by test.efi and displays everything)

-build a devicetree for Linux (important to get the basics right)

-compile a generic Linux kernel for arm with Tegra3 support

p.s. iam trying to compiling Grub again because i realized quite some things as i wrote down all the things i know today

PLS:

-post your progress, even if it looks negligible

-CONTACT ME:

Via this thread​

XDA private message​

I would be happy to exchange knowledge via discord or some other platform​