TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #5883: Masterjun's SNES Super Mario World "sram game end glitch" in 00:11.13

Console: Super NES
Game name: Super Mario World
Game version: USA
ROM filename: Super Mario World (U) [!].smc
Branch: sram game end glitch
Emulator: lsnes rr2
Movie length: 00:11.13
FrameCount: 669
Re-record count: 73
Author's real name: Julian N.
Author's nickname: Masterjun
Submitter: Masterjun
Submitted at: 2018-04-01 00:01:44
Text last edited at: 2018-04-04 00:53:08
Text last edited by: Nach
Download: Download (1119 bytes)
Status: decision: rejected
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
ALERTS POSSIBLY COMPROMISING MOVIE INTEGRITY:

LSMV begins from dirty SRAM

Author's comments and explanations:

Behold!

It is time to unleash the ultimate destruction of this piece of interactive game software called Super Mario World!


(Link to video)

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?


Nach: This run is in violation of the various rules. Rejecting.

Similar submissions (by title and categories where applicable):