docs update on mobicore, xen and kinibi

documentation/source/BootROM_8890/04_xen_and_mib3.rst

@@ -64,9 +64,7 @@ TFFS is a proprietary file system from Tuxera, with one mounter available `tffsm
     cd initramfsdom0_a
     cpio -idmv < initramfsdom0_a.bin
 
-Alternative approach (not working for partitions within the IVI).
+Alternative approach (not working for partitions within the IVI). ``python3 -m tffsmount 32gb.bin /tmp/mib3/tffsmount2 -o 0x1be00000``
-
-``python3 -m tffsmount 32gb.bin /tmp/mib3/tffsmount2 -o 0x1be00000``
 
 .. code:: bash
 
@@ -117,21 +115,57 @@ Alternative approach (not working for partitions within the IVI).
     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. 
+The initramfs partitions contain the initial ramdisk, which is a cpio archive. The contents of the initramfs can be extracted using the following command:
 
-Domain0 and DomainU
+XEN, 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."
+Virtual machines are essentially guest operating systems running on a device. Virtual machines share physical memory and can share hardware devices, creating security risks, allowing potential VM excapes. A mitigation is to have all hardware access isolated in a trusted execute environment (TEE), or in our case, this might already be the Domain0. The resources of the CPU and other peripherals are shared between the VMs, with the hypervisor managing the resources. In our case, Domain0 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 likely also has access to the hardware resources.
 
-Data can be shared between domains using XenStore - an information storage space between domains maintained by Xenstored. 
+    *"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."*
 
-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. 
+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. ""
+    *"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.
+MCLF, MobiCore or Trustonic
+---------------------------
+Looking through ``systemdom0_a`` at ``3000000``, we find three 'tabin' files with some hash as a filename, and ``MCLF`` in the header. These are likely trusted applets, running in the secure world. MCLF format (source: quarkslab0 and `kinibi` OS).
+
+.. figure:: images/mclf_format.png
+   :alt: MCLF header
+   :align: center
+
+These files contain a MCLF header when viewing the file header. MCLF is a Mobicore Loadable Format
+
+.. code:: bash
+
+    ➜  gradle-8.11 cd /tmp/mib3/tffsmount/3000000/opt/tee/ta 
+    ➜  ta ls
+    22546a5c7c8658b2b9159ca48a7f9272.tabin  2c0ba9cc522252ddaf45af9a79eab69f.tabin  c4ad25cde4205d90ae7642155cd60556.tabin
+
+Quarkslab on MCLF: `A Deep Dive Into Samsung's TrustZone (Part 1) <https://blog.quarkslab.com/a-deep-dive-into-samsungs-trustzone-part-1.html>` and `A Deep Dive Into Samsung's TrustZone (Part 2) <https://blog.quarkslab.com/a-deep-dive-into-samsungs-trustzone-part-2.html>`.
+
+Trusted applets
+^^^^^^^^^^^^^^^
+Communication between secure and normal world are done using software interrupts and 'World Shared Memory' buffers. These WSM allow transfer of data. A ``MCLib`` - Mobicore Library - is used to communicate between trustlets. In our case: libMcClient.so, located at ``usr/lib/libMcClient.so``, which in turn communicates with a daemon: ``usr/bin/mcDriverDaemon`` (in systemdom0).
+
+    *"This library is not loaded dynamically by the trustlets. The address of the McLib's handler is written into them at load time and then used as a regular function as shown in the code snippet given below. The tlApi number is passed into R0 and the arguments in the rest of the general purpose registers or on the stack, depending on the number of arguments.""*
+
+This MobiCore library is loaded at runtime. The trustlet command handlers provide an attack surface for higher privileged processes. Secure drivers are another type of applets, with higher privileges and access to hardware and additional Supervisor Calls (SVC). They are typically multithreaded, into a main, a normal world handler, a system/trustlet handler and an ISR thread handler.
+
+.. figure:: images/trusted_app_mobicore_worldshares.png
+    :alt: Mobicore world shares
+    :align: center
+
+Direct communication with a secure world driver is possible from the nowrmal world, using the shared buffer between both worlds, which passes the arguments for the secure world driver. The secure world driver can then access the hardware directly.
+
+Kibini
+^^^^^^
+Kibini is part of SBoot, and is probably extracteable 
+
+Wahrheit
 
 XEN logs
 ^^^^^^^^^^

documentation/source/index.rst

@@ -14,4 +14,5 @@ Documentation on Samsung devices, currently mainly the Samsung S7. Here we're ex
    BootROM_8890/01_start.rst
    BootROM_8890/02_frederics_exploit.rst
    BootROM_8890/03_exploit_boot_chain.rst
-   BootROM_8890/04_notes.rst
+   BootROM_8890/04_xen_and_mib3.rst
+   BootROM_8890/05_notes.rst