Samsung_S7/documentation/source/BootROM_8890/index.rst

===================
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.

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.
To extract the sboot.bin file from a samsung firmware file:

.. code-block:: bash

   $ unzip -p firmware.zip 'BL_*.tar.md5' | tar -Oxf - 'sboot.bin.lz4' | lz4 -d - sboot.bin

Memory Layout
-------------
TODO make memory layout of ROM, IMEM and some devices @JONHE

.. figure:: images/memory_layout.drawio.svg

    The memory layout of the Exynos 8890
    

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.

The Exynos BootROM uses a custom protocol to download a bootable image over USB. 
This image is verified and executed by the BootROM. Unauthorized images are rejected. (TODO verify and document)

dldata
------

.. figure:: images/dl_packet.drawio.svg

    The dldata packet is used to send data to the BootROM.


.. 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>`_). 

.. code-block:: dts

	udc: usb@15400000 {
		compatible = "samsung,exynos8890-dwusb3";
		clocks = <&clock 700>, <&clock 703>, <&clock 708>, <&clock 709>;
		clock-names = "aclk", "sclk", "phyclock", "pipe_pclk";
		reg = <0x0 0x15400000 0x10000>;
		#address-cells = <2>;
		#size-cells = <1>;
		ranges;
		usb-pm-qos-int = <255000>;
		status = "disabled";

		usbdrd_dwc3: dwc3 {
			compatible = "synopsys,dwc3";
			reg = <0x0 0x15400000 0x10000>;
			interrupts = <0 213 0>;
			phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
			phy-names = "usb2-phy", "usb3-phy";
		};
	};c


This is a basic USB controller, but some functions, that are also present in the linux kernel, should be visible in the bootROM as well. Available functions could be: `linux-kernel-dwc3 <https://android.googlesource.com/kernel/msm/+/android-msm-dory-3.10-kitkat-wear/drivers/usb/dwc3/core.h>`_.

Bug 1(Integer underflow)
------------------------

https://github.com/LineageOS/android_kernel_samsung_universal8890/blob/lineage-18.1/arch/arm64/boot/dts/exynos8890.dtsi

@TODO better explain frederick's bug. @JONHE


Bug 2
-----

.. caution::

   Might be a 0/N-day if exploitable


@ELHER 

There is a bug(unpatched?) in receiving the last packet of the usb image:

.. figure:: images/underflow_bug.png

    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.