Small docs update

This commit is contained in:
Jonathan Herrewijnen 2024-09-03 19:31:41 +02:00
parent e59478187d
commit 906629b80f
6 changed files with 31 additions and 22 deletions

View File

@ -183,7 +183,7 @@ After authentication the bootROM jumps to this function at, we can execute this
jump_fwbl1()
BL1 is loaded at the download buffer and self copies to ``0x02022000`` and resumes execution there (``0x02024010``), with a size of 0x2000 (0x02022000 to 0x02024000).
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).
@ -249,12 +249,10 @@ Probably the only thing it does is set some clocks and prepare for BL31.
BL31
----
BL31 is written at 0x02024000 with the entry point at 0x02024010.
BL31 is written at ``0x02024000`` with the entry point at ``0x02024010``.
BL2
---
0x02e8dc mentions 'Onyx-OPR6-8511R1', which is likely sboot.
OLD

View File

@ -1,21 +1,18 @@
===================
Exynos BootROM 8890
===================
The Exynos 8890 BootROM is a small piece of code that runs on the Exynos SoC at boot time.
It is responsible for initializing the hardware and loading the first stage bootloader from storage.
The BootROM is stored in a read-only memory and cannot be modified.
Protections
-----------
There are no stack canaries or guard pages, and no ASLR. Meaning there are almost no protections in place. There is however an SMC and a MMU. The SMC is used to communicate with the secure world, and the MMU is used to map the memory.
There are no stack canaries or guard pages, and no ASLR. Meaning there are almost no protections in place.
Rom is at address 0x0 and is unwritable(Sometimes this is writeable due to MMU caching).
Rom is at address 0x0 and is unwritable (Sometimes this is writeable due to MMU caching).
Samsung Firmware
----------------
Samsung releases firmware files for their devices. These files contain the bootloader, modem, and other firmware files.
To see how the ROM works we are interested in the sboot firmware, which contains multiple stages of the bootloader.
@ -49,7 +46,6 @@ TODO make memory layout of ROM, IMEM and some devices @JONHE
Download protocol
-----------------
When the ROM is unable to boot from the internal storage, it enters ``Exynos Recovery Mode``.
In this mode the bootROM accepts data over USB.
There is little functionality other than receiving data, meaning almost no additional attack surface except for the download protocol.
@ -199,12 +195,10 @@ There is a bug(unpatched?) in receiving the last packet of the usb image:
DWC3
^^^^
The Exynos 8890 uses the Synopsys DesignWare USB 3.0 controller.
Much of the code is shared with the DWC3 driver in the Linux kernel, except that the ROM does not do any scheduling and a lot of features have been removed(OTG handling, etc).
Gupje
^^^^^
In order to run the debugger, a small amount of the bootROM was reversed in order to implement send/recv functionality.

View File

@ -14,3 +14,9 @@ What is interesting about the ROM is that it starts by checking MPIDR_EL1 regist
0000000c 41 00 00 54 b.ne LAB_00000014
00000010 fc 7f 83 14 b LAB_020e0000
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. Interestingly, one of the setups is at
Patching the if-statement at 0x020244e8, and in doing so, disabling this function.

View File

@ -2629,7 +2629,7 @@
"outputs": [],
"source": [
"# Save to html\n",
"fig.write_html(\"stack_and_functions.html\")"
"fig.write_html(\"../_static/stack_and_functions.html\")"
]
}
],

View File

@ -13,6 +13,6 @@ Documentation on Samsung devices, currently mainly the Samsung S7.
BootROM_8890/index.rst
BootROM_8890/boot_chain.rst
BootROM_8890/notes.rst

View File

@ -725,18 +725,32 @@ class ExynosDevice():
# Jump BL31
self.cd.arch_dbg.state.LR = DEBUGGER_ADDR
self.cd.memwrite_region(0x20219b8, p32(DEBUGGER_ADDR))
# self.cd.memwrite_region(0x20219b8, p32(DEBUGGER_ADDR))
# self.cd.restore_stack_and_jump(hijacked_fun)
# Write 'a1 00 00 00' to 0x0202a330
# Write 0's to 0x11600
# Inspect TTBR0_EL3 table
TTBR0_EL3 = 0x02035600 # Zeroed
# Overwrite 02028b0c from 5f5820f8 to d503201f -> Doesn't seem to be doing anything
# self.cd.memwrite_region(0x02028b0c, struct.pack('>I', 0xd503201f))
# Same at 02028b8c
# self.cd.memwrite_region(0x02028b8c, struct.pack('>I', 0xd503201f))
# Modifies setting up MMU (but is set up eventually)
# self.cd.memwrite_region(0x020244e8, struct.pack('>I', 0x1f0c00f1)) # Change check to always false
# self.cd.memwrite_region(0x020244fc, b'\00'*8) # Change check to always false
self.cd.restore_stack_and_jump(0x02024010)
time.sleep(2)
self.connect_device()
self.usb_read(0x200) # GiAs
self.cd.arch_dbg.fetch_special_regs()
self.usb_read(0x200) # GiAs
regs = self.cd.arch_dbg.fetch_special_regs()
# print status of MMU
print(f'MMU is {hex(self.cd.arch_dbg.state.R_SCTLR_EL3.mmu)} (1=enabled, 0=disabled)')
BL31_ra = self.cd.arch_dbg.state.LR
@ -804,7 +818,4 @@ if __name__ == "__main__":
exynos.setup_guppy_debugger()
exynos.dumb_interact()
sys.exit(0)
with open()
sys.exit(0)