Shine Spawn Cutscene Underflow ACE

By starting a Shine Get cutscene while another cutscene is playing, the game will terminate more cutscenes than it started, resulting in previous cutscenes (or garbage data) being played before the savebox. I call this glitch Cutscene Underflow. More info (read the description): https://www.youtube.com/watch?v=xhUd0e0Sgwo

What if you replay a cutscene in a different area than it was originally played? For most cutscenes, nothing interesting happens: either they play normally, or they end instantly, depending on whether the associated camera movement filename was overwritten in the transition or not. But some cutscenes retain a callback to execute before and after the cutscene (even if the camera movement couldn’t be found), and a pointer to a relevant object to be passed to the callback. Most notably, Shine spawns keep a pointer to the Shine being spawned.

There are limitations to cross-area cutscene underflow: FMVs and episode selections will overwrite all cutscene slots with data from the disc, which has a very low chance of leading to anything but a crash. That means the plaza is basically the only usable target for this. Additionally, since the cutscene count will reset to 0 on any area transition, and it takes at least 2 cutscenes to trigger cutscene underflow, the Shine needs to be spawned after at least 2 other cutscenes, and Shine spawns that can't fit this criterion (e.g. Pinna 1 as it spawns too fast after you enter the area) cannot be used.

At the beginning of a Shine spawn cutscene, its callback will lead to one of the Shine’s virtual functions, TMapObjBase::makeObjAppeared, being called. When replaying the cutscene with cross-area cutscene underflow, its Shine pointer will be stale and the virtual call can be redirected to arbitrary code. Let S be the Shine pointer; *S will be read as a pointer to the Shine’s virtual table, and *(*S + 0x100) will be set as the instruction pointer. The conditions to make this ACE happen in the game are yet to be determined, with 426 different Shine addresses being identified as usable for this, but some things can already be said about the payload.

Context:
- r0 contains the return address of TMapObjGeneral::appear (read-only; PAL:801b5004)
- r3, r30 and r31 contain the Shine pointer;
- r4 contains the word at offset 0x18c from the Shine pointer;
- r5, r6, r7, r27, r28 and r29 contain 0xFFFFFFFF;
- r8, r19, r23 contain 4;
- r9 contains the horizontal camera angle;
- r12 contains the address of the payload;
- r14, r15, r16, r17, r18, r21, r24 and r25 contain 0;
- r20 contains gpApplication + 0x2c (very useful for setting the next area or FMV);
- r26 contains gpMarDirector.

Preventing a crash in the rest of the callback: the Shine spawn callback does a couple more things after the payload runs, still assuming that it’s dealing with a TShine instance.
- `blr`: unsafe, requires other fields to be valid pointers
- branch to the end of TMapObjGeneral::appear (PAL:801abfb8): safer, might only require certain floats to not be NaN or infinite?
- `addi sp,sp,0x28` then branch to the end of TShine::appearWithTime (PAL:801b51d4): very safe, barely any side effects

Preventing a crash if not all cutscene slots are filled: `stb r14, 0x24d(r26)` will reset the cutscenes ended index to 0, skipping the later slots.