1 of 34

!!! PLEASE READ !!!

This is the development section. The stuff you find below is barely tested. Some of it might be even untested. USE FILES/INFORMATION FROM HERE AT YOUR OWN RISK!!!

!TODO for everyone

Small introduction to the Bootprocess
upload ACPI tables sRT2
move BCT table & BCT table to boot process?
rewrite boot process
explain difference between APX and UEFI boot
Add writeup about Trustzone Takeover

ASAP

~~All-in-one Secureboot tool should move to boot section~~
Write a new, better and cleaner install guide for Windows RT, 10 and Linux

CTS devNotes

Development notes of CrackTheSurface

!TODO

Surface RT

Surface 2

Fix USB
Fix SD card
Audio input

battery

TZ Exploit - CTS

Read EL from APX
Read EL from UEFI
Create Payload

Idea

Write code into TZ mem and jump to it. Hopefully it will execute at EL3.

Tests

Read NS-Bit

page 1697: can only be read from securemode.

Read EL

page: 1139

Read EL from APX

a custom payload will be used to read the Exception Level from in APX mode. I expect it to be 3.

Supervisor mode is the default mode to which a Supervisor Call exception is taken.

Read EL from UEFI

A normal efi App will be used to read the Execption Level from UEFI. I expect it to be 0.

FIQ mode is the default mode to which an FIQ interrupt is taken.

Creating a payload

We need a relocateable payload since UEFI can give us different load addresses everytime.

Therefore we need to use Position independent code:

Step by Step

Step 1:

Create payload which reads EL and reports back via serial. Read payload from USB/eMMC to memory. Disable TZ protection. copy payload into TZ mem. override TZ with jumps to payload address. If payload reads EL3 continue.

Step 2:

to be continued...

tCover Linux support

I2C0 @ 0x00 Address 0x00 is general call address which makes Cover incompatible with standard I2C drivers.

WDSA Table

Name(ABUF, ResourceTemplate()
{
    I2CSerialBus(0, ControllerInitiated, 0x61a80, AddressingMode7Bit, "\\_SB.I2C1", 0, ResourceConsumer, , )
    GpioInt(Level, ActiveLow, Shared, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , ) {0x59}
})
Name(EBUF, ResourceTemplate()
{
    I2CSerialBus(0, ControllerInitiated, 0x61a80, AddressingMode7Bit, "\\_SB.I2C1", 0, ResourceConsumer, , )
    GpioInt(Level, ActiveLow, SharedAndWake, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , ) {0x75}
})

Address 0x00; Speed 400kHz

GPIO Interrupts: 0x59 -> L1 0x75 -> O5

From 5.1.1 HID Descriptor Format

All important information is set to 0x00. I guess standard I2C HID Driver will have a hard time.

HID Descriptor Address is 0x41. This makes all the Register fields seem legit.

Whats wrong here?

It was tested without tCover. Connecting a tCover doesn't change anything.

This should be related to wrong power settings.

Surface RT2 turns on backlight on TypeCover2 when the kernel is booted from UEFI with ACPI.

ACPI does something right according to power settings. Now we need to capture the new HID Descriptor for UEFI boot on Surface RT. Results should show what to do next

Observation

Booting Windows without tCover: Windows doesn't send a single byte to tCover. Booting Windows with tCover: Windows does send some non HID bytes before the HID Descriptor is read.

That leads to the conclusion that the SoC has a GPIO which acts as tCover detector.

Kernel module

Maybe we have to write a kenel module which will init the tCover IC and hand off controll to I2C-HID Driver

Dump Bootrom

Idea

https://media.ccc.de/v/c4.openchaos.2018.06.glitching-the-switch dumping boot rom seems easy. only need to set the right access bits. which we can do since we have total control over the CPU/memory. Reverse engineering is the hard part. 48kB arm assembler. And only some bits decide from which device is booted from. But we have a good starting point. The provided example patches a function which prevents the bootrom to read the BCT. We need to patch some bits before this instruction is executed. and since reading the BCT is the first thing the bootrom does we should start looking at the begining of the function call chain. only need to figure out to which value we must set the byte. but this should also be easy. the bootdevice is read form a fuse. Nvidia provides a script to burn fuses. this should tell us which fuse is used for bootdevice selection and we should be able to find this address in the bootrom. it should also tell us which value the fusee needs to be to boot from mmc/sd/usb/... the theory part is "done". Need to dump the bootrom and throw the binary into ghidra. find the function which reads the boot device fuse and write an ipatch to patch the bootrom. like disableing security fuse. i hope this allows us to boot selfmade BCTs from other storage devices. luckily we dont have to do some voltage glitching. we could just set the bits to read the bootrom

Preparation

Secureboot registers

Secureboot registers should be located at 6000:c2000

fusee gelee payload

git for dummys [WIP!] (like me)

Clone the repo with SSH

git clone git@github.com:Open-Surface-RT/grate-linux.git

Add upstream

git remote add upstream https://github.com/grate-driver/linux.git

update to upstream

edit local commits

solve merge conflicts

log stat

git log --stat

Leander devNotes

!TODO

UEFI Privilege Escalation Exploit Documentation

Yahallo: Free memory access

The Yahallo exploit uses a security vulnerability in the NVIDIA Tegra 3 / Tegra 4 UEFI firmware to disable the SMMU memory protection. As a result you can access all memory.

Disclaimer Most information only applies to SurfaceRT, but some yahallo information applies to Surface RT 2 too.

The exploit

Background story

Because NVIDIA/Microsoft didn't implement a check for maximum buffer size when using a SMC instruction to register a new shared buffer, it is possible to create a buffer overflow, which is then used to overwrite the area where a BootServices->SetMem UEFI call writes its memory.

Understand the formular

This is from the . It gives a brief overview about the parameters, but here is more detail about them:

First, you need to know which values are used from the SMC in the calculation, we don't care about parameters 1 and 2. Parameter 3 is request_area, so in yahallo source 0x40000000. Parameter 4 is area_slice, so in yahallo source 0x6001e0e0.

Calculation of the addresses

The calculation has the following formular: response_area = (request_area + (area_slice >> 1)) Examples: 0x7000_f070 = (0x4000_0000 + (0x6001_e0e0 >> 1) 0x7000_f010 = (0x4000_0000 + (0x6001_e020 >> 1))

Use the exploit to disable the SMMU

Tegra 3 SOC: Important information

The Tegra 3 Technical Reference Manual (TRM) has important information about virtual addressing and configuration registers in section 18. You can download it , but downloading requires a NVIDIA developer account.

The SMMU (System Memory Managment Unit) is part of the SOC, and not part of the Cortex-A9 cores. The CPU cores have a MMU too, you can simply disable it with a ArmDisableMmu() call in the edk2 source tree. Yahallo reconfigures the SMMU, so all SMMU memory protection is gone. The CPU MMU still protects this memory, but you can easily disable it.

Disable SMMU

To disable the SMMU, you need to write 0's to the SMMU Enable Register (0x7000f010). This can only be done when you are in secure mode, so it doesn't work if you just disable the CPU MMU. With the help of the Yahallo exploit we can write to all memory locations in secure mode, because the BootServices->SetMem call executes in secure mode. (UEFI firmware operates in secure mode generally)

What Yahallo does

Yahallo writes 32 bytes of 0's to 0x7000f070, so it writes the Secure Region Configuration Base register, Secure Region Configuration Bound register and the Protected Region Configuration Bound register.

This makes the Trustzone 0MB in size (SMMU side), so you have access to non-trustzone-secured* memory, when CPU doesn't restrict memory access. The CPU restrictions can be removed by disabling the MMU.

* Some registers are restricted to be only accessible from Trustzone-secured CPU memory access. (e.g. from the SMMU_ENABLE register from TRM: This register can only be accessed by Trustzone-Secured accesses from the CPU.)

UEFI Privilege Escalation: Execute code in Secure mode

Replace the Secure Monitor to execute user-defined code in Secure mode by using a Secure Monitor Call (SMC)

The idea

Using the Yahallo exploit we can get access to Trustzone memory. In the Trustzone you can find all of the firmware's functionality, where some code executes in Secure mode. On top of that, some of the memory is marked as secure, so you can execute it from Secure mode.

The goal is to get rid of Trustzone memory, so the page tables of the Trustzone memory need to be modified. To do this you need to be in the Secure mode.

But how do you get into Secure mode?

UEFI firmware provides runtime services to the running operating system. The communication happens with ACPI or other protocols. But also with interrupts, specifically the Secure Monitor Call (SMC). A user can trigger a SMC by executing the smc instruction. See the for more information on how such a call happens.

When executing a SMC, the processor receives the interrupt and looks in the Monitor Vector Table at the Monitor Vector Base (specified in the Monitor Vector Base Address Register (MVBAR)) for the address of the Secure Monitor and jumps to it. The Secure Monitor is then responsible for reading the variables from the SMC and running the desired function in Secure mode*. Essentially SMCs are used for communicating with the Secure world and the Trustzone kernel.

When you further think about it, you may notice that we could simply replace the Secure Monitor and put our own code there, by using the Yahallo exploit.

* The Secure Monitor executes in Monitor mode. Monitor mode ignores the SCR.NS bit and always executes in secure mode. You can use this to modify configurations which are specific to each execution state.

Finding MVBAR

To replace the Secure Monitor, you first need to locate it. The Monitor Vector Base Address Register points to the Monitor Vector Table, where the third table entry points to the Secure Monitor

Reading MVBAR

So just read the MVBAR, right?

But what are the Secure PL1 modes?

So they are only accessible from Secure state. A normal UEFI App executes at PL1 in non-Secure mode.

So reading the register at runtime won't work. But there are other options to get the address.

Reverse-engineering the firmware binary

You can get your UEFI firmware binary from C:\Windows\Firmware\SurfaceRTUEFI.bin.

For reverse engineering we have used Ghidra. For importing make sure to use ARM:LE:32:V7:default as language.

mcr p15,0x0,r0,cr12,cr0,0x1 is the instruction which sets MVBAR. Search for it. You should only find one result. The disassembly looks something like this:

When further analyzing this, you will quickly notice that you will not be able to find out MVBAR by just analyzing the UEFI binary. Maybe it's possible, but only with heavy reverse-engineering.

As you might have thought, there is an easier way to get the value of MVBAR.

Analyzing a memory dump

Dump memory

To analyze a memory dump you need to create one first. Our also compiles into a memory dump tool, modify if you need to change the memory address.

Analyzing and importing the dump

Import the dump to Ghidra. Use the setting from above, but make sure to go to options and set the Base Address to 80000000. This is where the memory dump started from. After this change continue the import as usual.

But what now? You have Megabytes of memory, and you need to pick an exact point out of it.

Of course we read the handful of existing and useful blog posts that are on the internet. Including this one:

It shows how a Monitor Vector Table looks like, when disassembled:

So only search for some branch instructions, right?

Not really. There are a lot of jump tables in the memory dump. After hours upon hours of starring at Ghidra and the internet, I managed to find the right one.

I searched for multiple branch instructions next to each other using this command xxd "trustzone.bin" | grep -E '(.{3}00 00ea){4}' (CTS helped me with that command)

I just went through the results and found a jump table at 0x811f8000.

At that point I already had an EFI app which loads a payload into memory, copies it to a desired location in the Trustzone and then fills some memory with an instruction to load the payload location into a register and an instruction to branch to this register. The payload was capable of printing something to UART. I have also tried other jump tables at that time, with no success.

But this time it was different: The payload started executing.

So it was clear: MVBAR is 0x811f8000

The Trustzone payload

Where to put the payload in memory

Right now the payload is placed at 0x8011219c. When analyzing a memory dump you will notice that this is right after an instruction is executed which sets SCR.NS. In theory you will not need to place the payload exactly there. You could also place it before the SCR.NS set, you will always execute in secure mode, as described above. In theory you could also just replace a single Secure Monitor "Function" (When you pass paramteres to a SMC you specify what to do in the Secure Monitor).

TODO: Add picture of Ghidra with the memory location

Compiling a relocateable payload

You can find a fully working payload example on . It includes the Makefile, a linker script, an assembly file and a C source file.

Our payload is position independet, this means it can execute from anywhere in memory. It's really easy to make GCC compile position independet: Just add -fpic to the CFlags. (Yes, the payload is written in C, other languages such as C++ or Rust may be useable too).

Using Assembler language

When configuring a large amout of registers, using a seperate .S/.asm file is more convinient than using inline assembly.

But there is something worth knowing: You need to make sure that your assembly is relocatable, otherwise the code will break. In C the compiler makes the code reloactable, but the assembler can't make the assembly relocateable for you.

Here is a short example of an assembly file which loads the address of mybuffer into r0:

What to explain:

How the payload works and how it is executed and why exactly the strange memory location
verifying that payload executes in Secure mode
explain monitor mode a bit more (maybe)

Additional resources

(Including Monitor Vector Table)
(Figure 3.3)

Removing trustzone

We tried to get rid of the trustzone with help from yahallo exploit

Details of the CPU

The Surface RT's Tegra 3 SOC's CPU uses Cortex-A9 cores. These cores use Virtual Memory System Architecture (VMSA), this means we have a Memory Management Unit (MMU).

ARM Architecture Reference Manual ARMv7 A & R edition

This manual describes the ARMv7 A & R architecture (ARMv7 A is important for us) in Application Level Architecture and in System Level Architecture. The System Level Architecture is the interesting part for this type of development. Part B, System Level Architecture, only has 874 pages to read 🥳.

Download the manual here:

Why modify page tables?

The MMU is also used for virtual addressing, not only for protected memory. Virtual addressing is necessary for most applications and operating systems. Linux works without it, but most programs don't work without virtual addressing. Because of that we need to enable the MMU for linux, but when MMU is enabled, it blocks access to trustzone memory, so the trustzone memory needs to be unmapped by modifying the page tables of the Cortex-A9 cores.

Advantage

The advantage of completely eliminating UEFI and TrustZone is, that we don't need to modify the linux source code, only a device tree is needed, which can be mainlined. Without getting this way to work, our linux work probably won't be mainlined ever.

EFI linux booting

Booting linux with UEFI boot is now possible.

Issues

PMIC regulators don't work.
Audio, Wireless, Cameras, Sensors .This is also true for APX boot.

TODO

Implement ACPI for arm32. This will help in development for all other devices that run Windows RT too. Why? It removes the need for a device tree and enables us to comunicate with the firmware, which will hopefully enable us to use PMIC stuff. Also we can upstream our ACPI Parking Protocol driver, which is needed for SMP.
Get Audio, Wireless, Cameras, Sensors.
Possibly more, but we don't know about it yet.

Configs we already tried

This is a place were we put configurations we tried, and didn't work or did work up to a certain point.

Surface RT 1

@Leander's trial and fail

Qemu emulation

Run arm32 UEFI in a virtual machine.

Emulating a arm32 UEFI device is useful for developing Linux and debugging it.

In the GDB Debugging page you can find instructions on how to compile Linux for this virtual machine.

A premade ZIP with all required files can be found at the bottom.

Compile OVMF for qemu

Install required packages

Run the following commands to install the required packages.

You will need other stuff too, but that is probably already installed. (e.g. git)

Download source

You need the source code of edk2 and acpica.

Compile OVMF

Go to your source directory and run the following commands.

Your output OVMF firmware file for qemu is$WORKSPACE/Build/ArmVirtQemu-ARM/RELEASEGCC5/FV/QEMU_EFI.fd

Setup qemu files and run it

Create a directory, where you want your files to be in. Put your QEMU_EFI.fd firmware file in this directory, compiled in the previous section. Now run the following commands to create some disk images:

Now create a directory named boot. This will be your EFI partition. You can now easily place your EFI files in there.

Run qemu

To start your virtual machine run the following command, and make sure qemu-system-arm is installed.

This will run qemu with 4 virtual CPU cores. They are Coretx-A15 cores. Used because it works.

Premade files

The following ZIP includes all files setup in their proper location. In addition its EFI partition folder has a UEFI shell in it. To run it either execute the run.sh file or enter the command described in .

References

Links where the above compiling information is from:

GDB Debugging

Debug Linux kernel with GDB

Compile a correct Linux kernel

Clone a Linux tree and run make ARCH=arm defconfig to make a generic kernel configuration suited for qemu. Now edit the kernel configuration (.config) and add the following lines at the bottom:

CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y

Now run make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) to compile the kernel. If you get asked about anything, just press enter to use the standard value.

Copy the output zImage (arch/arm/boot/zImage) to efi/boot/bootarm.efi on your EFI partition folder in your qemu directory.

Prepare GDB for debugging

Install

Run sudo apt-get install gdb-multiarch to install GDB on Ubuntu. gdb-mutliarch is required because normal gdb package doesn't have support for ARM.

Run

Open up the terminal you want GDB to run in, and change directory to your Linux compilation directory. Then run gdb-multiarch vmlinux., it will open GDB you and you can now connect to a target with target remote localhost:1234. At this point GDB will wait for qemu to start. After that you can now debug with qemu, there are tutorials online to show you how to do this.

Run qemu

Go to the directory where your qemu files are located, start qemu as described in , only change is that you need to add a -s parameter, this lets qemu know that it starts a GDB server.

VSCode integration

Debug Linux kernel within Visual Studio Code

Create configuration files

The following steps have to be performed in your Linux source directory.

Create tasks.json

Create a file called tasks.json in the directory .vscode and paste the following contents into it:

You may want to change line 26 and 34, as they point to the directory where your qemu files are located.

See for the documentation about the tasks.json format

Create launch.json

Create a file called launch.json in the directory .vscode and paste the following contents into it: Use IntelliSense to learn about possible attributes. Hover to view descriptions of existing attributes. For more information, visit:

Create c_cpp_properties.json

Create a file called c_cpp_properties.json in the directory .vscode and paste the following contents into it:

Debug

Press F5 to start debugging. The following steps will be performed:

Compile Kernel
Copy zImage to qemu EFI partition
Launch qemu

The following keys are important:

F9 for creating a breakpoint
F10 for going a step forward
F11 for stepping into a function

EFI Signing / Secure Boot

Windows bootmanager exploit is deprecated, as you can now disable secure boot. Without secure boot you don't need to sign your EFI binaries. Visit Yahallo for more information.

SurfaceRT/2 uses UEFI Secure Boot.

We have a test key that can be used to sign our EFI binaries so that they are trusted by the windows boot manager. (When secure boot is enabled).

Working Test Key

5D7630097BE5BDB731FC40CD4998B69914D82EAD CN=Windows OEM Test Cert 2017 (TEST ONLY), O=Microsoft Partner, OU=Windows, L=Redmond, S=Washington, C=US

can use signtool on windows to sign our EFI builds eg

signtool.exe sign /tr http://timestamp.digicert.com /td sha1 /fd sha1 /sm /sha1 5d7630097be5bdb731fc40cd4998b69914d82ead *.efi

GRUB2 Booting Notes

Booting Linux with grub is now possible. (But UEFI shell is normally used)

Starting from Linux Kernel 5.0, it is now possible to enable FrameBuffer. This can be configured in grub with

grub_cfg

set grub_mm_debug=1
insmod efi_gop
insmod efi_uga
earlycon=efifb,mem

More here -

EFISTUB (Kernel booting)

The information bellow is outdated. Visit for information on how to compile & boot a working linux kernel.

As we are "stuck" inside Microsofts bootarm.efi -> ContextSwitcher -> grub.

Cross Compiling

SurfaceRT or RT2 is ARMv7 (ARM32 / armhf ) Cross compiling is fairly simple when using docker, but you can do it it without.

Cross compiler quick setup (platform agnostic mac/linux/windows)

Linux: apt install docker Mac: brew install docker; brew cask install docker; Windows (install docker-ce from docker.com?) docker run --rm dockcross/linux-armv7:latest > dockcross-linux-armv7-latest chmod +x dockcross-linux-armv7-latest To use:

./dockcross-linux-armv7 bash -c make

Alternate option (linux debian based - amend for other package managers as needed)

#install req's for cross compiling apt install gcc-arm-linux-gnueabihf bison autoconf autopoint flex build-essential #install random libraries that grub2 seemed to need apt install liblzma5 libarchive-dev freetype2-demos libfreetype-dev fonts-dejavu grub-theme-starfield ttf-dejavu-core libdevmapper-dev libfuse-dev ttf-unifont unifont liblzma-dev #install EDK2 bits apt install acpica-tools uuid-dev nasm python-distutils #install u-boot bits apt install swig libpython3-dev

Devicetree information

ARM kernel maintainers decided that the best way to configure SoC hardware, would be to create a separate description of a particular SoC into something called a device tree file, in order to keep it out of the kernel.

In Linux there is a concept of "device trees", which is quite separate from the "/dev" structure & udev. It's available in PC land, although it isn't strictly necessary necessary because of the BIOS. Cursory googling suggests that the device tree is used in EFI (or UEFI?) based boot sequences, which is a kind of modern bootloading alternative to the BIOS.

A "device tree" is a data structure that is given at boot-time, probably by the 2nd stage bootloader, to the final stage kernel so that it load the right drivers (ie kernel modules) with the right parameters. It's a platform description that iis useful for describing the parameters of standard subcomponents like PCI buses, Brand X ethernet chips, etc. In

In ARM land there has never been anything like the BIOS, which was tailored to specific hardware (especially motherboards or laptops) but had quite a universal interface across plaforms.. The BIOS was thus able to help the kernel identify the hardware arrangment of the platform. Because ARM has not history of a standard firmware bootloading stage to describe hardware, as PCs have (or had) BIOS, device trees (along with kexecboot or u-boot or barebox etc) are a more essential consideration for arm. A booting ARM core doesn't even know about other cores in the same multi-core CPU. A "device tree" a document (source or compiled bytecode) that can be passed to the kernel at boot that describes the hardware layout of the entire system.

dts: Source file specification of a device tree for a platform.
dtb: Compiled bytecode representing the device tree, sometimes called a Flattened Devicee Tree (FDT).
dtc: The bytecode compiler that turns dts files into dtb file

Do gifs work?

Uboot information

uBoot on the Tegra consists of 2 parts. An SPL which will run on the Bootrom and will prepare and setup the transfer from Boot CPU to Main CPU.

U-Boot debug output

The file above has the following logging configuration:

CONFIG_LOG_MAX_LEVEL=9 CONFIG_SPL_LOG_MAX_LEVEL=9 CONFIG_TPL_LOG_MAX_LEVEL=9 CONFIG_LOG_DEFAULT_LEVEL=9 CONFIG_LOG_CONSOLE=y CONFIG_SPL_LOG_CONSOLE=y CONFIG_TPL_LOG_CONSOLE=y

jwa4 Notes

UEFI Privilege Escalation: Execute code in Secure mode

Replace the Secure Monitor to execute user-defined code in Secure mode by using a Secure Monitor Call (SMC)

The idea

The goal is to get rid of Trustzone memory, so the page tables of the Trustzone memory need to be modified. To do this you need to be in the Secure mode.

But how do you get into Secure mode?

When you further think about it, you may notice that we could simply replace the Secure Monitor and put our own code there, by using the Yahallo exploit.

Finding MVBAR

To replace the Secure Monitor, you first need to locate it. The Monitor Vector Base Address Register points to the Monitor Vector Table, where the third table entry points to the Secure Monitor

Reading MVBAR

So just read the MVBAR, right?

But what are the Secure PL1 modes?

So they are only accessible from Secure state. A normal UEFI App executes at PL1 in non-Secure mode.

So reading the register at runtime won't work. But there are other options to get the address.

Reverse-engineering the firmware binary

You can get your UEFI firmware binary from C:\Windows\Firmware\SurfaceRTUEFI.bin.

For reverse engineering we have used Ghidra. For importing make sure to use ARM:LE:32:V7:default as language.

mcr p15,0x0,r0,cr12,cr0,0x1 is the instruction which sets MVBAR. Search for it. You should only find one result. The disassembly looks something like this:

When further analyzing this, you will quickly notice that you will not be able to find out MVBAR by just analyzing the UEFI binary. Maybe it's possible, but only with heavy reverse-engineering.

As you might have thought, there is an easier way to get the value of MVBAR.

Analyzing a memory dump

Dump memory

To analyze a memory dump you need to create one first. Our also compiles into a memory dump tool, modify if you need to change the memory address.

Analyzing and importing the dump

But what now? You have Megabytes of memory, and you need to pick an exact point out of it.

Of course we read the handful of existing and useful blog posts that are on the internet. Including this one:

It shows how a Monitor Vector Table looks like, when disassembled:

So only search for some branch instructions, right?

Not really. There are a lot of jump tables in the memory dump. After hours upon hours of starring at Ghidra and the internet, I managed to find the right one.

I searched for multiple branch instructions next to each other using this command xxd "trustzone.bin" | grep -E '(.{3}00 00ea){4}' (CTS helped me with that command)

I just went through the results and found a jump table at 0x811f8000.

But this time it was different: The payload started executing.

So it was clear: MVBAR is 0x811f8000

The Trustzone payload

Where to put the payload in memory

TODO: Add picture of Ghidra with the memory location

Compiling a relocateable payload

You can find a fully working payload example on . It includes the Makefile, a linker script, an assembly file and a C source file.

Using Assembler language

When configuring a large amout of registers, using a seperate .S/.asm file is more convinient than using inline assembly.

Here is a short example of an assembly file which loads the address of mybuffer into r0:

What to explain:

How the payload works and how it is executed and why exactly the strange memory location
verifying that payload executes in Secure mode
explain monitor mode a bit more (maybe)

Additional resources

(Including Monitor Vector Table)
(Figure 3.3)

!!! PLEASE READ !!!

hashtagThis is the development section. The stuff you find below is barely tested. Some of it might be even untested. USE FILES/INFORMATION FROM HERE AT YOUR OWN RISK!!!

!TODO for everyone

hashtagASAP

CTS devNotes

!TODO

hashtagsRT & s2

hashtagTCOVER

hashtagAUDIO

hashtagSENSOR COLLECTION

hashtagUEFI STUB

hashtagdistro installer

hashtagafter everything is done

Surface RT

hashtagMisc

hashtagAPX

hashtagBATTERY

hashtagUEFI

Surface 2

battery

TZ Exploit - CTS

hashtagIdea

hashtagTests

hashtagRead NS-Bit

hashtagRead EL

hashtagRead EL from APX

hashtagRead EL from UEFI

hashtagCreating a payload

hashtagStep by Step

hashtagStep 1:

hashtagStep 2:

tCover Linux support

hashtagWDSA Table

hashtagWhats wrong here?

hashtagObservation

Kernel module

Dump Bootrom

hashtagIdea

hashtagPreparation

hashtagSecureboot registers

hashtagfusee gelee payload

git for dummys [WIP!] (like me)

hashtagClone the repo with SSH

hashtagAdd upstream

hashtagupdate to upstream

hashtagedit local commits

hashtagsolve merge conflicts

hashtaglog stat

Leander devNotes

!TODO

UEFI Privilege Escalation Exploit Documentation

Yahallo: Free memory access

hashtagThe exploit

hashtagBackground story

hashtagUnderstand the formular

hashtagCalculation of the addresses

hashtagUse the exploit to disable the SMMU

hashtagTegra 3 SOC: Important information

hashtagDisable SMMU

hashtagWhat Yahallo does

UEFI Privilege Escalation: Execute code in Secure mode

hashtagThe idea

hashtagFinding MVBAR

hashtagReading MVBAR

hashtagBut what are the Secure PL1 modes?

hashtagReverse-engineering the firmware binary

hashtagAnalyzing a memory dump

hashtagDump memory

hashtagAnalyzing and importing the dump

hashtagThe Trustzone payload

hashtagWhere to put the payload in memory

hashtagCompiling a relocateable payload

hashtagUsing Assembler language

hashtagAdditional resources

Removing trustzone

hashtagDetails of the CPU

hashtagARM Architecture Reference Manual ARMv7 A & R edition

hashtagWhy modify page tables?

hashtagAdvantage

EFI linux booting

This is the development section. The stuff you find below is barely tested. Some of it might be even untested. USE FILES/INFORMATION FROM HERE AT YOUR OWN RISK!!!

ASAP

sRT & s2

TCOVER

AUDIO

SENSOR COLLECTION

UEFI STUB

distro installer

after everything is done

Misc

APX

BATTERY

UEFI

Idea

Tests

Read NS-Bit

Read EL

Read EL from APX

Read EL from UEFI

Creating a payload

Step by Step

Step 1:

Step 2:

WDSA Table

Whats wrong here?

Observation

Idea

Preparation

Secureboot registers

fusee gelee payload

Clone the repo with SSH

Add upstream

update to upstream

edit local commits

solve merge conflicts

log stat

The exploit

Background story

Understand the formular

Calculation of the addresses

Use the exploit to disable the SMMU

Tegra 3 SOC: Important information

Disable SMMU

What Yahallo does

The idea

Finding MVBAR

Reading MVBAR

But what are the Secure PL1 modes?

Reverse-engineering the firmware binary

Analyzing a memory dump

Dump memory

Analyzing and importing the dump

The Trustzone payload

Where to put the payload in memory

Compiling a relocateable payload

Using Assembler language

Additional resources

Details of the CPU

ARM Architecture Reference Manual ARMv7 A & R edition

Why modify page tables?

Advantage

Issues

TODO

Surface RT 1

@Leander's trial and fail

Compile OVMF for qemu

Install required packages

Download source

Compile OVMF

Setup qemu files and run it

Run qemu

Premade files

References

Compile a correct Linux kernel

Prepare GDB for debugging

Install

Run

Run qemu

Create configuration files

Create tasks.json