Difference between revisions of "SCECAF"
Jump to navigation
Jump to search
| (3 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
== SCECAF Container File Structure == | == SCECAF Container File Structure == | ||
| − | Header | + | Structure: |
| − | + | * Header | |
| − | Repeating Section Meta Blocks | + | * Repeating Section Meta Blocks |
| − | + | * Repeating Section Hash Blocks | |
| − | Repeating Section Hash Blocks | + | * Header Hash |
| − | + | * Sections | |
| − | Header Hash | ||
| − | |||
| − | Sections | ||
=== Header === | === Header === | ||
| Line 30: | Line 27: | ||
|- | |- | ||
| 0x28 || 0x8 || Total Sections Size | | 0x28 || 0x8 || Total Sections Size | ||
| − | |||
|- | |- | ||
|} | |} | ||
| Line 53: | Line 49: | ||
|- | |- | ||
| 0x38 || 0x8 || Filler | | 0x38 || 0x8 || Filler | ||
| − | |||
|- | |- | ||
|} | |} | ||
| Line 83: | Line 78: | ||
=== Sections === | === Sections === | ||
| − | Sections are data (normally Gzipped ELF core or CPAD padding) that | + | Sections are data (normally Gzipped ELF core or CPAD padding) that is encrypted. The encryption is AES 128 in CBC mode. The IV comes from the Section Meta Header. The HMAC is the SCE-modified HMAC SHA256. |
| + | The current theory is that the key to use is specified in the Section Meta Header, though since there are no sample that vary (same ID and same key), it is just a guess. | ||
== Kernel Coredump Encrypted ELF == | == Kernel Coredump Encrypted ELF == | ||
| − | On | + | On FW 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. On reboot, the data is encrypted and compressed prior to being wrapped in a SCECAF container. |
=== Process === | === Process === | ||
| − | # The exception handler in the kernel calls SMC 0x122 | + | # The exception handler in the kernel ([[SceExcpmgr]]) calls [[SMC]] 0x122. |
| − | # TrustZone | + | # [[TrustZone]] configures [[Pervasive]] device and [[SceLowio|SceGrab]] device. Need why still? |
# Reset SceDmac5Reg Device | # Reset SceDmac5Reg Device | ||
| − | # Create a SceCrashDumpHeader at PA 0x58000000 on retail and 0x60000000 on | + | # Create a SceCrashDumpHeader at PA 0x58000000 on retail and 0x60000000 on DevKit (maybe only in DevKit Memory Size mode) |
# Map SceCrashDumpZero to start of DRAM at PA 0x40000000 | # 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 VRAM at PA 0x20000000 in 0x1000 byte chunks | ||
# Configure SceDmac5Reg and loop through all of DRAM at PA 0x40200000 in 0x10000 byte chunks | # Configure SceDmac5Reg and loop through all of DRAM at PA 0x40200000 in 0x10000 byte chunks | ||
| − | # Call SMC 0x11A to | + | # Call [[SMC]] 0x11A to initiate a reboot in requested coredump mode |
| − | # Upon reboot, coredump handler will create a SCECAF container of the data | + | # Upon reboot, coredump handler ([[SceCrashDump]]) will create a SCECAF container of the data from PA 0x58000000 or 0x60000000 |
| + | |||
| + | [[Category:Formats]] | ||
Latest revision as of 22:13, 1 May 2023
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
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 is encrypted. The encryption is AES 128 in CBC mode. The IV comes from the Section Meta Header. The HMAC is the SCE-modified HMAC SHA256.
The current theory is that the key to use is specified in the Section Meta Header, though since there are no sample that vary (same ID and same key), it is just a guess.
Kernel Coredump Encrypted ELF
On FW 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. On reboot, the data is encrypted and compressed prior to being wrapped in a SCECAF container.
Process
- The exception handler in the kernel (SceExcpmgr) calls SMC 0x122.
- 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 (maybe only in DevKit Memory Size mode)
- 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 initiate a reboot in requested coredump mode
- Upon reboot, coredump handler (SceCrashDump) will create a SCECAF container of the data from PA 0x58000000 or 0x60000000