Small docs update

documentation/source/BootROM_8890/boot_chain.rst

@@ -183,7 +183,7 @@ After authentication the bootROM jumps to this function at, we can execute this
 
     jump_fwbl1()
 
-BL1 is loaded at the download buffer and self copies to ``0x02022000`` and resumes execution there (``0x02024010``), with a size of 0x2000 (0x02022000 to 0x02024000).
+BL1 is loaded at the download buffer and self copies to ``0x02022000`` and resumes execution there, with a size of 0x2000 (``0x02022000`` to ``0x02024000``).
 
 However, this does not result in a jump back to the debugger. But the ROM still allows receival of one data package from the USB host (this is likely the system 'waiting' to receive the bootloader). 
 
@@ -249,12 +249,10 @@ Probably the only thing it does is set some clocks and prepare for BL31.
 
 BL31
 ----
-
+BL31 is written at ``0x02024000`` with the entry point at ``0x02024010``. 
-BL31 is written at 0x02024000 with the entry point at 0x02024010. 
 
 BL2
 ---
-
 0x02e8dc mentions 'Onyx-OPR6-8511R1', which is likely sboot. 
 
 OLD

documentation/source/BootROM_8890/index.rst

@@ -1,21 +1,18 @@
 ===================
 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. There is however an SMC and a MMU. The SMC is used to communicate with the secure world, and the MMU is used to map the memory.
-There are no stack canaries or guard pages, and no ASLR. Meaning there are almost no protections in place.
 
 Rom is at address 0x0 and is unwritable (Sometimes this is writeable due to MMU caching).
 
 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.
 
@@ -49,7 +46,6 @@ TODO make memory layout of ROM, IMEM and some devices @JONHE
 
 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.
@@ -199,12 +195,10 @@ There is a bug(unpatched?) in receiving the last packet of the usb 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.
 

documentation/source/BootROM_8890/notes.rst

@@ -14,3 +14,9 @@ What is interesting about the ROM is that it starts by checking MPIDR_EL1 regist
         0000000c 41 00 00 54     b.ne       LAB_00000014
         00000010 fc 7f 83 14     b          LAB_020e0000
 
+
+Week 35 - 2024
+===============
+After booting BL31, the MMU seems to be set up, and we're unable to do get any data off of spaces we're not 'allowed' to access. Interestingly, one of the setups is at 
+
+Patching the if-statement at 0x020244e8, and in doing so, disabling this function. 

documentation/source/_ignore/draw_boot.ipynb

@@ -2629,7 +2629,7 @@
    "outputs": [],
    "source": [
     "# Save to html\n",
-    "fig.write_html(\"stack_and_functions.html\")"
+    "fig.write_html(\"../_static/stack_and_functions.html\")"
    ]
   }
  ],

documentation/source/index.rst

@@ -13,6 +13,6 @@ Documentation on Samsung devices, currently mainly the Samsung S7.
 
    BootROM_8890/index.rst
    BootROM_8890/boot_chain.rst
-
+   BootROM_8890/notes.rst
 
 

source/exploit/exploit.py

@@ -725,10 +725,22 @@ class ExynosDevice():
         
         # Jump BL31
         self.cd.arch_dbg.state.LR = DEBUGGER_ADDR
-        self.cd.memwrite_region(0x20219b8, p32(DEBUGGER_ADDR))
+        # self.cd.memwrite_region(0x20219b8, p32(DEBUGGER_ADDR))
         # self.cd.restore_stack_and_jump(hijacked_fun)
 
-        # Write 'a1 00 00 00' to 0x0202a330
+        # Write 0's to 0x11600
+
+        # Inspect TTBR0_EL3 table
+        TTBR0_EL3 = 0x02035600 # Zeroed
+        
+        # Overwrite 02028b0c from 5f5820f8 to d503201f -> Doesn't seem to be doing anything
+        # self.cd.memwrite_region(0x02028b0c, struct.pack('>I', 0xd503201f))
+        # Same at 02028b8c
+        # self.cd.memwrite_region(0x02028b8c, struct.pack('>I', 0xd503201f))
+
+        # Modifies setting up MMU (but is set up eventually)
+        # self.cd.memwrite_region(0x020244e8, struct.pack('>I', 0x1f0c00f1)) # Change check to always false
+        # self.cd.memwrite_region(0x020244fc, b'\00'*8) # Change check to always false
         
         self.cd.restore_stack_and_jump(0x02024010)
         
@@ -736,7 +748,9 @@ class ExynosDevice():
         self.connect_device()
         
         self.usb_read(0x200) # GiAs 
-        self.cd.arch_dbg.fetch_special_regs()
+        regs = self.cd.arch_dbg.fetch_special_regs()
+        # print status of MMU 
+        print(f'MMU is {hex(self.cd.arch_dbg.state.R_SCTLR_EL3.mmu)} (1=enabled, 0=disabled)')
 
         BL31_ra = self.cd.arch_dbg.state.LR
 
@@ -805,6 +819,3 @@ if __name__ == "__main__":
     exynos.dumb_interact()
         
     sys.exit(0)
-
-
-with open()