295 lines
13 KiB
ReStructuredText
295 lines
13 KiB
ReStructuredText
=====
|
||
Notes
|
||
=====
|
||
General notes on interesting/peculiar things found on the S7 USB recovery boot process
|
||
|
||
Emulator
|
||
--------
|
||
What is interesting about the ROM is that it starts by checking MPIDR_EL1 register and doing a conditional branch to 0x20e0000.
|
||
|
||
.. code-block:: bash
|
||
|
||
undefined w0:1 <RETURN>
|
||
Reset XREF[1]: Entry Point(*)
|
||
00000000 bb 00 38 d5 mrs x27,mpidr_el1
|
||
00000004 7b 0f 78 92 and x27,x27,#0xf00
|
||
00000008 7f 03 00 f1 cmp x27,#0x0
|
||
0000000c 41 00 00 54 b.ne LAB_00000014
|
||
00000010 fc 7f 83 14 b LAB_020e0000
|
||
|
||
BL1 peculiarities
|
||
-----------------
|
||
At this point, we assumed that the authentication was succesful, and the bootROM would jump back to the debugger after loading, but this was not the case. After running this function, we were able to send a single packet, but never received a response. Indicating that the function we were executing never returned on us.
|
||
|
||
.. figure:: images/bl1_auth_references.png
|
||
:align: center
|
||
|
||
BL1 authentication
|
||
|
||
If authentication at auth_bl1 is succesful, the returns a value from a function at ``1230c``. This function does some things, but eventually jumps to a function at:
|
||
|
||
.. figure:: images/bl1_auth_follow-up_1230c.png
|
||
:align: center
|
||
|
||
BL1 authentication
|
||
|
||
After authentication the bootROM jumps to this function at, we can execute this function with the debugger.
|
||
|
||
.. code-block:: python
|
||
|
||
self.cd.memwrite_region(0x02020f60, p32(0x020c0000))
|
||
BOOT_BL1 = 0x00019310
|
||
def jump_bl1(lr):
|
||
self.cd.arch_dbg.state.LR = lr
|
||
self.cd.restore_stack_and_jump(BOOT_BL1)
|
||
|
||
jump_bl1(0x020c0000)
|
||
|
||
jump_fwbl1()
|
||
|
||
BL1 is loaded at the download buffer and self copies to ``0x02022000`` and resumes execution there, with a size of 0x2000 (``0x02022000`` to ``0x02024000``).
|
||
|
||
However, this does not result in a jump back to the debugger. But the ROM still allows receival of one data package from the USB host (this is likely the system 'waiting' to receive the bootloader).
|
||
|
||
By adding the IMEM to ghidra, we can have a look at what is going here. After having modified the LR to jump back to the debugger and jumping into auth_bl1 at ``0x00012848`` we jump back to the debugger. Jumping into BL1 at ``2c0`` does not return us to the debugger. Here we need to hijack ``020200dc`` and ``02021880`` we're able to boot into BL1. We store the address of the hijacked function, to restore it later for a proper boot flow.
|
||
|
||
.. code:: python
|
||
|
||
auth_bl1(DEBUGGER_ADDR)
|
||
self.usb_write(b"FLSH") # Flush cache
|
||
hijacked_fun = u32(self.cd.memdump_region(0x020200dc, 4))
|
||
|
||
# BL1 patches
|
||
self.cd.memwrite_region(0x020200dc, p32(DEBUGGER_ADDR)) # hijack ROM_DOWNLOAD_USB for BL31
|
||
self.cd.memwrite_region(0x02021880, self.cd.arch_dbg.sc.branch_absolute(DEBUGGER_ADDR, branch_ins="br"))
|
||
|
||
Authentication of BL1 seems to be done at ``0x0012848``. With return value '0' expected when this function is executed, to execute other functions.
|
||
|
||
.. figure:: images/bl1_auth_references.png
|
||
:align: center
|
||
|
||
BL1 authentication.
|
||
|
||
purpose
|
||
^^^^^^^
|
||
bl1 interacts with several pheriperals, from the DTB these are:
|
||
|
||
.. code-block:: bash
|
||
|
||
/* FSYS0 */
|
||
pinctrl_5: pinctrl@10E60000 {
|
||
compatible = "samsung,exynos8890-pinctrl";
|
||
reg = <0x0 0x10E60000 0x1000>;
|
||
interrupts = <0 212 0>;
|
||
};
|
||
|
||
/* FSYS1 */
|
||
pinctrl_6: pinctrl@15690000 {
|
||
compatible = "samsung,exynos8890-pinctrl";
|
||
reg = <0x0 0x15690000 0x1000>;
|
||
interrupts = <0 202 0>;
|
||
};
|
||
|
||
/* PERIC1 */
|
||
pinctrl_9: pinctrl@14CC0000 {
|
||
compatible = "samsung,exynos8890-pinctrl";
|
||
reg = <0x0 0x14CC0000 0x1000>;
|
||
interrupts = <0 460 0>;
|
||
};
|
||
|
||
pmu_system_controller: system-controller@105C0000 {
|
||
compatible = "samsung,exynos8890-pmu", "syscon";
|
||
reg = <0x0 0x105C0000 0x10000>;
|
||
};
|
||
|
||
rtc@10070000 {
|
||
compatible = "samsung,s3c6410-rtc";
|
||
reg = <0x0 0x10070000 0x100>;
|
||
interrupts = <0 73 0>, <0 74 0>;
|
||
clocks = <&clock 157>;
|
||
clock-names = "gate_rtc";
|
||
};
|
||
|
||
Probably the only thing it does is set some clocks and prepare for BL31.
|
||
|
||
The reason for this is the following code in bl1:
|
||
|
||
.. code-block:: c
|
||
|
||
iVar3 = FUN_02024320();
|
||
if (iVar3 == 1) {
|
||
(*(code *)(ulong)uRam0000000002020108)(0,1);
|
||
}
|
||
|
||
This code uses a predefined ROM function(I was looking for it) and jumps back to that function when it's done.
|
||
This function is at address ``0x020200e8``, looking in our IMEM dump we can see where in the ROM this points to:
|
||
|
||
.. code-block:: c
|
||
|
||
DAT_02020108 XREF[2]: FUN_00001708:000018b4(W),
|
||
FUN_02021970:02021a40(R)
|
||
02020108 90 57 00 00 undefined4 00005790h
|
||
|
||
Replacing this function with our debugger makes us jump back:
|
||
|
||
.. code-block:: python
|
||
|
||
# Overwrite jump back
|
||
self.cd.memwrite_region(0x02020108, p32(0x2069000))
|
||
self.cd.memwrite_region(0x020200e8, p32(0x2069000))
|
||
|
||
def jump_bl1():
|
||
self.cd.arch_dbg.state.LR = 0x2069000
|
||
self.cd.restore_stack_and_jump(0x02024010)
|
||
# self.cd.restore_stack_and_jump(0x02021810)
|
||
|
||
bl1 = open("../S7/bl1.bin", "rb").read()
|
||
self.cd.memwrite_region(0x02024000, bl1)
|
||
self.usb_write(b"FLSH")
|
||
|
||
# auth_bl1()
|
||
jump_bl1()
|
||
assert self.usb_read(0x200) == b"GiAs", "not jumped back to debugger?"
|
||
self.cd.arch_dbg.state.print_ctx()
|
||
|
||
root | DEBUG |
|
||
X0 : 0xc00000 | X1 : 0x2069000 | X2 : 0x0 | X3 : 0x2023114 | X4 : 0x4 | X5 : 0x0 | X6 : 0x0 |
|
||
X7 : 0x136c0008 | X8 : 0x2069000 | X9 : 0x0 | X10 : 0x2070000 | X11 : 0x0 | X12 : 0x0 | X13 : 0x0 |
|
||
X14 : 0xf | X15 : 0x206d000 | X16 : 0x9 | X17 : 0x0 | X18 : 0x1 | X19 : 0x20200e8 | X20 : 0x0 |
|
||
X21 : 0x80000000 | X22 : 0x0 | X23 : 0x0 | X24 : 0x0 | X25 : 0x0 | X26 : 0x0 | X27 : 0x1 |
|
||
X28 : 0x0 | X29 : 0x2020ed8 | LR/X30 : 0x202419c | SP/X31 : 0x2020ec0
|
||
|
||
However this does not fully run bl1, so we will have to dig a bit deeper to see the puropose and when to jump back to the debugger.
|
||
|
||
|
||
Week 35 - 2024
|
||
--------------
|
||
After booting BL31, the MMU seems to be set up, and we're unable to do get any data off of spaces we're not 'allowed' to access. Patching the if-statement at 0x020244e8, disables the bit that says that the MMU is setup, but booting into recovery is possible (meaning the MMU is setup). Additionally, the memory at 0x02035600 is still not dumpable. At 0x02048000 is still accessible.
|
||
|
||
Weird space found at 0x105c2400. Seems to contain references to usb buffer (about 48-64 bytes). Also space at 0x020307f0, but I lose access to this after booting
|
||
|
||
.. code-block:: python
|
||
|
||
self.cd.memdump_region(0x105c2400, 0x40).hex()
|
||
'0f0f00000f0008002100000000000000ffffffffffffffffffffffffffffffff0f0f00000f0008002101000000000000ffffffffffffffffffffffffffffffff'
|
||
|
||
Week 36 - 2024
|
||
--------------
|
||
Interesting links:
|
||
- `Heap overflow <https://highaltitudehacks.com/2020/09/05/arm64-reversing-and-exploitation-part-1-arm-instruction-set-heap-overflow.html>`_
|
||
- `UART on S8 <https://grimler.se/posts/exynos-uart/>`_
|
||
|
||
By accident found space at 0x11207010. Seems to be a memory read/write space. Not executable however, unless the MMU is turned off.
|
||
|
||
We can use this space to store our debugger, and patch the boot process. After loading BL2, we're now indeed loading VBAR's for EL1.
|
||
|
||
bl31
|
||
MMU is 0x0 (0x1=enabled, 0x0=disabled)
|
||
TTBR0_EL3: 0xbc4640892f1460, TTBR1_EL2: 0x854d39cb76f0, TTBR0_EL1: 0xa5c20f408c581142
|
||
VBAR_EL3: 0x18800, VBAR_EL2: 0x0, VBAR_EL1: 0x0
|
||
TCR_EL3: 0x0, TCR_EL2: 0x80800000, TCR_EL1: 0x0
|
||
SCTLR_EL3: 0xc5183a, SCTLR_EL2: 0x30c5083a, SCTLR_EL1: 0xc5083a
|
||
MAIR_EL3: 0x44e048e000098aa4, MAIR_EL2: 0x9e42bf572931240b, MAIR_EL1: 0x44e048e000098aa4
|
||
Current EL: 0xc
|
||
|
||
Jumped to 0x11207010 and back
|
||
|
||
bL2
|
||
[+] Sent stage
|
||
Connected device! 0x4e8 0x1234
|
||
MMU is 0x0 (0x1=enabled, 0x0=disabled)
|
||
TTBR0_EL3: 0xbc4640892f1460, TTBR1_EL2: 0x854d39cb76f0, TTBR0_EL1: 0xa5c20f408c581142
|
||
VBAR_EL3: 0x2031800, VBAR_EL2: 0x0, VBAR_EL1: 0x2053800
|
||
TCR_EL3: 0x0, TCR_EL2: 0x80800000, TCR_EL1: 0x0
|
||
SCTLR_EL3: 0xc5183a, SCTLR_EL2: 0x30c5083a, SCTLR_EL1: 0x30c5083a
|
||
MAIR_EL3: 0x44e048e000098aa4, MAIR_EL2: 0x9e42bf572931240b, MAIR_EL1: 0x44e048e000098aa4
|
||
Current EL: 0xc
|
||
|
||
The debugger at 0x11200000 can only dump 0x768 at a time (its space related. Before BL31 this is also an issue.).
|
||
|
||
There's an odd space at 0x14kk. With things like deadcafe:
|
||
|
||
.. code::
|
||
|
||
1c0000000000000000000000fecaadde00000000fecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddefecaaddef
|
||
|
||
Week 37 - 2024
|
||
--------------
|
||
A few days ago, I noticed that the memory is no longer being cleared between boots. After some discussion, it seems most likely, that this is because I'm booting the device further, eventually into recovery mode. At some point, it doesn't clear the memory anymore (or it's not being cleared). This is interesting, as it allows me to see what was loaded into memory, before I start booting the device.
|
||
|
||
So, I've written something to dump the location of thte TTBR0_EL3 table, before booting any of BL1, but after loading the initial debugger. The read bytes are fluctuating, strongly, but there seems to be a pattern. I'm hoping that after enough boots, I'll have enough data to reconstruct the table.
|
||
|
||
.. code-block:: python
|
||
|
||
import pandas as pd
|
||
blub = self.cd.memdump_region(0x02035000, 0x1000)
|
||
try:
|
||
df = pd.read_pickle('ttbr0_el3.pkl')
|
||
# Concat data to existing dataframe
|
||
df = pd.concat([df, pd.Series([blub])], ignore_index=True)
|
||
except:
|
||
df = pd.DataFrame()
|
||
df['TTBR0_EL3'] = [blub]
|
||
df.to_pickle('ttbr0_el3.pkl')
|
||
|
||
I tried modifying some code to write text to the screen. In order to view whether this would at all be possible, I tried modifying code that would alter the message printed when booting normally (it would print: USB RECOVERY MODE). But it would appear that this is already in space that is by then not accessible anymore. The 'str' function crashes the device. Doesn't really matter where I do this, but the space seems immutable.. The movz and movk is because I was having issues moving data into registers.
|
||
|
||
.. code:: python
|
||
|
||
# Write NOP from 0x8f008cb8 to 0x8f008d14 using self.cd.memwrite
|
||
for i in range(0x8f008cb8, 0x8f008d14, 4):
|
||
self.cd.memwrite_region(i, b'\x1f\x20\x03\xd5')
|
||
#self.cd.memwrite_region(0x8f008cb8, struct.pack('>I', 0x1f2003d5))
|
||
|
||
# Write opcode that writes 'aaaaaaaa' at 0x8f06ab10
|
||
shellcode = f"""
|
||
// Load the target address (0x8f06ab10) into x21
|
||
movz x21, #0x8f06 // Load the high half of the address
|
||
movk x21, #0xab10, lsl #16 // Load the low half of the address
|
||
|
||
// Load the value 'aaaa' (0x6161616161616161) into x22
|
||
movz x20, #0xbeef
|
||
|
||
// Write the contents of x20 to the bytes where x21 points to
|
||
str x20, [x21]
|
||
"""
|
||
shellcode = ks.asm(shellcode, as_bytes=True)[0]
|
||
self.cd.memwrite_region(0x8f008cb8, shellcode)
|
||
|
||
It would appear that I'm currently only able to modify code before executing any part of BL33. I'm as of yet unable to return to the debugger at any point in BL33.
|
||
|
||
Week 45 - 2024
|
||
--------------
|
||
Loaded the debugger on the Head unit. There are some differences between the Head Unit and the phone (obviously), with the MIB3 boot stages being generally quite a bit larger. For instance, BL1 (or the second part of BL1) is 8.0Kb on the Samsung S7, but 28 Kb on the MIB3. As a result, the BL31 starts at ``0x020c0000`` on the MIB3, but at ``0x02024000``. This also means that some pointers are at different addresses. On the S7, we overwrite a pointer at ``0x02021880`` on the MIB3, this pointer is at ``0x02021890``. Similarly, the pointer at BL31 changes because the BL31 starts at a different address. Mitigated most changes, except for the authenitcation part.
|
||
|
||
The debugger stays alive, up until after booting BL2. But when we jump into the function that should receive the next boot stage for BL33, the debugger does not return, nor receive the next boot stage. Normally, on the Samsung S7, the device returns to the debugger, allowing modifications on the BL33 boot stage in memory.
|
||
|
||
.. code:: python
|
||
|
||
self.cd.restore_stack_and_jump(hijacked_fun)
|
||
time.sleep(1)
|
||
self.connect_device()
|
||
|
||
self.send_normal_stage(bl33) # Never returns/completes on the MIB3
|
||
self.connect_device()
|
||
self.usb_read(0x200) # GiAs
|
||
|
||
The MMU appears to be off however (?!). Quick look through the MIB3 images, shows that some partitions are still unencrypted, and contain a fair amount of strings.
|
||
|
||
If jumping into the boot BL33 function twice, the LDFW returns -. at the second jump. By using the modified fwbl1 from Francis, we can apply patches to uboot and boot them.
|
||
|
||
.. code:: bash
|
||
|
||
<20>Recovery mode
|
||
|
||
[ERROR] Fail to load LDFW
|
||
=> Return value : -1
|
||
|
||
LDFW init status=> Return value : -1
|
||
|
||
|
||
[ERROR] Fail to load Secure payload
|
||
=> Return value : -.
|
||
|
||
I dumped the contents of 0xcf4dfb28 to 60, which is a boot path information setter. Something in BL33 is setting this, because it is still empty (0xFF) after booting into BL2 and waiting for BL33.
|