From 4b937366bd6f21c47665533fd885fc16c185525b Mon Sep 17 00:00:00 2001 From: Jonathan Herrewijnen Date: Tue, 12 Nov 2024 15:49:23 +0100 Subject: [PATCH] Merge remote-tracking branch 'origin/HEAD' --- .../source/BootROM_8890/01_start.rst | 6 +- documentation/source/BootROM_8890/04_xen.rst | 63 +++++++++++++++++++ .../{04_notes.rst => 05_notes.rst} | 19 ++++++ 3 files changed, 87 insertions(+), 1 deletion(-) create mode 100644 documentation/source/BootROM_8890/04_xen.rst rename documentation/source/BootROM_8890/{04_notes.rst => 05_notes.rst} (89%) diff --git a/documentation/source/BootROM_8890/01_start.rst b/documentation/source/BootROM_8890/01_start.rst index 1ac0aec..cd22e86 100644 --- a/documentation/source/BootROM_8890/01_start.rst +++ b/documentation/source/BootROM_8890/01_start.rst @@ -43,4 +43,8 @@ When the ROM is unable to boot from the internal storage, it enters ``Exynos Rec 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. Initial authorisation is done using the '_auth_bl1' function. Frederic has exploited a vulnerability in the download protocol to load Unauthorized images. \ No newline at end of file +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. Initial authorisation is done using the '_auth_bl1' function. Frederic has exploited a vulnerability in the download protocol to load Unauthorized images. + +SOC information +--------------- +The Exynos 8890 runs on ARM64, or AARCH64, it's part of the Armv8-A architecture. \ No newline at end of file diff --git a/documentation/source/BootROM_8890/04_xen.rst b/documentation/source/BootROM_8890/04_xen.rst new file mode 100644 index 0000000..7603811 --- /dev/null +++ b/documentation/source/BootROM_8890/04_xen.rst @@ -0,0 +1,63 @@ +=== +XEN +=== + + +partitions +---------- + +.. code:: bash + + (venv) ➜ MIB3 Top High mmls 32gb.bin + GUID Partition Table (EFI) + Offset Sector: 0 + Units are in 4096-byte sectors + + Slot Start End Length Description + 000: Meta 0000000000 0000000000 0000000001 Safety Table + 001: ------- 0000000000 0000000255 0000000256 Unallocated + 002: Meta 0000000001 0000000001 0000000001 GPT Header + 003: Meta 0000000002 0000000005 0000000004 Partition Table + 004: 000 0000000256 0000002815 0000002560 boot_a + 005: 001 0000002816 0000005375 0000002560 boot_b + 006: 002 0000005376 0000005887 0000000512 hyp_a + 007: 003 0000005888 0000006143 0000000256 dtb_a + 008: 004 0000006144 0000009727 0000003584 kerneldom0_a + 009: 006 0000009728 0000012287 0000002560 initramfsdom0_a + 010: 007 0000012288 0000102911 0000090624 systemdom0_a + 011: 008 0000102912 0000109055 0000006144 system2dom0_a + 012: 012 0000109056 0000113919 0000004864 kerneldomu1_a + 013: 013 0000113920 0000114175 0000000256 dtbdomu1_a + 014: 014 0000114176 0000116735 0000002560 initramfsdomu1_a + 015: 015 0000116736 0000203775 0000087040 systemdomu1_a + 016: 016 0000203776 0000209919 0000006144 system2domu1_a + 017: 031 0000209920 0000210175 0000000256 align1 + 018: 032 0000210176 0000210687 0000000512 hyp_b + 019: 033 0000210688 0000210943 0000000256 dtb_b + 020: 034 0000210944 0000214527 0000003584 kerneldom0_b + 021: 036 0000214528 0000217087 0000002560 initramfsdom0_b + 022: 037 0000217088 0000307711 0000090624 systemdom0_b + 023: 038 0000307712 0000313855 0000006144 system2dom0_b + 024: 042 0000313856 0000318719 0000004864 kerneldomu1_b + 025: 043 0000318720 0000318975 0000000256 dtbdomu1_b + 026: 044 0000318976 0000321535 0000002560 initramfsdomu1_b + 027: 045 0000321536 0000408575 0000087040 systemdomu1_b + 028: 046 0000408576 0000414719 0000006144 system2domu1_b + 029: 059 0000414720 0000418815 0000004096 system_error_dump + 030: 069 0000418816 0000420863 0000002048 sys_ss + 031: 070 0000420864 0000437247 0000016384 sys_persist + 032: 071 0000437248 0000453631 0000016384 sys_irc + 033: 072 0000453632 0000500735 0000047104 sys_misc1 + 034: 099 0000500736 0001063935 0000563200 ivi_opt + 035: 100 0001063936 0007626751 0006562816 ivi + 036: ------- 0007626752 0007627775 0000001024 Unallocated + +TFFS is a proprietary file system from Tuxera, with one mounter available `tffsmount `_, however, we had no success mounting this file system. However, a lot of information can already be extracted from the binary by using a simple strings operation. + +Perceived boot order: boot_a, then hypervisor via hyp_a. dtb_a could be the device tree blob, providing information of/on hardware devices. kerneldom0_a would be the primary kernel, with initramfs being the RAM disk for dom0. + +.. quote:: "Dom0 is the initial domain started by the Xen hypervisor on boot. Dom0 is an abbrevation of "Domain 0" (sometimes written as "domain zero" or the "host domain"). Dom0 is a privileged domain that starts first and manages the DomU unprivileged domains. The Xen hypervisor is not usable without Dom0. This is essentially the "host" operating system (or a "service console", if you prefer). As a result, Dom0 runs the Xen management toolstack, and has special privileges, like being able to access the hardware directly." + +Data can be shared between domains using XenStore - an information storage space between domains maintained by Xenstored. + +Dom0 is the only domain with direct access to hardware, with DomU being an unprivileged domain, which need to communicate with Dom0 to access hardware. Multiple DomU can be created. \ No newline at end of file diff --git a/documentation/source/BootROM_8890/04_notes.rst b/documentation/source/BootROM_8890/05_notes.rst similarity index 89% rename from documentation/source/BootROM_8890/04_notes.rst rename to documentation/source/BootROM_8890/05_notes.rst index aa7388d..962f028 100644 --- a/documentation/source/BootROM_8890/04_notes.rst +++ b/documentation/source/BootROM_8890/05_notes.rst @@ -258,4 +258,23 @@ I tried modifying some code to write text to the screen. In order to view whethe It would appear that I'm currently only able to modify code before executing any part of BL33. I'm as of yet unable to return to the debugger at any point in BL33. +Week 45 - 2024 +-------------- +Loaded the debugger on the Head unit. There are some differences between the Head Unit and the phone (obviously), with the MIB3 boot stages being generally quite a bit larger. For instance, BL1 (or the second part of BL1) is 8.0Kb on the Samsung S7, but 28 Kb on the MIB3. As a result, the BL31 starts at ``0x020c0000`` on the MIB3, but at ``0x02024000``. This also means that some pointers are at different addresses. On the S7, we overwrite a pointer at ``0x02021880`` on the MIB3, this pointer is at ``0x02021890``. Similarly, the pointer at BL31 changes because the BL31 starts at a different address. + +The debugger stays alive, up until after booting BL2. But when we jump into the function that should receive the next boot stage for BL33, the debugger does not return, nor receive the next boot stage. Normally, on the Samsung S7, the device returns to the debugger, allowing modifications on the BL33 boot stage in memory. + +.. code:: python + + self.cd.restore_stack_and_jump(hijacked_fun) + time.sleep(1) + self.connect_device() + + self.send_normal_stage(bl33) # Never returns/completes on the MIB3 + self.connect_device() + self.usb_read(0x200) # GiAs + +The MMU appears to be off however. + +Quick look through the MIB3 images, shows that some partitions are still unencrypted, and contain a fair amount of strings.