Reverse Engineering Samsung S6 SBOOT - Part I

Web Search

I started by searching for Samsung bootloader and SBOOT related work on several search engines. Unfortunately, results on the subject were scarce and only one reverseengineering.stackexchange.com thread [5] dating back to March 2015 was relevant.

This thread mainly gives us 2 hints. J-Cho had the intuition that the bootloader starts at the file offset 0x3F000 and Just helping suggests that it is actually starting at 0x10.

As I wanted to dismiss my hypothesis that the bootloader base address is 0x00000000 and that its code always begins at 0x10, I started to look for bootloaders used in other Exynos smartphones. SBOOT in Meizu's smartphones does not give valid instructions at 0x10, confirming my doubts:

I also analyzed if there were any debug string left on other bootloaders that would give me hints on where SBOOT is generally loaded in memory. No luck :( But I got another lead: some strings in Meizu's SBOOT suggested that U-Boot is used. Even if U-Boot is not used on Samsung Galaxy S6, it was a lead worth exploring and I started to dig further.

U-Boot Repository

U-Boot is open-source and supports several Exynos chips. For instance, Exynos 4 and Exynos 5 have been supported for more than 5 years now. Support for the Exynos 7 has not fully landed on the mainline yet but, based on their mailing list [6], some patches exist for the Exynos 7 ESPRESSO development board.

I may have missed it, but going through patches for the ESPRESSO development board did not bear fruits :( I tried multiple known base addresses from Exynos 4 to Exynos 7 boards without succeeding. It was time to try another angle.

ARM Literal Pools

If you are used to reverse engineering ARM assembly, you must have noticed the massive use of literal pools to hold certain constant values that are to be loaded into registers. This property may help us to find approximately where SBOOT is loaded, especially when a branch destination address is loaded from a literal pool.

I searched all the branching instructions marked with errors in operands (highlighted in red) by IDA Pro. As the code of a bootloader is self-contained, I can safely assume that most of the branches destination address must target code in the bootloader itself. With this assumption, I could approximate the bootloader's base address.

From the very first instructions, I noticed the following branching errors:

The interesting facts on these code fragments are:

1. Branching instructions BR (Branch to register) are unconditional and suggest that it will not return.

2. The operand value for both branches is the same (0x2104010) and, it is located very early in the bootloader.

3. The last byte is 0x10 which is exactly the offset where the code of the bootloader seems to begin.

I arbitrarily assumed that the address 0x2104010 was a reset address and I tried to load the SBOOT binary at 0x2104000, with the following options:

• Processor Type: ARM Little Endian [ARM]

• Start ROM Address: 0x2104000

• Loading Address: 0x2104000

• Disassemble as 64-bit code: Yes

At least, IDA Pro found fewer errors which indicates that my assumption may be correct. Yet, I could not tell for sure that this base address was the right one, I needed to reverse engineer further to be sure. Spoiler: I nearly got it right :)

ARM System Registers

Now that I may have the potential base address, I continued reverse engineering SBOOT hoping that there were no anomalies in the code flow.

As I wanted to find the TEE OS, I started searching for pieces of code executed in the secure monitor. A rather simple technique to find the secure monitor consists in looking for instructions that set or read registers that can only be accessed from the secure monitor. As previously mentioned, the secure monitor runs in EL3. VBAR_EL3 is rather a good candidate to find EL3 code as it holds the base address of the EL3 exception vector table and leads to SMC handlers.

Do you remember the exception vector table's format presented at the beginning of this article? It is made of 16 entries of 0x80 bytes holding the code of exception handlers. Amongst the search results, code at 0x2111000 seemed to lead to a valid exception vector table:

Even though, the chosen base address was still not the right one :( When verifying other instructions that set VBAR_EL3, one can note that 0x210F000 is in the middle of a function:

These anomalies would suggest that 0x2104000 is not the right base address yet. Let us try something else.

Service Descriptors

Samsung Galaxy S6 SBOOT is partly based on ARM Trusted Firmware [7]. ARM Trusted Firmware is open-source and provides a reference implementation of secure world software for ARMv8-A, including a Secure Monitor executing at Exception Level 3 (EL3). The assembly code corresponding to the secure monitor is exactly the same as the one in ARM Trusted Firmware. This is good news because it will buy me some time and save me reverse engineering efforts.

I tried to find another anchor point in the disassembled code I could use to determine the base address of SBOOT. Members of type char * in structures are particularly interesting candidates as they point to strings whose addresses are defined at compile time. While comparing SBOOT disassembled code and ARM Trusted Firmware source code, I identified a structure, rt_svc_desc_t, that had the property I was looking for:

typedef struct rt_svc_desc {
    uint8_t start_oen;
    uint8_t end_oen;
    uint8_t call_type;
    const char *name;
    rt_svc_init_t init;
    rt_svc_handle_t handle;
} rt_svc_desc_t;

According to ARM Trusted Firmware's source code, rt_svc_descs is an array of rt_svc_desc_t that holds the runtime service descriptors exported by services. It is used in the function runtime_svc_init which can be easily located in SBOOT thanks to debug strings in its calling function bl31_main:

I tried to map the binary at different addresses and checked whether I could find valid strings for rt_svc_desc.name entries. Here is a small bruteforcing script:

import sys
import string
import struct

RT_SVC_DESC_FORMAT  = "BBB5xQQQ"
RT_SVC_DESC_SIZE    = struct.calcsize(RT_SVC_DESC_FORMAT)
RT_SVC_DESC_OFFSET  = 0xcb50
RT_SVC_DESC_ENTRIES = (0xcc10 - 0xcb50) / RT_SVC_DESC_SIZE

if len(sys.argv) != 2:
    print("usage: %s <sboot.bin>" % sys.argv[0])
    sys.exit(1)

sboot_file = open(sys.argv[1], "rb")
sboot_data = sboot_file.read()

rt_svc_desc = []
for idx in range(RT_SVC_DESC_ENTRIES):
    start = RT_SVC_DESC_OFFSET + (idx << 5)
    desc = struct.unpack(RT_SVC_DESC_FORMAT,
                         sboot_data[start:start+RT_SVC_DESC_SIZE])
    rt_svc_desc.append(desc)

strlen = lambda x: 1 + strlen(x[1:]) if x and x[0] in string.printable else 0

for base_addr in range(0x2100000, 0x21fffff, 0x1000):
    names = []
    print("[+] testing base address %08x" % base_addr)
    for desc in rt_svc_desc:
        offset = desc[3] - base_addr
        if offset < 0:
            sys.exit(0)
        name_len = strlen(sboot_data[offset:])
        if not name_len:
            break
        names.append(sboot_data[offset:offset+name_len])
    if len(names) == RT_SVC_DESC_ENTRIES:
        print("[!] w00t!!! base address is %08x" % base_addr)
        print("    found names: %s" % ", ".join(names))

Running this script on the analyzed SBOOT gave the following output:

$ python bf_sboot.py sboot.bin
[+] testing base address 02100000
[+] testing base address 02101000
[+] testing base address 02102000
[!] w00t!!! base address is 02102000
    found names: mon_smc, std_svc, tbase_dummy_sip_fastcall,
                 tbase_oem_fastcall, tbase_smc, tbase_fastcall
[...]

Victory! Samsung Galaxy S6 SBOOT's base address is 0x02102000. Reloading the binary into IDA Pro with this base address seems to correct all the oddities in the disassembled code I have seen so far. We are sure to have the right one now!

Missed Functions

While IDA Pro does an excellent job in disassembling common file formats, it will likely miss a lot of functions when reversing unknown binaries. In this situation, a common habit is to write a script looking for prologue instructions and declaring that a function exists at these spots. A simple AArch64 function prologue looks like this:

// AArch64 PCS assigns the frame pointer to x29
sub     sp, sp, #0x10
stp     x29, x30, [sp]
mov     x29, sp

The instruction mov x29, sp is a rather reliable marker for AArch64 prologues. The idea to find the beginning of the function is to search for this marker and to disassemble backward while common prologue instructions (mov, stp, sub for instance) are found. A function that searches for AArch64 prologues looks like this in IDA Python:

import idaapi

def find_sig(segment, sig, callback):
    seg = idaapi.get_segm_by_name(segment)
    if not seg:
        return
    ea, maxea = seg.startEA, seg.endEA
    while ea != idaapi.BADADDR:
        ea = idaapi.find_binary(ea, maxea, sig, 16, idaapi.SEARCH_DOWN)
        if ea != idaapi.BADADDR:
            callback(ea)
            ea += 4

def is_prologue_insn(ea):
    idaapi.decode_insn(ea)
    return idaapi.cmd.itype in [idaapi.ARM_stp, idaapi.ARM_mov, idaapi.ARM_sub]

def callback(ea):
    flags = idaapi.getFlags(ea)
    if idaapi.isUnknown(flags):
        while ea != idaapi.BADADDR:
            if is_prologue_insn(ea - 4):
                ea -= 4
            else:
                print("[*] New function discovered at %#lx" % (ea))
                idaapi.add_func(ea, idaapi.BADADDR)
                break
    if idaapi.isData(flags):
        print("[!] %#lx needs manual review" % (ea))

mov_x29_sp = "fd 03 00 91"
find_sig("ROM", mov_x29_sp, callback)

ARM64 IDA Plugins

ROM:0000000002104200                 BL              sub_2104468
ROM:0000000002104204                 MOV             X19, #0x814
ROM:0000000002104208                 MOVK            X19, #0x105C,LSL#16
ROM:000000000210420C                 MOV             X0, X19

ROM:0000000002104200                 BL              sub_2104468
ROM:0000000002104204                 MOVE            X19, #0x105C0814
ROM:000000000210420C                 MOV             X0, X19

Signatures

As previously mentioned, SBOOT is partly based on ARM Trusted Firmware [12]. Since the source code is available, one can save a lot of reverse engineering efforts by browsing the source code, recompiling it and do binary diffing (or signature matching) in order to recover as much symbols as possible.

I generally combine multiple binary diffing tools to propagate symbols between binaries:

• Rizzo [13] from Craig Heffner (devttys0)

• Bindiff [14] from Zymanics

• Diaphora [15] from Joxean Koret (@matalaz)

They sometimes have complementary results.