Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Prepare USB: format it as FAT32 and copy your files
Insert USB into your Surface
Hold Vol-Down
Press PWR
Wait until the Surface logo shows and wait some more seconds
Release Vol-Down
To boot unsigned non Microsoft UEFI Apps you need to apply Yahallo first
Connect your Tegra3/4 via an USB A-to-A cable to an USB 3.0 Port of your PC
Hold Vol-Up
Press PWR
Release Vol-Up
it should immediately boot into APX mode
Use your payload sender to send data (Fusée Gelée)
Newer PCs can use an USB Type C cable instead of USB A-to-A cable
This section deals with different Boot processes on Surface RT/2
Boot process can be divided in 2 different sections.
First comes the SoC boot process. This prepares the SoC to execute more capable firmware/bootloaders which will eventually load a Operating System.
Once the UEFI Firmware is loaded it needs to decide which files should be booted next.
Boot process of Tegra SoC's from PowerOn to Bootrom to Bootloader
Every Tegra SoC contains a small built in ROM. Tegra3 has one which is 48kB in size. This ROM is called BootRom.
The Bootrom is responsible for initial SoC setup. The code stored in bootrom will execute on the Boot and Power Management Processor (BPMP) which is a ARM7TDMI(ARMv4T) CPU. Until DRAM is setup it can only use iRam which is only 64kB in size. After DRAM setup it will load a Bootloader to DRAM and transfers control to it.
Checks fuse or strap to decide which boot device should be used.
Try to read a valid signed BCT
Set up DRAM according to BCT
Load a hashed Bootloader specified in BCT and execute it
If no valid Bootloader is found it enters USB recovery mode (RCM/APX)
From there its the firmware job to setup the main CPU (ARMv7-Cortex-A9) and transfer control to the main CPU. This part of the firmware/bootloader is called Secondary ProgramLoader (SPL).
On a stock Surface RT/2 this bootloader is UEFI TianoCore EDK2 which provides the UEFI API.
USB recovery mode can be exploited. See Fusée Gelée
http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
APX Mode (NVIDIA USB Recovery Mode) can be used to run Fusee Gelee or to use Nvidia tools to flash the hardware. https://forum.xda-developers.com/showpost.php?p=77286176&postcount=85
Note - you will need a USB3 port on your development computer.
Power off the SurfaceRT or RT2 (not sleep mode!)
When the device is shut off, plug in a USB type A into the Surface, and a USB type A (or type C depending on your development device) into your development computer.
Hold VOL-UP; Press PWR and release it. Release VOL-UP if dmesg -Tw
shows:
Once connected in APX mode, you can use NVidia tools or a precompiled Fusee Gelee on your device. Nvflash v2.6 - https://docs.toradex.com/103464-nvfl...ry-toolset.zip NvFlash tool for getting uid - https://web.archive.org/web/20160318...ools-win32.zip
Connect USB - A-to-A cable Write 0x00000002 to 0x7000E450 <- sets bit in PMC-register to indicate to boot to RCM Write 0x00000010 to 0x7000E400 <- reboot This should force reset in RCM Mode
Boot UEFI Shell as normal. use this startup.nsh
Fusee Gelee (translates to Frozen Rocket) is a coldboot launcher. The exploit takes advantage of a USB software stack that is provided inside the BootROM. This stack contains a copy operation that allows for control from attackers. By creating your own USB control request, attacks can use this vulnerability to gain control of the Boot and Power Management Processor (BPMP).
This allows attackers to gain control of the system before any of privilege restrictions are put in place, essentially giving full access to the device. Allowing for the loading of arbitrary code and extraction of secrets.
This vulnerability is completely unpatchable, so the only way to fix this vulnerability is to recall and replace existing SKUs. It affects most of the Tegra devices that were produced before the exploit was published. This includes Surface RT and Surface RT2 and other Tegra3/4 devices.
To use this exploit you need
A payload - a binary file which gets executed
A payload sender - a program which transfers the payload to the device memory.
pyusb
There is a precompiled payload for the Nexus 7 2012 that we can repurpose for the Surface RT (Tegra 3).
The payload provided in this repository has been tested many times, but proceed at your own risk.
You will need to clone this repository into a new directory, including the submodule here:
Once the payload and exploit are downloaded, here are the steps all the way up to flashing an unsigned bootloader:
Connect a USB-A to USB-A cable from your Surface RT to a USB 3.0 port on your host machine.
Boot into APX mode.
Press and hold Volume Up & Power for about 3 seconds
Release the Power button
Release the Volume Up button
lsusb should show a Nvidia device with id 0955:7130
cd
into the tegra30_debrick
directory
Run the commandsudo ./fusee-launcher/fusee-launcher.py ./payload/uart_payload_n7.bin -V 0955 -P 7130
This will send the uart_payload to the Surface RT, and patch the getSecurityMode function to always return 3, allowing us to use nvflash.
Run the commandsudo ./utils/nvflash_v1.13.87205 --getbct --bct surfacert.bin --configfile ./utils/flash.cfg
This will read the surfacert bct, which is a required input for many nvflash commands.
Finally, we can run arbitrary code using the following command:
sudo ./utils/nvflash_v1.13.87205_miniloader_patched --setbct --bct surfacert.bin --configfile ./utils/flash.cfg --bl u-boot.bin --go
Further tweaking is needed to get a functioning bootloader, with the above steps, and the compiled nvidia fork of u-boot located here (Driver Packages - Cardhu), the webcam light turns on.
Once the L4T R16 u-boot.bin is flashed, you will then need to press and hold the Power button for around 10 seconds to fully power off the tablet. Then you can repeat the above steps to re-attempt flashing.
To get your platform key use this command in the tegra30-debrick directory.sudo ./fusee-launcher/fusee-launcher.py –-tty ./fusee-launcher/dump-sbk-via-usb.bin
Add the -P parameter at the end to specify the product_id if "No TegraRCM device found" is the output. For the Surface RT 1 this is 7130.
This will output a lot of things. Look for the line with hello world, after that line something like this b'e57de3bab6cb499d874d5772cb219f0101042c20'
should show up. Remove the b, the two ' and the last 8 remaining characters. This is your platform key. It is used to encrypt and decrypt the BCT and the firststage bootloader
UEFI can be set to require a trusted chain from boot to execution of OS - aka a Root of Trust. On the Surface RT/2, UEFI is setup to require a trusted chain "secure boot".
This was the main issue for development of other OS's on the Surface RT/2 hardware.
Secure Boot means that we are unable to replace the "bootarm.efi" bootloader with our own bootloader like GRUB as it needs to be signed by Microsoft.
Microsoft is unwilling or unable to provide the key to "unlock" the Surface RT/2 hardware, so we are "stuck" with using their bootloader. There are two possible options to bypass this - Yahallo and Test Certificate bypass.
A "golden key" bypass which allows us to insert a trusted test certificate into the UEFI Bios allows us to use a signed shim to boot into our own EFI loader (instead of booting into Windows). We still load Microsoft's signed bootarm.efi, which then loads a shim, to load Grub/EFI shell, which can then finally load a Kernel.
Further info on this bootmanager exploit bypass is here
A new, easier method for enabling test signing was discovered. It involves the same techniques, but you only need to boot from a USB twice, you don't even need a windows installed. (An EFI partition could be required, this needs to be verified)
Grab the ZIP file from here, extract it to your USB, and boot your Surface device from it. A menu should show up where you have several options (Install Golden Keys, Uninstall Golden Keys, Apply Yahallo, Undo Yahallo). Select "Install Golden Keys" to enable test signing (You have to use a USB keyboard to select an entry). Your device should reboot and you need to accept a warning.
With this you can also easily disable secure boot with the help of yahallo. Just make sure test signing is enabled and you can select "Apply Yahallo" in the menu to disable secure boot.
You can get further explanation of the tool / USB setup in the development section.
Note: This only works when you downgraded to Windows RT 8.0 you can brick your device if you use Windows RT 8.1.
Down in this section there is a download for the "golden key" you need to install it, by running InstallPolicy.cmd as admininistrator on your SurfaceRT. It is important that you don't run the file off a USB drive, copy it to your desktop. After running the file you need to reboot, a menu should open which should enable you to enable testsigning. Accept it. After the reboot open up a cmd, again with administrator privilegs and run the following command:
Reboot again, now testsigning should be enabled.
To use the test signing to boot from USB you need to extract the files from the usb-boot-setup.zip to the root of a FAT32 formated USB-drive. This setup doesn't include any bootable files, to add one place it into the root directory and name it BOOT.efi. Further reading on how the bootflow works at UEFI Boot Sequence.
Root of Trust combination with keys and certificates. Using SecureBoot your firmware will check if the operating system you are trying to boot and your bootloader are trusted by you. On each boot-up UEFI firmware will inspect what you are trying to boot and if it's not trusted a security violation will be triggered.
PK: The Platform Key, the master one, the ring to rule them all. The holder of a PK can install a new PK and update the KEK.
KEK: Key Exchange Key is a secondary key used to sign EFI executables directly or a key used to sign the db and dbx databases.
db: The signature databse is a list with all allowed signing certificates or criptografy hashes to allowed binaries. We will use THIS db key to sign our Linux Kernel.
dbx: The dark side of the db. Inverse db. "not-good-db". You name it. It's the list containing all keys that are not allowed.
https://news.knowledia.com/US/en/articles/secure-your-boot-process-uefi-secureboot-efistub-luks2-lvm-2fe5ab6e432ac7b6d0bb773cebe0363c41bef83c https://wiki.ubuntu.com/UEFI/SecureBoot/Signing https://bentley.link/secureboot/ https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd https://lwn.net/Articles/632528/ [The bootstrap process on EFI systems] https://community.arm.com/developer/ip-products/system/f/embedded-forum/7016/uefi-on-arm-v8-based-linux-embedded-system https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html http://weng-blog.com/2017/07/21/ARMv8-UEFI-manual-boot.html
https://ubuntu.com/blog/how-to-sign-things-for-secure-boot https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
Refer to The exploit in the dev section to get further information about it.
The Exploit starts in App.c. App.c transfers controll to DeviceLut.c It will compare the UEFI version to some entrys in a lookupTable In case of sRT it will apply a display fix first. DeviceLut.c transfers control to Exploit.c
We suggest to only apply this if you need it. In most cases it is not necessary. At the moment you gain no advantage.
https://github.com/NekomimiRouter/yahallo
You can easily disable secure boot by booting the All-in-one Secureboot tool. Just download the ZIP, extract it to your USB and boot it. Select the options with an USB keyboard. For further information how to setup the USB go to the more detailed explanation bellow.
More details can be found in the Secure Boot page and in the All-in-one Secureboot tool page.
Prerequisites to start with the process!
Working USB drive formatted as FAT32
Surface RT/2 with 50% or more battery, can be plugged in
Yahallo files to boot from
Windows Boot Manager exploit, this one is important!!!
Prepare the USB drive and format as FAT32, doesn't matter if it's MBR or GPT. In my case I name the drives after their capacity.
Extracting the files, make sure the folder contents are on your USB drive's root directory (example: E:\ [stuff is here])
Once the files are copied over, unplug the drive from your PC and power off your Surface. Once powered off plug in the USB drive and boot from it by pressing power and holding volume down at the same time.
That's it! Exploit has been done and all you have to do is power off your tablet and turn back on. From my case at first it refused to display anything so I suggest leaving it for 5 minutes at most. Since SecureBoot is now disabled you can boot unsigned code like Linux, which is work in progress.
To re-enable secureboot replace the "Yahallo.efi" file on your USB with the file bellow, make sure the naming is correct.
Enabling secure boot brings you no advantage at all, you only restirct yourself with what you can do.
Boot process of Tegra SoC's from Firmware to Operating System
UEFI Firmware is loaded by the BootRom which loads the UEFI Firmware.
UEFI Firmware will setup hardware like Display, USB, etc.
After hardware setup it will transfer control to /efi/boot/bootarm.efi
bootarm.efi has to be signed with the Microsoft SecureBootKey (SBK)
https://forum.xda-developers.com/showpost.php?p=82555449&postcount=126
coherixmatts - "This has been helpful to me, as I was able to quickly test changes to the BCD file. Changing the BCD file allowed me to replace test.efi with bootshim.efi from here: http://github.com/imbushuo/boot-shim/releases
Instead of loading EFI files like test.efi, this alternative loads ELF files. That isn't necessarily so exciting, but this BootShim also unloads elements of the original SecureBoot restricted UEFI. They are using this on Lumia devices (particularly the 950XL) to load a modified version of UEFI. After that, it seems they can boot most anything." This thread also seems interesting for reference https://github.com/rhboot/shim/issues/138
In the Surface RT UEFI there is a bug which prevents the display from working. This is because the standard GOP (Graphical Ouput Protocol) isn't hooked up to the Surface RT's display. This was fixed in the Surface RT 2.
The CPU will load the boot setup, and then load up UEFI "bios". UEFI will then load /efi/boot/bootarm.efi (which needs to be signed with a secureboot-key) into ram and pass it control to then load other stuff in turn. We haven't been able to sign our own stuff yet ( if we could then we could just install uboot and bypass all the pain!). So.. we use Microsoft's, aka WindowsBootManager (/efi/boot/bootarm.efi) to eventually load our boot tool (i.e. grub2)
Microsoft's bootarm.efi checks for
efi/microsoft/boot/bcd (boot configuration data)
(which then loads our special "jailbreak" policy), then loads a test.efi shim, which finally loads a secondary EFI file - i.e. GRUB2 or uefi shell placed in the root.
The special FAT32 requirment of this device.
For a long time it has been thought that only some USB drives work on these devices. Now the issue is known: FAT32 isn't FAT32.
Windows's FAT32 is actually W95 FAT32 (LBA). But Linux creates proper FAT32. So a USB drive that is formatted with Linux won't work for these devices, because the UEFI firmware doesn't support proper FAT32.
Here is a comparison from the two possible partitions (Program used is Gnome Disks):
Type, (here german "Inhalt") doesn't matter. The parition type is meaningful.
Here is are steps to achive this with diskpart:
In the Start menu, type cmd
, and then click the entry for the cmd program.
At the command prompt, enter diskpart
(you have to approve this operation as an administrator). The prompt line should now display "DISKPART".
Enter list disk
. lists your drives.
Enter select disk X
, where X is the number of your selected disk.
(MAKE SURE TO SELECT THE CORRECT ONE!!!).
Enter clean
. wipes the selected drive partition table.
Enter create partition primary
. creates a partition and marks it as primary.
Enter select partition 1
. selects the partition number 1 (primary).
Enter active
. sets it as active (makes it bootable).
Enter format fs=fat32 quick
. formats the drive as FAT32 partition table (quick at the end indicates quick format).
Enter assign
. assigns the drive to a mount point.
Enter exit
.
Open a terminal and run this command to locate the right device:
Use fdisk
command accordingly:
sudo fdisk /dev/sdX
; X
stands for the right disk letter something in the region of b
, c
or d
Type o to change the partition table type to dos
When the command runs type d and enter to delete the existing partition, then
Type n to create new partition
Accept the defaults when ask for the partition type
and size
(assuming that is desirable),
Type p to see what you have done,
Type t to change the file system type,
Type c to create a W95 FAT32 (LBA)
partition,
Repeat step 2.5
, i.e. 5
above to see the created partition,
Type a to activate that partition so it automounts,
Type w to write the changes to disk
Format the again from the terminal:
Note: i
represents the partition number in this case it should be 1
Eject and replug the device
According to a device will initially start up and look for a particular file based on the architecture of the system: As we need to bypass the standard boot, we use the jailbreak to hack the process using a supplemental policy, which enables testsignmode.
/boot.efi Hardcoded bootloader boots "bootarm.efi"(1: windows bootmanager) Bootmanager loads BCD (2) Bootmanager loads SecureBootDebug.efi, and the SecureBootDebugPolicy.p7b Then loads a test.efi (lolhax? shim) [this can be changed to our own shim, eg ] Which finally loads our boot.efi
More detail here -
(although we use GRUB2, the boot process is quite similar, and this is worth a read!)
Source:
work in progress.
Looks like UARTA is using the ULPI pins as noted here (https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-tegra/tegra30/pinmux.c#L238) So we know we can setup our UARTA and UARTD on the ULPI pins
#if defined UARTA
/* set pinmux for uart-a (nexus 7) */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DATA0_0, 0b00000110); /* tx */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DATA1_0, 0b00100110); /* rx */
#elif defined UARTD
/* set pinmux for uart-d (ouya */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_CLK_0, 0b00000110); /* tx */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DIR_0, 0b00100110); /* rx */
#endif