Back in October
Fail0verflow released their
Adieu PS4 Kernel Exploit for 4.05 OFW, and since
SpecterDev's Follow-up they've now shared documentation on PlayStation 4 crashdumps and dumping a PS4 kernel in "only" 6 days for other scene developers to learn from.
Previously we also saw PS4 Developer
Flat_z Bid PS4 Crash Dumps Good Bye using conventional means thanks to Sony patching the existing holes.
To quote from their latest
Blog Entry:
Crashdumps on PS4
The crash handling infrastructure of the ps4 kernel is interesting for 2 main reasons:
- It is ps4-specific code (likely to be buggy)
- If the crashdump can be decoded, we will gain very useful info for finding bugs and creating reliable exploits
On a normal FreeBSD system, a kernel panic will create a dump by calling kern_reboot with the RB_DUMP flag. This then leads to doadump being called, which will dump a rather tiny amount of information about the kernel image itself to some storage device.
On ps4, the replacement for doadump is mdbg_run_dump, which can be called from panic or directly from trap_fatal. The amount of information stored into the dump is gigantic by comparison - kernel state for all process, thread, and vm objects are included, along with some metadata about loaded libraries. Other obvious changes from the vanilla FreeBSD method are that the mdbg_run_dump encodes data recorded into the dump on a field-by-field basis and additionally encrypts the resulting buffer before finally storing it to disk.
Dumping Anything
Let’s zoom in to a special part of mdbg_run_dump - where it iterates over all process’ threads and tries to dump some pthread state:
Code:
void mdbg_run_dump(struct trapframe *frame) {
// ...
for ( p = allproc; p != NULL; p = cur_proc->p_list.le_next ) {
// ...
for (td = p->p_threads.tqh_first; td != NULL; td = td->td_plist.tqe_next) {
// ...
mdbg_pthread_fill_thrinfo2(&dumpstate, td->td_proc,
(void...