Changes

Jump to navigation Jump to search
511 bytes added ,  18:09, 27 January 2017
no edit summary
Line 1: Line 1:  
[[File:ChainOfTrust.png]]
 
[[File:ChainOfTrust.png]]
   −
The red box is secure world ARM. The green box is non-secure kernel mode ARM. The blue box is non-secure user mode ARM. The yellow is F00D processor. Black arrows indicate trust (A -> B means B trusts A). Green arrows means decryption request (A -> B means A requests decryption from B). Red arrow means executable decryption (A -> B means A decrypts B). THIS IS WRONG AND NEEDS TO BE UPDATED
+
Right and down are less trusted. kernel_boot_loader.self does not itself run on F00D but only contains encrypted segments for ARM to run. Unless indicated otherwise, all processes are encrypted and require F00D to decrypt. This diagram reflects current knowledge and may contain inaccuracies (specifically everything on the F00D side is only a best guess).
    
== Root Chain of Trust ==
 
== Root Chain of Trust ==
   −
ROMs are trusted implicitly. <code>second_loader</code> and <code>secure_kernel</code> are, at update time,  additoinally encrypted (likely with per-console keys). If that is the case, it is likely that the F00D bootrom has the ability to decrypt those two files. It is also predicted that <code>secure_kernel</code> is run on F00D as does <code>second_loader</code> in order to decrypt <code>kernel_boot_loader.self</code> to start the ARM code .
+
The root is F00D's boot rom. This is likely where root keys are seeded and wiped from memory (if we have to guess using knowledge from similar systems). Either second_loader.enp or secure_kernel.enp are loaded from the eMMC (SLB2 partition) although second_loader.enp is the more likely candidate based on name. Both enp files are per-console encrypted (by F00D) during the update process. This is likely in addition (wraps over) to the already encrypted enp from the update file and is to hinder downgrade attacks (by externally flashing a bootloader from another Vita).
 +
 
 +
Curiously, secure_kernel.enp is loaded to DRAM by F00D before ARM secure-world bootloader. However on retail units, its address does not seem to be used. If an address is passed in the boot buffer, then the secure-world bootloader could send the address back to F00D (why?) but attempts to fake this process and attempts to replace the enp with older/newer version have failed.
    
== Decryption Request ==
 
== Decryption Request ==
Line 13: Line 15:  
== Security ==
 
== Security ==
   −
The two bootroms are physically burned into the SoC and cannot be changed. The Cortex A9 bootrom loads the first level bootloader and the F00D bootrom is unknown. Every other component can be changed and most can be revoked. Below, we discuss potential outcomes if there is a hack at each level.
+
Since every decryption happens on F00D and an encrypted revoke list is passed early during startup (in secure world bootloader), it is possible to revoke just about anything on the system. Any hack that can happen before the revoke list is loaded would likely count as a "permanent hack" that cannot be patched without a hardware revision.
    
=== Usermode ===
 
=== Usermode ===

Navigation menu