|
==Technical information==
When viewing the party screen or the move screen, the game displays small Pokémon icons and animates them based on their current hit point values and status. While it is doing this, the game stores the animation data in a structure starting from address $C51C, which lies right beyond the end of screen tile data at $C508. The game can store and animate up to 10 sprites this way. In particular, the move screen only has a single animated sprite (the current Pokémon's icon in the top left of the screen).
WhenAn viewingimportant the listfield of moves, the gameanimation placesdata structure is the current''animation Pokémontype's', iconstored in theaddress top$C51E left(wSpriteAnim1AnimSeqID) offor the screenfirst andanimated animates it, storing the current animation type in address $C51Esprite. This is used to index a jump table that is used to control the behavior of the animation. By overwriting this address with an invalid value, we can index this table out of bounds, potentially triggering arbitrary code executionACE.
TypeThe glitch type 0xD0 's (the type of move 0x00) can overwrite $C51E by overflowing the tile data when its name is susceptibleprinted toon VRAMthe accessibilitymove screen, if said name is long enough. SinceThe source of the type name is read0x8350 fromin VRAM, hence affected by what is or was displayed on the screen; in particular, the party screen may affect 0x8350 if you have enough Pokémon menu sprites and/or held items in the party{{fact}}. This also means that the name is susceptible to VRAM accessibility: if the game attempts to read a character while VRAM is inaccessible it will read value $FF and print a '9' instead of the expected character. This means that the effects of the glitch can differ depending on the exact timing of the name being printed on screen. ▼Move 0x00 has a glitch type, specifically glitch type 0xD0. The source of its glitch type is 0x8350 in VRAM, hence what is or what was on the screen will affect what the game brings up as a type name; possibly with what's on the Pokémon menu affecting 0x8350{{fact}}, as 0x8350 may be written to if you have enough Pokémon menu sprites and/or held items in the party.
DueOverall, it might be difficult to manipulate the data written to $C51E exactly. However, due to the structure of the code located right after the jump table, a reasonable amount of pointers will land in the vicinity of either the $C9xx region or the $E9xx region (echo RAM for the $C9xx region). For smaller maps, execution will safely slide until it reaches three regions: ▼When we have 'good' data at 0x8350 the name of the glitch type causes text to print beyond the end of screen tile data, reaching far enough to corrupt address $C51E, wSpriteAnim1AnimSeqID. Depending on the text character written into this field, this indexes the animation jump table out of bounds, potentially triggering ACE.
▲Type 0xD0's name is susceptible to VRAM accessibility. Since the name is read from VRAM, if the game attempts to read a character while VRAM is inaccessible it will read value $FF and print a '9' instead of the expected character. This means that the effects of the glitch can differ depending on the exact timing of the name being printed on screen.
▲Due to the structure of the code located right after the jump table, a reasonable amount of pointers will land in the vicinity of either the $C9xx region or the $E9xx region (echo RAM for the $C9xx region). For smaller maps, execution will safely slide until it reaches three regions:
* $CC20 contains wBGMapBuffer, which temporarily buffers newly inserted tile IDs.
* $CC48 contains wBGMapPalBuffer, which temporarily buffers newly inserted tile palettes.
|