Fixed resturctured text layout
This commit is contained in:
parent
5e7cfa7a60
commit
6bc9156cb6
@ -2,6 +2,14 @@
|
||||
=======
|
||||
Booting
|
||||
=======
|
||||
This part describes the boot chain of the ``Exynos 8890`` SoC.
|
||||
|
||||
Booting Protocol
|
||||
================
|
||||
TODO document normal samsung boot chain
|
||||
|
||||
Exploitation
|
||||
============
|
||||
|
||||
After exploitation the goal is to fully boot the device.
|
||||
|
||||
@ -43,7 +51,8 @@ This results in the following files:
|
||||
After loading the stage1 (entry.S - Frederic's exploit), we're allowed to send custom payloads to the device. The first payload that is then sent, is the debugger.
|
||||
|
||||
debugger
|
||||
========
|
||||
--------
|
||||
|
||||
The initial debugger is written to ``0x2069000``, with debugger_stack and _storage at ``0x0206b000`` and ``0x0206d000`` respectively.
|
||||
|
||||
After the initial loading of the debugger, the processor state reported is (using ghidra assistant):
|
||||
@ -89,7 +98,7 @@ The processor state reported then is:
|
||||
X28 : 0x0 | X29 : 0x2020f00 | LR/X30 : 0x20c0000 | SP/X31 : 0x2020ef0
|
||||
|
||||
bl1
|
||||
===
|
||||
---
|
||||
|
||||
.. figure:: images/initial_boot_function.png
|
||||
:align: center
|
||||
@ -208,7 +217,7 @@ Authentication of BL1 seems to be done at ``0x0012848``. With return value '0' e
|
||||
BL1 authentication.
|
||||
|
||||
purpose
|
||||
-------
|
||||
^^^^^^^
|
||||
bl1 interacts with several pheriperals, from the DTB these are:
|
||||
|
||||
.. code-block:: dtsi
|
||||
|
@ -1,18 +1,21 @@
|
||||
===================
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@ -30,6 +33,7 @@ Frederic has also written a payload to extract the sboot.bin file from a connect
|
||||
|
||||
Memory Layout
|
||||
-------------
|
||||
|
||||
TODO make memory layout of ROM, IMEM and some devices @JONHE
|
||||
|
||||
.. figure:: images/memory_layout.drawio.svg
|
||||
@ -38,7 +42,8 @@ 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.
|
||||
@ -48,19 +53,22 @@ The Exynos BootROM uses a custom protocol to download a bootable image over USB.
|
||||
(TODO verify and document)
|
||||
|
||||
dldata
|
||||
------
|
||||
^^^^^^
|
||||
For uploading a stage to boot, a custom protocol is used. The dldata that has to be send is the following:
|
||||
|
||||
.. figure:: images/dl_packet.drawio.svg
|
||||
|
||||
The dldata packet is used to send data to the BootROM.
|
||||
|
||||
The size in the packet is the total size of the packet, including header and footer.
|
||||
|
||||
.. info::
|
||||
|
||||
This protocol remains *mostly* the same for newer Exynos SoCs.
|
||||
|
||||
USB Stack
|
||||
=========
|
||||
---------
|
||||
|
||||
This information is largely based on the blogpost of Frederic on reversing the `USB stack of the Exynos BootROM <https://fredericb.info/2020/06/reverse-engineer-usb-stack-of-exynos-bootrom.html#reverse-engineer-usb-stack-of-exynos-bootrom>`_. We're looking at the proprietary USB protocol used by the Exynos BootROM.
|
||||
|
||||
The base address of the usb controller (dwusb3) is mapped at 0x1540000, with a size of 0x10000: (can be found at: `Exynos8890 dtsi <https://github.com/LineageOS/android_kernel_samsung_universal8890/tree/lineage-18.1/arch/arm64/boot/dts>`_).
|
||||
@ -118,7 +126,8 @@ Other general device descriptors are also sent from the device to the host (to d
|
||||
Data is transferred via Transfer Request Blocks (TRB), dwc3_depcmd_starttransfer is used. The TRB then contains a buffer address, where transferred data from the host is written to. The buffer allocation is done by 'usb_setup_event_buffer', which sets bufferHigh (DWC3_GEVNTADRLO), bufferLow (DWC3_GEVNTADRHI) and bufferSize (DWC3_GEVNTSIZ).
|
||||
|
||||
Bug 1 (Integer overflow)
|
||||
------------------------
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Originally described in this `blogpost <https://fredericb.info/2020/06/exynos-usbdl-unsigned-code-loader-for-exynos-bootrom.html#exynos-usbdl-unsigned-code-loader-for-exynos-bootrom>`_.
|
||||
|
||||
The exynos bootrom uses a simple USB protocol to receive a bootloader binary from a USB host. The binary sent is called 'dldata'. In Ghidra, at 21518, we can see that it consists of unit32_t: ready?, uint32: size, ? : data, uint16: footer. The contents of this data are checked before being being written.
|
||||
@ -168,7 +177,7 @@ The trick then becomes, to get the pointer to an address we would like to exploi
|
||||
} dldata;
|
||||
|
||||
Bug 2
|
||||
-----
|
||||
^^^^^
|
||||
|
||||
.. caution::
|
||||
|
||||
@ -183,11 +192,13 @@ There is a bug(unpatched?) in receiving the last packet of the usb image:
|
||||
The bug is an integer underflow in the calculation of the remaining size of the 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.
|
||||
|
||||
|
@ -15,3 +15,4 @@ Documentation on Samsung devices, currently mainly the Samsung S7.
|
||||
BootROM_8890/boot_chain.rst
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user