Kao the Kangaroo (PPSA05595)

[JJenkx]

Existing thread

• I searched this category for PPSA05595 and "Kao the Kangaroo"; no thread exists.

Title

Kao the Kangaroo (PPSA05595)

Content version tested

The extraction's eboot.bin, with PlayGo files present.

AnyPS5 commit

main 474030e584, with no extra PRs.

System tested

Linux 7.2.11 (Arch), Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.6, GCC, Release.

Furthest point

Boot screens: a bright first screen at 25 s, then a black screen at 60 s.

What is shown

Cross every 12 s from 30 s. The title runs at about 38 FPS, drops to about 5 FPS after the Cross press at 66 s, and then ends with SIGSEGV at about 75 s, exit 139. There is no AnyPS5 error before it, only the usual vkAllocateMemory (-1000072003) host-import fallbacks.

Current blocker

A crash in guest code. Under gdb with the same inputs, it is SEGV_MAPERR at address 0 on a game thread, with PC 0x2bac088 in eboot.elf. The code there is an array insert: a memmove call at 0x2bac07f, then mov (%r15),%rax and a store to (%rax,%rbx,4). The array's data pointer is null, which suggests that an earlier guest allocation returned null or failed. I haven't traced which one.

How it was run

relinker --registry --rpath <build>/core/libs/libs eboot.elf app.elf
APS5_PLAYGO_UNLISTED_CHUNKS=installed ./app.elf

AI-assisted testing and report: yes.

[JJenkx]

More on the crash site in eboot.elf (01.007.000): it is a sorted insert into an Unreal TArray held at offset 0xd0 of an object. The data pointer is at +0xd0, the count at +0xd8 and the capacity at +0xdc.

2bac040: lea    0x1(%r12),%eax        ; count + 1
2bac045: lea    0xd0(%rdi),%r15       ; &array
2bac04c: mov    %eax,0xd8(%rdi)
2bac052: cmp    0xdc(%rdi),%r12d      ; full?
2bac059: jl     2bac069
2bac061: call   0x2be2750             ; grow (reallocate)
2bac066: mov    (%r15),%r8            ; reload data
...
2bac07f: call   0x5369ff0             ; memmove to make room
2bac084: mov    (%r15),%rax           ; data
2bac092: mov    %ecx,(%rax,%rbx,4)    ; store -> SIGSEGV at address 0

So the data pointer is null after the grow path. Either the reallocation returned null, or the object's array header was already invalid: for example a garbage count asking for an impossible size, or the object not yet constructed. AnyPS5 logs no allocation failure before the crash, so I can't tell which from this run. The next step is to break at 0x2bac061 and 0x2bac084 and read 0xd0 to 0xdc of the object, plus the grow call's size.

AI-assisted analysis: yes.

[JJenkx]

A gdb run on the same main with the same inputs. At the fault, the array header is inconsistent rather than null:

rip 0x2bac085, rbx 0, r12 0x20
r15 = 0x7ce9070  (object 0x7ce8fa0 + 0xd0, static data in eboot.elf)
0x7ce9070: data 0x00000000074b5810, count 0x00000096 (150), capacity 0x00000004

The count, 150, is larger than the capacity, 4, so this is not an allocation that returned null. The array of a static object was already corrupt when the insert ran. The likeliest causes are concurrent modification of this global array, for example two threads inserting while a lock that should exclude them does not, or a stray write from elsewhere. I have not identified which. A useful next step is a hardware watchpoint on 0x7ce9078, the count, recording each writer thread.

AI-assisted analysis: yes.

[JJenkx]

A correction to my last comment. A hardware watchpoint on 0x7ce9078 over a whole run shows only two writes, both on thread 1:

• -1 at 0x2bf4ded during startup;
• one store at 0x1fa38e6 that sets the values I printed (data 0x74b5810, then 150 and 4).

Nothing writes it afterwards. So it is not modified concurrently, and my reading of +0xdc as a capacity, with count above capacity meaning corruption, was wrong. The layout there is not a plain TArray header.

This run also faulted at a different place, 0x2a02344 on thread 6. So the crash site varies between runs, and I do not yet have a consistent first bad access. I am stopping on this title here.

AI-assisted analysis: yes.