Behold!
It is time to unleash the ultimate destruction of this piece of interactive game software called Super Mario World!
Game objectives are comfy and easy to wear
- Emulator used: lsnes rr2
- Win the game
- (very fast)
- details
Saving... do not turn off th-
Overwriting the bytes in a savegame is not an instant process. Resetting halfway through can result in a corrupted savegame. To try and avoid loading faulty data, most games use a checksum, so does SMW. The checksum is 16 bits and thus can only hold 2^16 = 65536 different values. This means a working corrupted savegame can be created with a well-timed reset.
Super SRAM World
Loading corrupted savegame data itself does not crash the game or lead to any dangerous codepaths.
However, a corrupted submap value will make the game load graphic bytes from various locations (and one of those locations can be SRAM itself). Having corrupted graphics doesn't crash the game, but important here is how the game first decompresses the data into a buffer in memory ($7E:AD00). There are no checks for the bounds (only 0xC00 = 3072 bytes are allocated), so we can buffer overflow bytes all the way to $7F:8000 where SMW stores its OAM clearing routine, which runs every frame when there are sprites on the screen.
Of course, we're not only able to overwrite the data with random values, we can actually overwrite the bytes with arbitrary code.
Arbitrary Code Execution?
Arbitrary Code Execution.
There are like a few dozen frames, which one is the best?
There are at least 3 interesting ones (check the credits), but to avoid spoilers I'll just give you this one.
So there's "dirty" SRAM? Tell me, what is "clean" SRAM?
The current published run relies on a SRAM byte to have a specific value for it to work. It just so happens that our accepted SNES emulators fill the SRAM with the required byte.
If the current run is allowed to be on this site, then this new run, which relies on SRAM intialization as well, has to be accepted.
Is filling the memory with a single byte "cleaner" than filling it with somewhat random data? This particular run goes the extra mile and also includes a payload, but remove the payload and you will get a crash which can in theory lead to controller registers, and to the credits all over again, extending this run by a few frames.
If this run is rejected, is the current run faulty as well?