Fixed resturctured text layout

This commit is contained in:
Eljakim Herrewijnen 2024-08-16 23:00:13 +02:00
parent 5e7cfa7a60
commit 6bc9156cb6
3 changed files with 33 additions and 12 deletions

View File

@ -2,6 +2,14 @@
======= =======
Booting 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. 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. 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 debugger
======== --------
The initial debugger is written to ``0x2069000``, with debugger_stack and _storage at ``0x0206b000`` and ``0x0206d000`` respectively. 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): 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 X28 : 0x0 | X29 : 0x2020f00 | LR/X30 : 0x20c0000 | SP/X31 : 0x2020ef0
bl1 bl1
=== ---
.. figure:: images/initial_boot_function.png .. figure:: images/initial_boot_function.png
:align: center :align: center
@ -208,7 +217,7 @@ Authentication of BL1 seems to be done at ``0x0012848``. With return value '0' e
BL1 authentication. BL1 authentication.
purpose purpose
------- ^^^^^^^
bl1 interacts with several pheriperals, from the DTB these are: bl1 interacts with several pheriperals, from the DTB these are:
.. code-block:: dtsi .. code-block:: dtsi

View File

@ -1,18 +1,21 @@
=================== ===================
Exynos BootROM 8890 Exynos BootROM 8890
==================== ===================
The Exynos 8890 BootROM is a small piece of code that runs on the Exynos SoC at boot time. 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. 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. The BootROM is stored in a read-only memory and cannot be modified.
Protections Protections
----------- -----------
There are no stack canaries or guard pages, and no ASLR. Meaning there are almost no protections in place. 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 Firmware
---------------- ----------------
Samsung releases firmware files for their devices. These files contain the bootloader, modem, and other firmware files. 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. 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 Memory Layout
------------- -------------
TODO make memory layout of ROM, IMEM and some devices @JONHE TODO make memory layout of ROM, IMEM and some devices @JONHE
.. figure:: images/memory_layout.drawio.svg .. figure:: images/memory_layout.drawio.svg
@ -38,7 +42,8 @@ TODO make memory layout of ROM, IMEM and some devices @JONHE
Download protocol Download protocol
================= -----------------
When the ROM is unable to boot from the internal storage, it enters ``Exynos Recovery Mode``. 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. 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. 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) (TODO verify and document)
dldata 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 .. figure:: images/dl_packet.drawio.svg
The dldata packet is used to send data to the BootROM. 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:: .. info::
This protocol remains *mostly* the same for newer Exynos SoCs. This protocol remains *mostly* the same for newer Exynos SoCs.
USB Stack 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. 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>`_). 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). 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) 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>`_. 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. 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; } dldata;
Bug 2 Bug 2
----- ^^^^^
.. caution:: .. 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. The bug is an integer underflow in the calculation of the remaining size of the image.
DWC3 DWC3
==== ^^^^
The Exynos 8890 uses the Synopsys DesignWare USB 3.0 controller. 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). 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 Gupje
----- ^^^^^
In order to run the debugger, a small amount of the bootROM was reversed in order to implement send/recv functionality. In order to run the debugger, a small amount of the bootROM was reversed in order to implement send/recv functionality.

View File

@ -12,6 +12,7 @@ Documentation on Samsung devices, currently mainly the Samsung S7.
:caption: BootROMs: :caption: BootROMs:
BootROM_8890/index.rst BootROM_8890/index.rst
BootROM_8890/boot_chain.rst BootROM_8890/boot_chain.rst