Fixed resturctured text layout
This commit is contained in:
parent
5e7cfa7a60
commit
6bc9156cb6
@ -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
|
||||||
|
@ -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.
|
||||||
|
|
||||||
|
@ -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
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user