Changes

Jump to navigation Jump to search
3,198 bytes added ,  21:08, 5 August 2019
no edit summary
Line 186: Line 186:  
=== Syscall handler doesn't check syscall number (integer overflow) ===
 
=== Syscall handler doesn't check syscall number (integer overflow) ===
   −
Discovered on 2015-07-03 by Molecule Team. Implemented in Mathieulh's early PSVita FW exploit chain.
+
Discovered on 2015-07-03 by Molecule Team.
    
A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.
 
A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.
Line 485: Line 485:     
(2018-07-27) jebaited, not an exploit. Just [https://github.com/TeamMolecule/petite-mort tools used to glitch bootrom].
 
(2018-07-27) jebaited, not an exploit. Just [https://github.com/TeamMolecule/petite-mort tools used to glitch bootrom].
 +
 +
=== F00D exception vectors reused as SLSK load buffer ===
 +
 +
(2018-07-27) When an [[Enc]] is loaded by the bootrom, it is first read to <code>0x40000</code> which is the uncached alias of <code>0x800000</code> (both are F00D-only private memory) and then later decrypted to the final address it is executed from. However, <code>0x40000</code> is also where the exception vectors lie. By the time the SLSK is read, the exception vectors are stale and therefore the memory is safe to reuse. Interrupts are disabled, so we cannot use those. Exceptions, however cannot be disabled in hardware. Unfortunately, there is no way to trigger any exception from bootrom code (which is why Sony thought it would be safe to re-use the buffer). Below is a summary of all the exceptions and why they are not possible.
 +
 +
{| class="wikitable"
 +
! Exception
 +
! Offset
 +
! Reason
 +
|-
 +
| Reset
 +
| 0x0
 +
| Requires hardware reset signal
 +
|-
 +
| NMI
 +
| 0x4
 +
| Requires hardware NMI signal
 +
|-
 +
| RI
 +
| 0x8
 +
| No reserved instructions used
 +
|-
 +
| ZDIV
 +
| 0xC
 +
| DIV/DIVU instructions not used
 +
|-
 +
| BRK
 +
| 0x10
 +
| BRK instruction not used
 +
|-
 +
| SWI
 +
| 0x14
 +
| SWI/STC instructions not used
 +
|-
 +
| DSP
 +
| 0x18
 +
| No DSP unit
 +
|-
 +
| COP
 +
| 0x1C
 +
| No coprocessor unit
 +
|}
 +
 +
However, through [[Glitching]], we can inject a fault in either the decoding or execution units of the processor and trigger one of these exceptions. By writing a fake ENC file that actually masquerades as a F00D exception handler table that all points to our payload, we can execute F00D code at bootrom time (before bootrom is unmapped). This is a very desirable glitching target because it almost requires no precision (any instruction anywhere can be "corrupted" into something that triggers an exception) and allows for "spray and pray" style of glitch attacks. In practice, we found this target to have an insanely high success rate.
 +
 +
In the bootrom there are two SLSK load paths. The first one is used at initial boot to read [[Second Loader]] from the eMMC. In this path, the minimum payload size is 0x200 bytes because at most 1 eMMC block must be read. The second path is used in early boot to read the [[Secure Kernel]] ENC which is loaded from the [[SLB2]] partition by ARM TZ processor to volatile memory. This second path is more difficult to reach because it requires a handshake between F00D ("you are allowed to reset me") and ARM TZ ("I am going to reset F00D"). However, as long as both F00D and ARM TZ are pwned post-boot, the second path can be triggered.
 +
 +
The advantage of the first path is that it is easier and faster to trigger (always hits on first boot). The disadvantages are that it corrupts the first 0x200 bytes of F00D memory (which we might want to dump) and that it requires "bricking" the device (because second loader is replaced by our payload). Note that with a proper hardware flasher and a backup beforehand, it is possible to unbrick a corrupted second loader.
 +
 +
The advantage of the second path is that it does not require a hardware flasher and that it only corrupts 0x40 bytes of F00D memory. The disadvantage is that it requires more work to trigger (code execution both in ARM TZ and F00D) and it takes longer to trigger (since you have to boot the system to a point where you can pwn F00D and ARM TZ).
    
=== moth exploit ===
 
=== moth exploit ===

Navigation menu