SCECAF File Format: Difference between revisions

From Vita Developer wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
[[Category:Software]]<noinclude>[[Category:Main]]</noinclude>
[[Category:Software]]<noinclude>[[Category:Main]]</noinclude>
Files from coredumps or crash reports are in SCECAF format when encrypted. The file names will be either crash_report.caf or a coredump with a filetype of .spsp2dmp. All data is in little endian format.


= File Format  =
== SCECAF Container File Structure ==
/*Needs Documentation*/
Files [http://f.lui.li/get_3366_2bba.html here]


Similar to PUP file.
Header


Structure (highly speculative) is as follows (most parts are byteswapped):
Repeating Section Meta Blocks


== Structure ==
Repeating Section Hash Blocks


The file starts with a global header :
Header Hash
 
Sections
 
=== Header ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Offset !! Length !! Type !! Information !! Example
! Offset !! Size !! Description
|-
|-
| 0x0 || 0x8 || unsigned long || Magic || ("SCECAF")
| 0x0 || 0x8 || <code>0x5343454341460000</code> magic SCECAF\0\0
|-
|-
| 0x8 || 0x8 || unsigned long || Package Version || (0x02)
| 0x8 || 0x8 || Type/Version? (always 2)
|-
|-
| 0x10 || 0x8 || unsigned long || Image Version || (0x01)
| 0x10 || 0x8 || HMAC Key ID (always 1)
|-
|-
| 0x18 || 0x8 || unsigned long || Files Count || (0x01)
| 0x18 || 0x8 || Number of sections
|-
|-
| 0x20 || 0x8 || unsigned long || Header Length || (0xC0)
| 0x20 || 0x8 || Size of Header
|-
|-
| 0x28 || 0x8 || unsigned long || Package Length || (0x40)
| 0x28 || 0x8 || Total Sections Size
 
|-
|-
|}
|}


Entries are then described as follows (There are as many entries as there are files) :
=== Section Meta Block ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Offset !! Length !! Type !! Information !! Example
! Offset !! Size !! Description
|-
|-
| 0x0 || 0x8 || unsigned long || Entry ID || (0x0)
| 0x0 || 0x8 || Section ID (starts with 0)
|-
|-
| 0x8 || 0x8 || unsigned long || Data offset || (0xC0)
| 0x8 || 0x8 || Section Start Offset
|-
|-
| 0x10 || 0x8 || unsigned long || Data length || (0x40)
| 0x10 || 0x8 || Section Length
|-
|-
| 0x18 || 0x8 || unsigned long || Unknown || (0x01)
| 0x18 || 0x8 || HMAC Key ID (Always 1)
|-
|-
| 0x20 || 0x8 || unsigned long || Unknown|| (0x02)
| 0x20 || 0x8 || Encryption Key ID (Always 2)
|-
|-
| 0x28 || 0x10 || u8[16] || IV || Random IV
| 0x28 || 0x10 || Encryption IV
|-
|-
| 0x30 || 0x8 || unsigned long || Padding|| (0x0)
| 0x38 || 0x8 || Filler
 
|-
|-
|}
|}


Then follows SHA-256 hashes. They probably are salted hashes of the entry headers.
=== Section Hash Block ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Offset !! Length !! Type !! Information !! Example
! Offset !! Size !! Description
|-
|-
| 0x0 || 0x8 || unsigned long || Entry ID || (0x0)
| 0x0 || 0x8 || Section ID (starts with 0)
|-
|-
| 0x8 || 0x20 || u8[32] || SHA-256 Sum || sha256sum
| 0x8 || 0x20 || HMAC Hash
|-
|-
| 0x28 || 0x8 || unsigned long || Padding || (0x0)
| 0x28 || 0x8 || Filler
|-
|-
|}
|}


Files data follows. The data is encrypted (using AES-128-CBC ?). Entries are as follows :
=== Header Hash Block ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Offset !! Length !! Type !! Information !! Example
! Offset !! Size !! Description
|-
| 0x0 || 0x20 || u8[32] || SHA-256 Sum || sha256sum
|-
|-
| 0x20 || Variable ||  || Encrypted file data ||  
| 0x0 || 0x20 || HMAC Hash
|-
|-
|}
|}


=== Sections ===


= Location =
Sections are data (normally Gzipped ELF core or CPAD padding) that are encrypted. The encryption is AES 128 in CBC. The IV comes from the Section Meta Header and the key is one of the 4 keys listed in the [[Keys#Coredump_Keys]] page for Coredumps. The HMAC is the SCE-Modified HMAC SHA256. The HMAC Key is one of the 3 listed on the [[Keys#Coredump_Keys]] page as well. The current theory is which key is specified in the section meta header, though since there are no sample that vary, it is just a guess.
 
SCECAF files are used for coredump files. They can be found in ux0:data.
 
Example :
 
ux0:data/crash_report.caf


ux0:data/psp2core-SceVideoPlayer.spsp2dmp


== Kernel Coredump Encrypted ELF ==


== crash_report.caf ==
On firmwares 2.12 and greater, a SceKernelProcess coredump can be created when a critical error (such as a DABT or PABT) occurs in a syscall or kernel thread. The data is encrypted and compressed prior to being wrapped in the SCECAF container.  


=== Process ===


== psp2core-*.spsp2dmp ==
# The exception handler in the kernel calls SMC 0x122 with the arguments (Error type, TTBR0, VBAR, SysRoot VA)
# TrustZone Configures Pervasive Device and SceGrab device - need why still
# Reset SceDmac5Reg Device
# Create a SceCrashDumpHeader at PA 0x58000000 on retail and 0x60000000 on devkit
# Map SceCrashDumpZero to start of DRAM at PA 0x40000000
# Configure SceDmac5Reg and loop through all of VRAM at PA 0x20000000 in 0x1000 byte chunks
# Configure SceDmac5Reg and loop through all of DRAM at PA 0x40200000 in 0x10000 byte chunks
# Call SMC 0x11A to initial a reboot in requested coredump mode
# Upon reboot, coredump handler will create a SCECAF container of the data in 0x58000000 or 0x60000000

Revision as of 22:22, 2 November 2016

Files from coredumps or crash reports are in SCECAF format when encrypted. The file names will be either crash_report.caf or a coredump with a filetype of .spsp2dmp. All data is in little endian format.

SCECAF Container File Structure

Header

Repeating Section Meta Blocks

Repeating Section Hash Blocks

Header Hash

Sections

Header

Offset Size Description
0x0 0x8 0x5343454341460000 magic SCECAF\0\0
0x8 0x8 Type/Version? (always 2)
0x10 0x8 HMAC Key ID (always 1)
0x18 0x8 Number of sections
0x20 0x8 Size of Header
0x28 0x8 Total Sections Size

Section Meta Block

Offset Size Description
0x0 0x8 Section ID (starts with 0)
0x8 0x8 Section Start Offset
0x10 0x8 Section Length
0x18 0x8 HMAC Key ID (Always 1)
0x20 0x8 Encryption Key ID (Always 2)
0x28 0x10 Encryption IV
0x38 0x8 Filler

Section Hash Block

Offset Size Description
0x0 0x8 Section ID (starts with 0)
0x8 0x20 HMAC Hash
0x28 0x8 Filler

Header Hash Block

Offset Size Description
0x0 0x20 HMAC Hash

Sections

Sections are data (normally Gzipped ELF core or CPAD padding) that are encrypted. The encryption is AES 128 in CBC. The IV comes from the Section Meta Header and the key is one of the 4 keys listed in the Keys#Coredump_Keys page for Coredumps. The HMAC is the SCE-Modified HMAC SHA256. The HMAC Key is one of the 3 listed on the Keys#Coredump_Keys page as well. The current theory is which key is specified in the section meta header, though since there are no sample that vary, it is just a guess.


Kernel Coredump Encrypted ELF

On firmwares 2.12 and greater, a SceKernelProcess coredump can be created when a critical error (such as a DABT or PABT) occurs in a syscall or kernel thread. The data is encrypted and compressed prior to being wrapped in the SCECAF container.

Process

  1. The exception handler in the kernel calls SMC 0x122 with the arguments (Error type, TTBR0, VBAR, SysRoot VA)
  2. TrustZone Configures Pervasive Device and SceGrab device - need why still
  3. Reset SceDmac5Reg Device
  4. Create a SceCrashDumpHeader at PA 0x58000000 on retail and 0x60000000 on devkit
  5. Map SceCrashDumpZero to start of DRAM at PA 0x40000000
  6. Configure SceDmac5Reg and loop through all of VRAM at PA 0x20000000 in 0x1000 byte chunks
  7. Configure SceDmac5Reg and loop through all of DRAM at PA 0x40200000 in 0x10000 byte chunks
  8. Call SMC 0x11A to initial a reboot in requested coredump mode
  9. Upon reboot, coredump handler will create a SCECAF container of the data in 0x58000000 or 0x60000000
Retrieved from "http://www.psdevwiki.com/vita/index.php?title=SCECAF_File_Format&oldid=4982"