Glitch City Laboratories Forums

Lab γ: Video Games and Glitches Discussion => Pokémon Glitch Discussion => Generation I Glitch Discussion => Topic started by: Evie the Bird Mother 🌸 ☽ on November 02, 2019, 12:16:26 pm

Title: How far can 0x0 sprite dimensions corrupt?
Post by: Evie the Bird Mother 🌸 ☽ on November 02, 2019, 12:16:26 pm
Glitch Pokémon's 0 dimension sprite dimensions (height/width) can cause a buffer overflow while decompressing the SRAM, into RAM. Up to where in RAM can this corrupt? We know Yellow MissingNo. corrupts C0EF/C0F0. Other than C109 (facing direction which allows for ACE (https://glitchcity.info/wiki/Facing_direction_arbitrary_code_execution)), are there any other corruptible locations to do something useful to exploit?
Title: Re: How far can 0x0 sprite dimensions corrupt?
Post by: Parzival on November 03, 2019, 11:52:17 am
Glitch Pokémon's 0 dimension sprite dimensions (height/width) can cause a buffer overflow while decompressing the SRAM, into RAM. Up to where in RAM can this corrupt? We know Yellow MissingNo. corrupts C0EF/C0F0. Other than C109 (facing direction which allows for ACE (https://glitchcity.info/wiki/Facing_direction_arbitrary_code_execution)), are there any other corruptible locations to do something useful to exploit?
how many bytes does the typical frontsprite take up and how big is it?
Title: Re: How far can 0x0 sprite dimensions corrupt?
Post by: Sherkel on November 03, 2019, 12:43:16 pm
Glitch Pokémon's 0 dimension sprite dimensions (height/width) can cause a buffer overflow while decompressing the SRAM, into RAM. Up to where in RAM can this corrupt? We know Yellow MissingNo. corrupts C0EF/C0F0. Other than C109 (facing direction which allows for ACE (https://glitchcity.info/wiki/Facing_direction_arbitrary_code_execution)), are there any other corruptible locations to do something useful to exploit?
how many bytes does the typical frontsprite take up and how big is it?
5 x 5, 6 x 6, or 7 x 7 tiles. Not sure if it has to be uniform, but all examples are. Presumably treating one as 256 x 256 and seeing how far it reaches if the same routine is run for it should show up to where it overwrites.
Title: Re: How far can 0x0 sprite dimensions corrupt?
Post by: Parzival on November 03, 2019, 03:16:46 pm
Glitch Pokémon's 0 dimension sprite dimensions (height/width) can cause a buffer overflow while decompressing the SRAM, into RAM. Up to where in RAM can this corrupt? We know Yellow MissingNo. corrupts C0EF/C0F0. Other than C109 (facing direction which allows for ACE (https://glitchcity.info/wiki/Facing_direction_arbitrary_code_execution)), are there any other corruptible locations to do something useful to exploit?
how many bytes does the typical frontsprite take up and how big is it?
5 x 5, 6 x 6, or 7 x 7 tiles. Not sure if it has to be uniform, but all examples are. Presumably treating one as 256 x 256 and seeing how far it reaches if the same routine is run for it should show up to where it overwrites.
well if I knew how many bytes one frontsprite of known size takes up, I could calculate out how many bytes it'd take up and thus (barring weird position-resetting behavior) the range of corruption.
Title: Re: How far can 0x0 sprite dimensions corrupt?
Post by: Evie the Bird Mother 🌸 ☽ on March 10, 2020, 08:23:09 am
Actually there's a great point here. You can probably use the sprite import tools and method (https://sites.google.com/site/torchickens2/glitching-tools) in someway; except these originally aren't sprites but data/code interpreted as sprites. A 7x7 sprite is 56x56 pixels. We can probably find how many pixels then a 256x256 sprite would be; hence around how many bytes long it might be. We know these cause buffer overflows into SRAM (and in Yellow MissingNo.'s case C0EF/C0F0). Maybe you do 256x8 which is 2048 pixels.
Title: Re: How far can 0x0 sprite dimensions corrupt?
Post by: Evie the Bird Mother 🌸 ☽ on March 10, 2020, 11:27:00 am
So we have (from disassembly);

wSpriteCurPosX:: ; d0a1
   ds 1
wSpriteCurPosY:: ; d0a2

For D0A1, the game seems to cycle through values of 0 to (sprite width x8). For instance, when loading Rattata's sprite; d0a1 will only be from $00-$27 (dec:0-39), because 5x8=40. (Rattata has 5 for its dimensions).

Encountering Yellow MissingNo. (addresses here other than A188 are -1)

When we get to

sSpriteBuffer1:: ds SPRITEBUFFERSIZE ; a188

@0:24D9
; Put a into D0A0
; Put D0AC (sprite output pointer) into a
; increment a, and then value in D0AC
; At some point we get back to 0:24D9. D0A0 increases to the maximum width of Yellow MissingNo. (256 bytes).
; hl (a188) increases 1040 times

OK my Yellow MissingNo. corrupted up to C30F from the 2564 routine.