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:

https://developer.arm.com/documentation/ddi0406/latest

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.

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 SMC Calling Convention 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 github repository also compiles into a memory dump tool, modify MemoryDumpTool/App.c 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: https://fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html

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

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:

# This should link into the .text section
.text

# Define a buffer with the size of 16 bytes
mybuffer: .word 16

# Make assembly_code available globally (so it can be used in C code)
.global assembly_code
.type assembly_code, function
assembly_code:
    # Push the return address to the stack
    # Do this if you branch
    push {lr}
    
    # Load the address of mybuffer into memory
    # This is the important line.
    # ldr r0, =mybuffer doesn't work
    adr r0, mybuffer
    
    # Get the return address back from the stack
    pop {pc}

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)

• what to do now

• maybe how to use ghidra

Additional resources

1. Structure of Vector Tables (Including Monitor Vector Table)

2. Monitor Vector Base Address Register

3. ARM Processor Modes and Registers (Figure 3.3)

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 yahallo source code. 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 here, 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.)