update docs regarding xen

This commit is contained in:
Jonathan Herrewijnen 2024-11-12 17:44:35 +01:00
parent f905c6d2d3
commit 7cb00e4c98
8 changed files with 255 additions and 64 deletions

9
.vscode/launch.json vendored
View File

@ -4,6 +4,15 @@
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Run a python file",
"type": "debugpy",
"request": "launch",
"program": "${file}",
"args": [],
"console": "integratedTerminal",
"justMyCode": false
},
{
"name": "Run exploit",
"type": "python",

View File

@ -358,3 +358,10 @@ If removing the ROM/UFS Short, the phone will go into odin mode. And is visible
Bus 001 Device 043: ID 04e8:685d Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Download mode)
Exploiting on the MIB3
======================
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`` on the Samsung S7. 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. Mitigated most changes, except for the ``Authentication??`` part in BL31 (when booting from BL2 into BL33, something is done in BL31 to either verify or do something.)
The MMU appears to be off however.
This topic resumes in xen_and_mib3

View File

@ -1,63 +0,0 @@
===
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 <https://github.com/NetherlandsForensicInstitute/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.

View File

@ -0,0 +1,191 @@
============
XEN and MIB3
============
partitions
----------
The contents of the partitions taken from a chipoff. There's a large IVI partition containing partitions of its own.
.. 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 <https://github.com/NetherlandsForensicInstitute/tffsmount>`_, however, we had no success mounting this file system. Luckily, a fair bit of information can already be extracted from the binary by using a simple strings operation. In order to view the contents of a specific partition, it's best to extract and unzip the partitions of interest.
.. code:: bash
dd if=32gb.bin of=initramfsdom0_a.bin.gz skip=0000009728 count=2560 bs=4096
gunzip initramfsdom0_a.bin.gz
mkdir initramfsdom0_a
mv initramfsdom0_a.bin initramfsdom0_a
cd initramfsdom0_a
cpio -idmv < initramfsdom0_a.bin
Alternative approach (not working for partitions within the IVI).
``python3 -m tffsmount 32gb.bin /tmp/mib3/tffsmount2 -o 0x1be00000``
.. code:: bash
➜ MIB3 Top High xxd 32gb.bin | grep .~.TFFS
03000000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
03006000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
17755d40: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
1c800000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
1c806000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
2d2b5d40: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
35000000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
35006000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
49755d40: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
4e800000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
4e806000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
5f2b5d40: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
66400000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
66406000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
66c00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
66c06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
6ac00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
6ac06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
6ec00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
6ec06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
7a400000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
7a406000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
104000000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
104006000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
105974000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
10597a000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
129474000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
12947a000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
25fc00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
25fc06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
263c00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
263c06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
26fc00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
26fc06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
3afc00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
3afc06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
3dfc00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
3dfc06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
4dfc00000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
4dfc06000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
545400000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
545406000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
745400000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
745406000: eb7e 9054 4646 5320 2020 2000 0000 0000 .~.TFFS .....
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.
Domain0 and DomainU
-------------------
.. 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.
Sharing devices between Dom0 and DomU.
.. quote:: "To access devices that are to be shared between domains, like the disks and network interfaces, the DomUs must communicate with Dom0. This is done by using a two-part driver. The FrontendDriver must be written for the OS used in the DomU, and uses XenBus, XenStore, shared pages, and event notifications to communicate with the BackendDriver, which lives in Dom0 and fulfils requests. To the applications and the rest of the kernel, the FrontendDriver just looks like a normal network interface, disk, or whatever. ""
Wahrheit.
XEN logs
^^^^^^^^^^
.. code:: bash
<20><>Recovery mode
=> Return value : 3oad LDFW
S8=> Return value : 0
Xen 4.8.0
(XEN) [ 0.209091] [SB_ERR]Integrity check fail
(XEN) [ 0.209119] [SB_ERR]verify_signature: binary ID = [0x10], return = [0x50E01]
(XEN) [ 0.209128] Dom[1] Fail to auth the dtb binary, ret:331265
(XEN) [ 0.209565] Dom[0] 2th, load kernel binary at 0000000081280000, 0000000000100000
(XEN) [ 0.211313] Static RAM[00000008c0000000 ~ 000000097a000000] -> guest address [00000008c0000000 ~ 000000097a000000]
(XEN) [ 0.226360]
(XEN) [ 0.226360] ****************************************
(XEN) [ 0.233678] Loading dom initrd from 0000000089200000 to 0x0000000089200000-0x0000000089340000
(XEN) [ 0.237909] Dom[0] 3th, load kernel binary at 0000000081380000, 0000000000100000
(XEN) [ 0.245791] DOM RAM Popluation of the pre-assigned range done. unassigned mem:0x 0000000000000000 Bytes
(XEN) [ 0.253771] Panic on CPU 7:
(XEN) [ 0.263057] Allocating PPI 16 for event channel interrupt
(XEN) [ 0.274424] Dom[0] 4th, load kernel binary at 0000000081480000, 0000000000100000
(XEN) [ 0.284998] Fail to auth the dtb binary
(XEN) [ 0.291690] Loading dom0 DTB to 0x0000000089000000-0x000000008901e99e dtb_virt:0x0000000089000000
(XEN) [ 0.302564] Dom[0] 5th, load kernel binary at 0000000081580000, 0000000000100000
(XEN) [ 0.303995] ****************************************
(XEN) [ 0.303995]
(XEN) [ 0.313722] ___Dom0 construction done___
(XEN) [ 0.324977] Dom[0] 6th, load kernel binary at 0000000081680000, 0000000000100000
(XEN) [ 0.329844] Reboot in five seconds...
(XEN) [ 0.346093] Dom[0] 7th, load kernel binary at 0000000081780000, 0000000000100000
(XEN) [ 5.365817] exynos8890: keep scratch, 0xd (shutdown_code: 3)

View File

@ -260,7 +260,7 @@ It would appear that I'm currently only able to modify code before executing any
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.
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. Mitigated most changes, except for the authenitcation part.
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.

View File

@ -0,0 +1,3 @@
from herrewebpy.firmware_forensics import memory_drawer
img = memory_drawer('partitions.csv')
img

View File

@ -0,0 +1,44 @@
start,end,name,order,comment,X0,LR
0x3000000,0x191ff000,systemdom0_a,,0000012288 to 0000102911,,
0x3006000,?,,,Not found with mmls. Divides to 12294,,
0x17755d40,?,,,Not found with mmls. Divides to 96085,,
0x1c800000,0x31bff000,systemdomu1_a,,0000116736 to 0000203775,,
0x1c806000,,,,Not found with mmls. Divides to 116742,,
0x2d2b5d40,,,,Not found with mmls. Divides to 185013.828125,,
0x35000000,,systemdom0_b,,0000217088 to 0000307711,,
0x35006000,,,,,,
0x49755d40,,,,Divides to 300885.828125,,
0x4e800000,,systemdomu1_b,,0000321536 to 0000408575,,
0x5f2b5d40,,,,Divides to 389813.828125,,
0x66400000,,sys_ss,,0000418816 to 0000420863,,
0x66406000,,,,,,
0x66c00000,,sys_persist,,0000420864 to 0000437247,,
0x66c06000,,,,,,
0x6ac00000,,sys_irc,,0000437248 to 0000453631,,
0x6ac06000,,,,,,
0x6ec00000,,sys_misc1,,0000453632 to 0000500735,,
0x6ec06000,,,,,,
0x7a400000,,ivi_opt,,0000500736 to 0001063935,,
0x7a406000,,,,,,
0x104000000,,,,Divides to 1064960.0,,
0x104006000,,,,Divides to 1064966.0,,
0x105974000,,,,,,
0x10597a000,,,,,,
0x129474000,,,,Divides to 1217652.0,,
0x12947a000,,,,,,
0x25fc00000,,dtb_a/dtb_b?,,Divides to 2489350,,SWUP? public CA-certificates
0x25fc06000,,,,,,
0x263c00000,,ivi_opt?,,,,Apps? In Vehicle Infotainment
0x263c06000,,,,,,
0x26fc00000,,dtb_a/dtb_b,,Contains only database information,,
0x26fc06000,,,,,,
0x3afc00000,,,,Some database like files,,
0x3afc06000,,,,,,
0x3dfc00000,,,,Some RAM like partition?,,
0x3dfc06000,,,,,,
0x4dfc00000,,,,Contains some docker stuff (no compose,,
0x4dfc06000,,,,,,
0x545400000,,,,Gracenote and some logs,,
0x545406000,,,,,,
0x745400000,,,,Contains only keys,,
0x745406000,,,,,,
1 start end name order comment X0 LR
2 0x3000000 0x191ff000 systemdom0_a 0000012288 to 0000102911
3 0x3006000 ? Not found with mmls. Divides to 12294
4 0x17755d40 ? Not found with mmls. Divides to 96085
5 0x1c800000 0x31bff000 systemdomu1_a 0000116736 to 0000203775
6 0x1c806000 Not found with mmls. Divides to 116742
7 0x2d2b5d40 Not found with mmls. Divides to 185013.828125
8 0x35000000 systemdom0_b 0000217088 to 0000307711
9 0x35006000
10 0x49755d40 Divides to 300885.828125
11 0x4e800000 systemdomu1_b 0000321536 to 0000408575
12 0x5f2b5d40 Divides to 389813.828125
13 0x66400000 sys_ss 0000418816 to 0000420863
14 0x66406000
15 0x66c00000 sys_persist 0000420864 to 0000437247
16 0x66c06000
17 0x6ac00000 sys_irc 0000437248 to 0000453631
18 0x6ac06000
19 0x6ec00000 sys_misc1 0000453632 to 0000500735
20 0x6ec06000
21 0x7a400000 ivi_opt 0000500736 to 0001063935
22 0x7a406000
23 0x104000000 Divides to 1064960.0
24 0x104006000 Divides to 1064966.0
25 0x105974000
26 0x10597a000
27 0x129474000 Divides to 1217652.0
28 0x12947a000
29 0x25fc00000 dtb_a/dtb_b? Divides to 2489350 SWUP? public CA-certificates
30 0x25fc06000
31 0x263c00000 ivi_opt? Apps? In Vehicle Infotainment
32 0x263c06000
33 0x26fc00000 dtb_a/dtb_b Contains only database information
34 0x26fc06000
35 0x3afc00000 Some database like files
36 0x3afc06000
37 0x3dfc00000 Some RAM like partition?
38 0x3dfc06000
39 0x4dfc00000 Contains some docker stuff (no compose
40 0x4dfc06000
41 0x545400000 Gracenote and some logs
42 0x545406000
43 0x745400000 Contains only keys
44 0x745406000

Binary file not shown.