Adding gitlab pages

This commit is contained in:
Jonathan Herrewijnen 2024-08-20 17:28:57 +02:00
parent 5154096998
commit 34ca995109
3 changed files with 25 additions and 10 deletions

22
.gitlab-ci.yml Normal file
View File

@ -0,0 +1,22 @@
variables:
http_proxy: http://outboundproxy.jubit2.minvenj.nl:8080
https_proxy: http://outboundproxy.jubit2.minvenj.nl:8080
no_proxy: git.eminjenv.nl
image: python:3.8
pages:
stage: deploy
script:
- mkdir .public
- python -m venv venv
- source venv/bin/activate
- pip install -r <(head -n -1 requirements.txt)
- documentation/make html
- cp -r documentation/build/* .public
- mv .public public
artifacts:
paths:
- public
only:
- main

View File

@ -45,14 +45,12 @@ BL31
Example of BL31 using debugger memory. Example of BL31 using debugger memory.
BL31 also configures the VBAR_EL3 and MMU so the memory mapping will probably change after this stage. BL31 also configures the VBAR_EL3 and MMU so the memory mapping will probably change after this stage (preparation for trustzone?).
It would be nice to patch BL31 before it is being executed. However the current exploit boot flow does not allow this because the ROM function downloads the next stage. It would be nice to patch BL31 before it is being executed. However the current exploit boot flow does not allow this because the ROM function downloads the next stage.
Notes Notes
----- -----
As done by Frederic, the bootrom can be dumped using his provided scripts, and can the be split into different boots: As done by Frederic, the bootrom can be dumped using his provided scripts, and can the be split into different boots:
.. code-block:: bash .. code-block:: bash
@ -85,7 +83,6 @@ After loading the stage1 (entry.S - Frederic's exploit), we're allowed to send c
debugger debugger
-------- --------
The initial debugger is written to ``0x2069000``, with debugger_stack and _storage at ``0x0206b000`` and ``0x0206d000`` respectively. The initial debugger is written to ``0x2069000``, with debugger_stack and _storage at ``0x0206b000`` and ``0x0206d000`` respectively.
After the initial loading of the debugger, the processor state reported is (using ghidra assistant): After the initial loading of the debugger, the processor state reported is (using ghidra assistant):
@ -130,9 +127,8 @@ The processor state reported then is:
X21 : 0x0 | X22 : 0x0 | X23 : 0x0 | X24 : 0x0 | X25 : 0x0 | X26 : 0x0 | X27 : 0x1 | X21 : 0x0 | X22 : 0x0 | X23 : 0x0 | X24 : 0x0 | X25 : 0x0 | X26 : 0x0 | X27 : 0x1 |
X28 : 0x0 | X29 : 0x2020f00 | LR/X30 : 0x20c0000 | SP/X31 : 0x2020ef0 X28 : 0x0 | X29 : 0x2020f00 | LR/X30 : 0x20c0000 | SP/X31 : 0x2020ef0
bl1 Initial boot function
--- ---
.. figure:: images/initial_boot_function.png .. figure:: images/initial_boot_function.png
:align: center :align: center
@ -291,7 +287,3 @@ bl1 interacts with several pheriperals, from the DTB these are:
Probably the only thing it does is set some clocks and prepare for BL31 Probably the only thing it does is set some clocks and prepare for BL31
BL31
----
Setups EL3 stuff, probably in preperation of loading trustzone

View File

@ -11,4 +11,5 @@ tqdm
pyhidra pyhidra
sphinxcontrib.confluencebuilder sphinxcontrib.confluencebuilder
sphinxcontrib.drawio sphinxcontrib.drawio
sphinx_wagtail_theme
source/ghidra_assistant/ghidra_assistant-0.0.1-py3-none-any.whl source/ghidra_assistant/ghidra_assistant-0.0.1-py3-none-any.whl